maria-discuss team mailing list archive

[MARK CALLAGHAN <mdcallag@xxxxxxxxx>]

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 <prohaska7@xxxxxxxxx> 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 <mdcallag@xxxxxxxxx>
> 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.reindl@xxxxxxxxxxxxx>
>> 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.reindl@xxxxxxxxxxxxx
>>>> <mailto:h.reindl@xxxxxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~maria-discuss
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> --
>> Mark Callaghan
>> mdcallag@xxxxxxxxx
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~maria-discuss
>> Post to     : maria-discuss@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-discuss
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>


-- 
Mark Callaghan
mdcallag@xxxxxxxxx