I am very happy to share with you all that the much awaited feature request - multi-threaded slave (MTS) - has made it to the development tree targeting 5.6 release and is part of this latest 5.6 DMR release (5.6 DMR2).
I would like to take a moment to thank those of you that took the time to evaluate and provide invaluable feedback. Some started as early as the very first snapshot that was put out in the open. Part of this feedback is directly responsible for many changes, as outlined in my previous posts about MTS. Since the last snapshot, we kept on taking your suggestions seriously and improved the implementation by deploying a few of them in time for this release. Again, thanks!
What comes next for MTS? Well, it will continue to be debugged and get its overall quality improved.
What comes next for MySQL replication? You already know that we are working on the binlog group commit (by the way, you can get a hold of the second labs snapshot for that one). But, wait, there's more! We are also spending time and effort to implement another much awaited feature: Global Transaction Ids. I think you'll enjoy that one very much (there is also a very early access labs snapshot that you can check out - I'll blog about the details later on...).
Lots of interesting stuff going on. Stay tuned!
In the meantime, you can download 5.6 DMR2 and check out our labs releases.
Wow - the replication team is making things much better!
ReplyDeleteMTS? Awesome!
ReplyDeleteGreat work. A BIG Thank You to all!
ReplyDeleteI have one database on Slave[MySLQ 5.6.3] that's being replicated from a Master[MySQL 5.5.8]. Replication is RBR, and I set slave_parallel_workers=8.
ReplyDeleteMy question is: Will the events from master be applied to slave [with just one database] in parallel using 8 threads? The diagram in this link "http://d2-systems.blogspot.com/2011/04/mysql-56x-feature-preview-multi.html" shows parallelism when there are multiple databases, but, how about my case where we have just one database.
show processlist; Does show 8 threads, but, it wont say what SQLs each thread is applying.
| 7 | system user | | NULL | Connect | 1211 | Waiting for master to send event | NULL |
| 8 | system user | | NULL | Connect | 0 | Slave has read all relay log; waiting for the slave I/O thread to update it | NULL |
| 9 | system user | | NULL | Connect | 81137 | Waiting for an event from Coordinator | NULL |
| 10 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 11 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 12 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 13 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 14 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 15 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 16 | system user | | NULL | Connect | 1211 | Waiting for an event from Coordinator | NULL |
| 291 | root | localhost | NULL | Query | 0 | init | show processlist
Thanks,
Sreedhar.
Hi Sree,
DeleteWhen one configures multiple appliers (through slave_parallel_workers) those appliers will, independently and exclusively from each other, work on their own set of databases. Each database has at most one applier thread working on it on a given moment in time.
Therefore, in your particular case, having only one database (say "db1") will result in having just one worker thread actually applying the relay log over time. Seven of them will remain idle. Should you have two different databases, say "db1" and "db2", and your load does not exhibit cross-database access patterns, one worker would apply changes to "db2" while the other would apply changes to "db1".
Regards,
Luís