[Maria-developers] Syntax for parallel replication

[Kristian Nielsen]

Hi Serg,

Can you help me with suggestions/comments for the following proposal for how
to do configuration for MDEV-6676, speculative parallel replication?

I am not too happy about how things are in 10.0. There, there is a single
option --slave-parallel-threads=N. If N0, then parallel replication is
enabled, else not.

One problem is that this makes it not configurable per multi-source master
connection. Another problem is that there are two possible mechanisms for
parallelisation, group-commit based and domain_id based; currently, one can
enable none of them or both, but not just one of them.

MDEV-6676 will introduce at least one other mechanism, which seems to make it
essential to make a better way to configure this.

Now, ideally, there would not be any configuration at all. The server would
just run things in parallel when possible and to the degree desirable.
However, I think there are some reasons that we need to allow the user this
configurability:

 - Parallel replication is still a somewhat experimental feature, so it seems
   too risky to enable it by default. Also, it doesn't really seem possible
   for the server to automatically set the best number of threads to use, with
   current implementation (or possibly any implementation).

 - When replicating with non-transactional updates, or in non-gtid mode, slave
   state is not crash safe. This is true in non-parallel replication also, but
   in parallel replication, the problem seems amplified, as there may be
   multiple transactions in progress at the time of a crash, complicating
   possible manual recovery. This also suggests that parallel replication must
   be configurable.

 - When using domain-based parallel replication, the user is responsible for
   ensuring that independent domains are non-conflicting and can be replicated
   out-of-order wrt. each other. So if replication domains are used, but this
   property is not guaranteed, then domain-based parallel replication need to
   be configurable, or parallel replication cannot be used at all.

 - The new speculative replication feature in MDEV-6676 is not always
   guaranteed to be a win - in some workloads, where there are many conflicts
   between successive transactions, excessive rollback could cause it to be
   less efficient than not using it. Again, this suggests it needs to be
   configurable.

So given this, I came up with the following idea for syntax:

  CHANGE MASTER TO PARALLEL_MODE=(domain,groupcommit,transactional,waiting)

Each of the four keywords in the parenthesis is optional.

domain enables domain-based parallelisation, where each replication domain
is treated independently.

groupcommit enables the non-speculative mode, where only transactions that
group-committed together on the master are applied in parallel on the slave.

transactional enables the speculative mode, where all transactional DML is
optimistically tried in parallel, and then in case of conflict a rollback and
retry is done.

groupcommit and transactional are mutually exclusive, at most one of them
can be specified.

The default would be (domain,groupcommit) to be back-wards compatible with
10.0. If slave_parallel_thread=0, then no parallel apply will happen even if
PARALLEL_MODE is non-empty. If slave_parallel_thread0 but PARALLEL_MODE is
empty (PARALLEL_MODE=()), then again no parallel apply will be done.

The waiting option is not essential to add, we could remove it, I put it in
because there were already a number of options so it seemed to cause no
harm. The idea is that on the master, we detect if transaction T2 had to do a
row lock wait on transaction T1. If so, it seems likely that a similar
conflict could occur on the slave, so we will not run T2 in parallel with T1;
instead we will let T2 wait for T1 to commit before T2 is started. The
waiting option could be enabled by a user to disable this check, enabling
even more aggressive parallelisation. I am not sure if it is worth it to have
this configurable though, comments welcome.

I have not checked how hard it will be to implement the new syntax. We do not
have any similar multi-option CHANGE MASTER elements, as far as I know, but it
is similar to ENUM system variables. And we already have a IGNORE_SERVER_IDS
syntax with comma-separated list within parenthesis. So hopefully not too hard
to do, and somewhat consistent with existing syntax.

So what do you think? Is it a reasonable syntax? Any comments, or suggestions
for better way to do it?

Thanks,

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

[Maria-developers] MDEV-6429 (storage engine API for parallel replication) possibly a requirement for MDEV-6676 (speculative parallel replication)

[Kristian Nielsen]

Hi Serg,

Earlier this year we discussed MDEV-6429, which is to implement a proper
storage engine API for a feature used in parallel replication. This is where
InnoDB reports to the replication layer whenever transaction T1 needs to wait
for T2; parallel replication uses this to detect and resolve deadlocks caused
by enforced commit order.

In 10.0, we decided to not do a proper API, instead just modify InnoDB to
call into the server layer directly. In 10.0, the need for this API/feature is
somewhat InnoDB-specific, it is not known whether any of the other
transactional storage engines would need to do anything similar for parallel
replication to work.

If we implement MDEV-6676, however, then the need for the API becomes more
critical. Because MDEV-6676 absolutely only works if we have a mechanism to
detect conflicts that cause a deadlock with commit order, as was implemented
for InnoDB. If we were to attempt to enable speculative parallel replication
for eg. Tokutek transactions, without implementing the necessary check in
Tokutek, then the slave would quickly end up hanging.

Thinking more on this, I suppose what we really need is what you requested
also during the original discussion: A true optional feature for storage
engines to implement this additional check. And a way for the server layer to
see if a storage engine has the implementation. If it does, then we can try to
run its transactions in parallel as per MDEV-6676. If not, we will not try,
and things will still work correctly (just without the parallelisation
optimisation).

Maybe for the first version, the best thing to do is to just hard-code a check
for the InnoDB storage engine. This will allow us to get real-world testing to
see if the new speculative parallel replication feature is interesting to any
users. Then if it is, and there turns out to be interest from other storage
engine venders (such as Tokutek) to also support speculative parallel
replication, we can work with them to implement a proper API.

This approach would also allow to consider the needs of a different storage
engine when designing the API, which makes it much more likely that the API
will be of general use and not too tied to InnoDB internals.

What do you think?

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp

[Maria-developers] Isn't thsi a bug?

[Peter Laursen]

Refer: http://bugs.mysql.com/bug.php?id=74238

here I prefer the 'relaxed parsing' in Maria DB.


But look at this:

CREATE TABLE `d` (
`rec_id` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
`datetime` DATETIME(4) DEFAULT NULL,
`timestamp` TIMESTAMP(4) NOT NULL DEFAULT CURRENT_TIMESTAMP(5) ON UPDATE
CURRENT_TIMESTAMP(4),
PRIMARY KEY (`rec_id`)
) ENGINE=INNODB;
-- it actually creates the table

SHOW CREATE TABLE d;
/* returns

CREATE TABLE `d` (
  `rec_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `datetime` datetime(4) DEFAULT NULL,
  `timestamp` timestamp(4) NOT NULL DEFAULT CURRENT_TIMESTAMP(4) ON UPDATE
CURRENT_TIMESTAMP(4),
  PRIMARY KEY (`rec_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
*/

I don't think DEFAULT CURRENT_TIMESTAMP(5) should be accepted for the
datatype DATETIME(4).


What say?



-- Peter
-- Webyog
___
Mailing list: https://launchpad.net/~maria-developers
Post to : maria-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-developers
More help   : https://help.launchpad.net/ListHelp