Rich - we have read-free replication although I am not sure on the status of it -- whether it is done or work-in-progress. https://github.com/facebook/mysql-5.6/wiki/Read-Free-Replication
On Wed, Oct 12, 2016 at 1:18 PM, Rich Prohaska <prohas...@gmail.com> wrote: > Hello All, > Back in the day, I was one of the Tokudb developers @ Tokutek. Two of the > features that I worked on were read free replication (RFR) and online > schema change for Tokudb. > > RFR has some nice slave performance benefits by the replacing read modify > write algorithm with a write algorithm. This works because the replication > stream includes the before and after rows. IMO, this would be nice to have > with Myrocks. There is a Mariadb push request for RFR that works with > Tokudb that may be used as the API for this feature for other storage > engines. > > Online schema change in Tokudb only injects 'schema change messages' into > the top of the fractal tree. This is very fast. The actual change in the > encoded row format occurs much later when these messages are executed on > the leaf nodes. This seems nice to me, but it can be replaced with other > online schema change packages. It would be nice to compare these various > method WRT to performance. > > Tokudb also supports large transactions defined as transactions that > effect a large number of rows such that the memory footprint of the undo > log for these operations spills to external storage. Personally, I don't > like large transactions, and believe that they should be avoided. However, > some people do use them, and the mysql server should be able to support > them without crashing, perhaps with degraded performance. > > On Wed, Oct 12, 2016 at 12:25 PM, MARK CALLAGHAN <mdcal...@gmail.com> > wrote: > >> 0) Sergei and Justin - I prefer to avoid the "Monty says" game either for >> or against. We are trying to establish a community here. He is one of many. >> His reputation (good or bad) shouldn't be a stick that is deployed to win >> arguments. >> >> 1) RocksDB has persistent snapshots. That would make flashback trivial to >> implement for MyRocks assuming you took snapshots ahead of time. So maybe >> that isn't flashing back. >> http://rocksdb.org/blog/2015/11/10/use-checkpoints-for-effic >> ient-snapshots.html >> >> 2) I expect almost everyone to choose MyRocks given a choice between >> MyRocks and TokuDB. I have evaluated TokuDB over several years. I have many >> performance and efficiency results from this year that I have yet to >> publish. Results are almost always much better with MyRocks, we have more >> resources dedicated to MyRocks so it will improve quickly. >> >> MariaDB is a community project, so if someone maintains TokuDB I assume >> it will be included in MariaDB. But I think time is better spent on >> MyRocks. Our docs need to be updated and our communication needs to be >> better. But we move fast and Yoshi has been updating the limitations wiki >> page as I write this (https://github.com/facebook/m >> ysql-5.6/wiki/MyRocks-limitations). >> >> I am not surprised that there are so few performance results published >> for TokuDB. And when they are published they are almost always for trivial >> workloads -- like insert-only insert benchmark. Try adding queries >> concurrent with the inserts. >> >> 3) Partitioning via the partition storage engine is supported for >> MyRocks. My employer doesn't need it for the initial deployment. It might >> be needed elsewhere and I am sure the community needs it. I assume we also >> need native partitioning in MyRocks when we move up to MySQL 8. The >> limitations page is getting updated to explain this. >> >> 4) By default the FB MySQL branch doesn't allow mysqld to start if >> MyRocks and InnoDB are enabled. This was misinterpreted to mean it wasn't >> possible to use MyRocks and InnoDB at the same time. It is possible now. >> And MariaDB/Percona are free to always allow both to be enabled. It was >> previously prevented in the FB MySQL repo because of fear that internal >> users might try to do a transaction that spans engines. I think that is a >> bad idea and XA scares me. I assume evaluations for MariaDB Server and >> Percona Server require that both InnoDB and MyRocks are enabled >> concurrently. See https://github.com/facebook/mysql-5.6/issues/106 >> >> 5) We have work in progress to support XA for MyRocks. Code has been >> merged. Perf tests are in progress. >> >> 6) We have work in progress to support online DDL. >> >> 7) MyRocks supports read-committed (RC) and repeatable-read (RR). RR in >> MyRocks is Postgres-style and I assume that it won't get much use, just >> like i assume it doesn't in Postgres. If we add gap-locking to MyRocks RR >> then it will match InnoDB. For details see https://github.com/mdcalla >> g/mytools/wiki/Cursor-Isolation >> >> 8) I am a long time user of SBR and think that RBR is the future. MyRocks >> needs RBR because we expect most deployments to use it with read-committed >> and just like InnoDB, that needs RBR. If gap locking is added to MyRocks RR >> then SBR is feasible, but you give up all of the great new replication >> features that will be RBR only. http://dba.stackexchange >> .com/questions/101122/mysql-why-statement-based-binlog- >> format-cannot-work-with-innodb-read-uncommitte >> >> 9) MyRocks could do transportable column family for all indexes/tables in >> a column family. Transportable is a nice feature but I don't think the lack >> of it is a big deal. It is part of being storage efficient, but the overall >> storage efficiency story is much stronger for MyRocks than InnoDB. >> >> 10) I hope there is a plan for foreign key and spatial in MyRocks. There >> isn't one yet. I don't think full text in any MySQL engine is a good use of >> time given how infrequently it is used. >> >> >> >> On Wed, Oct 12, 2016 at 8:39 AM, Reindl Harald <h.rei...@thelounge.net> >> wrote: >> >>> >>> >>> Am 12.10.2016 um 17:34 schrieb Justin Swanhart: >>> >>>> When upgrading from 5.0 -> 5.1 the sort order of some german characters >>>> was modified, which meant indexes had to be rebuilt (they are in sorted >>>> order after all). The mysql_upgrade would suggest a table rebuild >>>> (ALTER TABLE xyz ENGINE=INNODB) or dump/restore for every affected >>>> table. I was a consultant during this time, and I can't tell you how >>>> many tables I had to rebuild. Thousands to say the least. Yuck. >>>> >>> >>> well, a five-liner in PHP using a root account while UTF8_GENERAL_CI was >>> the wrong charset/collation anyways for german umlauts :-) >>> >>> On Wed, Oct 12, 2016 at 10:01 AM, Reindl Harald <h.rei...@thelounge.net >>>> <mailto:h.rei...@thelounge.net>> wrote: >>>> >>>> >>>> Am 12.10.2016 um 15:53 schrieb Justin Swanhart: >>>> >>>> Also having to dump/restore to go from 10.2 to 10.3 tables is a >>>> PITA >>>> >>>> it's a simple no-go and the answer to "should i use postgre or >>>> mysql/mariadb" is always "stay away from postgre, while it got >>>> better you need to dump your data and import them again still way >>>> too often while our mysql tables where created 2002 and now running >>>> on MariaDB 10 without doing such a bullshit a single time" >>>> >>>> Remember how awful it was to migrate all those BDB tables to >>>> InnoDB? Or >>>> even just how frustrating it was when UTF8_GENERAL_CI changed >>>> the umlaut? >>>> >>>> when did something change umlauts? >>>> >>>> as charsets where introdcued with MySQL 5.0 it was a simple script >>>> just to add the correct charset information that it is *not* UTF8 to >>>> 5000 tables with not a single char damaged and since we are located >>>> in austria üöäß are very common >>>> >>> >>> _______________________________________________ >>> Mailing list: https://launchpad.net/~maria-discuss >>> Post to : maria-discuss@lists.launchpad.net >>> Unsubscribe : https://launchpad.net/~maria-discuss >>> More help : https://help.launchpad.net/ListHelp >>> >> >> >> >> -- >> Mark Callaghan >> mdcal...@gmail.com >> >> _______________________________________________ >> Mailing list: https://launchpad.net/~maria-discuss >> Post to : maria-discuss@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~maria-discuss >> More help : https://help.launchpad.net/ListHelp >> >> > -- Mark Callaghan mdcal...@gmail.com
_______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp