Sergei Golubchik <serg@mariadb.org> writes:
I didn't know that it was possible to use --connection_name.XXX to configure things, which is why I thought I needed to use CHANGE MASTER instead.
Well, "possible" can have different meanings.
I meant that from the user point view --connection_name.variable_name is the normal and expected way to configure per-connection variables. Consistent with other per-connection variables and with named key caches.
But it is well possible that there's no existing class that implements this functionality yet.
Right, understood. I like the idea of --connection_name.XXX to configure parallel replication per-connection. I will see what it takes to implement that.
I agree that "groupcommit" is rather too technical. However, "following_master" is too generic, it doesn't say anything.
It means that the degree of parallelization on the slave is following the degree of parallelization on the master. If more threads are executed (commited, strictly speaking) in parallel on master - more threads can be commited in parallel on the slave. If the master is strictly single-threaded, there's only one connection doing changes - the slave will follow that and will serialize all transactions too.
Right. Let's go with your "following_master". Thanks, - Kristian.