[Maria-developers] Testing group commit with XtraBackup
Hi Philip, I thought of another test of group commit that ought to be done (not sure why I didn't think to mention this earlier, sorry about that). It's not urgent, just something for the list. The test is basically the same you already did for non-blocking `mysqldump --master-data --single-transaction` used to provision a slave, but using XtraBackup instead of mysqldump.
From what I could learn, the original reason that InnoDB added the mutex that kills group commit when binlog is enabled is the following: To ensure that commit order in the InnoDB transaction log is the same as in the binlog. This is needed when XtraBackup (innobackup really, but they work the same and XtraBackup is Free Software) takes a non-blocking backup of the InnoDB data (only), and this is used to provision a new slave. If commit order was different, there might not be any binlog position on the master corresponding to the backup snapshot used to setup the new slave.
Now, my group commit work also guarantees consistent commit order, but using a completely different method that does not kill group commit. So we ought to test this. So the test would be similar to your existing mysqldump test. But while the master is running, we would use non-blocking XtraBackup to take a snapshot. This snapshot we would then restore onto a new slave. The slave would then be configured with CHANGE MASTER TO, I believe one gets the correct binlog position to start from in the log file of XtraDB and/or slave mysqld (I need to check up on details). Then the test proceeds as the mysqldump case, letting the slave catch up and checking that replication is ok etc. What do you think? Now, to do this we would need to be able to use XtraBackup. I am wondering if it wouldn't make sense to at the same time include XtraBackup into MariaDB? XtraBackup seems to me quite mature already, and a very good product besides. It is arguably long overdue for us to include it. So if we include XtraBackup in mariadb-5.2-rpl (/5.3), I think this should be possible to setup without too much trouble (I can provide specific details/scripts for how to actually run XtraBackup and setup slave start position, I just need to research that a bit). Or we could also do the test first with XtraBackup as external, shouldn't be much harder, and would give us some experience with it. What do you think? Maybe we can look at it in more detail in Lisbon. - Kristian.
I think this test is entirely possible within the existing framework so I will try to do it eventually. Philip Stoev ----- Original Message ----- From: "Kristian Nielsen" <knielsen@knielsen-hq.org> To: "Philip Stoev" <philip@stoev.org> Cc: <maria-developers@lists.launchpad.net> Sent: Wednesday, March 09, 2011 8:36 AM Subject: Testing group commit with XtraBackup
Hi Philip,
I thought of another test of group commit that ought to be done (not sure why I didn't think to mention this earlier, sorry about that). It's not urgent, just something for the list.
The test is basically the same you already did for non-blocking `mysqldump --master-data --single-transaction` used to provision a slave, but using XtraBackup instead of mysqldump.
From what I could learn, the original reason that InnoDB added the mutex that kills group commit when binlog is enabled is the following: To ensure that commit order in the InnoDB transaction log is the same as in the binlog. This is needed when XtraBackup (innobackup really, but they work the same and XtraBackup is Free Software) takes a non-blocking backup of the InnoDB data (only), and this is used to provision a new slave. If commit order was different, there might not be any binlog position on the master corresponding to the backup snapshot used to setup the new slave.
Now, my group commit work also guarantees consistent commit order, but using a completely different method that does not kill group commit. So we ought to test this.
So the test would be similar to your existing mysqldump test. But while the master is running, we would use non-blocking XtraBackup to take a snapshot. This snapshot we would then restore onto a new slave. The slave would then be configured with CHANGE MASTER TO, I believe one gets the correct binlog position to start from in the log file of XtraDB and/or slave mysqld (I need to check up on details). Then the test proceeds as the mysqldump case, letting the slave catch up and checking that replication is ok etc.
What do you think?
Now, to do this we would need to be able to use XtraBackup. I am wondering if it wouldn't make sense to at the same time include XtraBackup into MariaDB? XtraBackup seems to me quite mature already, and a very good product besides. It is arguably long overdue for us to include it.
So if we include XtraBackup in mariadb-5.2-rpl (/5.3), I think this should be possible to setup without too much trouble (I can provide specific details/scripts for how to actually run XtraBackup and setup slave start position, I just need to research that a bit).
Or we could also do the test first with XtraBackup as external, shouldn't be much harder, and would give us some experience with it.
What do you think? Maybe we can look at it in more detail in Lisbon.
- Kristian.
The test is basically the same you already did for non-blocking `mysqldump --master-data --single-transaction` used to provision a slave, but using XtraBackup instead of mysqldump.
So the test would be similar to your existing mysqldump test. But while the master is running, we would use non-blocking XtraBackup to take a snapshot. This snapshot we would then restore onto a new slave. The slave would then be configured with CHANGE MASTER TO, I believe one gets the correct binlog position to start from in the log file of XtraDB and/or slave mysqld (I need to check up on details). Then the test proceeds as the mysqldump case, letting the slave catch up and checking that replication is ok etc.
Done, a test was created and installed in buildbot, where it passes. I am using xtradb from RPM.
Now, to do this we would need to be able to use XtraBackup. I am wondering if it wouldn't make sense to at the same time include XtraBackup into MariaDB? XtraBackup seems to me quite mature already, and a very good product besides. It is arguably long overdue for us to include it.
So if we include XtraBackup in mariadb-5.2-rpl (/5.3), I think this should be possible to setup without too much trouble (I can provide specific details/scripts for how to actually run XtraBackup and setup slave start position, I just need to research that a bit).
Including XtraBackup means including in MariaDB a yet another piece of software that, even if it is of reasonable quality, has a different development and release cycle: - we have 3 different innnodb directories, innodb, innodb_plugin and xtradb - they have 3 different xtrabackup binaries, one for 5.0, one for 5.1 and one for 5.5 - they provide 5 patches to patch Innodb with. As discussed in IRC, I tried the most intuitive combination and it did not patch correctly. I did not try your renaming trick; - in launchpad, they have a bunch of trees: a trunk tree , a 1.6 tree and a windows tree, both of which have seen pushes in the last 1 week Philip Stoev
"Philip Stoev" <pstoev@askmonty.org> writes:
The test is basically the same you already did for non-blocking `mysqldump --master-data --single-transaction` used to provision a slave, but using XtraBackup instead of mysqldump.
Done, a test was created and installed in buildbot, where it passes. I am using xtradb from RPM.
Cool, great stuff!
Now, to do this we would need to be able to use XtraBackup. I am wondering if it wouldn't make sense to at the same time include XtraBackup into MariaDB? XtraBackup seems to me quite mature already, and a very good product besides. It is arguably long overdue for us to include it.
Including XtraBackup means including in MariaDB a yet another piece of software that, even if it is of reasonable quality, has a different development and release cycle:
- we have 3 different innnodb directories, innodb, innodb_plugin and xtradb - they have 3 different xtrabackup binaries, one for 5.0, one for 5.1 and one for 5.5 - they provide 5 patches to patch Innodb with. As discussed in IRC, I tried the most intuitive combination and it did not patch correctly. I did not try your renaming trick; - in launchpad, they have a bunch of trees: a trunk tree , a 1.6 tree and a windows tree, both of which have seen pushes in the last 1 week
Yes, those are good points. So if users can just install xtrabackup stand-alone like from a Percona package, that might actually be better than including it in MariaDB. Once we get into distros, it will in any case be seamless, users will just eg. apt-get install xtrabackup, and it will not matter from where it comes. (and we could depends: or recommends: it from the mariadb-server package). Thanks! - Kristian.
participants (2)
-
Kristian Nielsen -
Philip Stoev