Posted on 2012-04-10 17:19
Milo的海域 閱讀(669)
評(píng)論(0) 編輯 收藏 所屬分類:
MySQL
當(dāng)innobackupex 做全備的時(shí)候(my version 1.6.5), 當(dāng)備份到MyISAM數(shù)據(jù)時(shí), innobackupex 會(huì)flush tables with read lock, 來禁止MyISAM的寫操作. (假設(shè)沒有--no-lock選項(xiàng))
sub backup {
if (!$option_incremental && !$option_no_lock) {
# make a prep copy before locking tables, if using rsync
backup_files(1);
# flush tables with read lock
mysql_lockall();
}
if ($option_slave_info) {
write_slave_info();
}
}
sub mysql_lockall {
if (compare_versions($mysql_server_version, '4.0.22') == 0
|| compare_versions($mysql_server_version, '4.1.7') == 0) {
# MySQL server version is 4.0.22 or 4.1.7
mysql_send "COMMIT;";
mysql_send "FLUSH TABLES WITH READ LOCK;";
} else {
# MySQL server version is other than 4.0.22 or 4.1.7
mysql_send "FLUSH TABLES WITH READ LOCK;";
mysql_send "COMMIT;";
}
write_binlog_info;
} 但是如果備份的時(shí)候還有很重的workload, "flush tables with read lock" 可能會(huì)比較耗時(shí). 這里參考了：
http://www.mysqlperformanceblog.com/2010/04/24/how-fast-is-flush-tables-with-read-lock/
看了下--no-lock的選項(xiàng)說明：
--no-lock
Use this option to disable table lock with "FLUSH TABLES WITH READ
LOCK". Use it only if ALL your tables are InnoDB and you DO NOT CARE
about the binary log position of the backup.
如果我們能保證workload僅僅是innodb相關(guān)的，我們可以使用這個(gè)選項(xiàng)。
記得在1.5版本的時(shí)候，使用--no-lock選項(xiàng)會(huì)導(dǎo)致xtrabackup_slave_info沒有保存?zhèn)浞輹r(shí)的logfile & pos. 這個(gè)問題在1.6.5被解決了
if ($option_slave_info) {
write_slave_info();
}
xtrabackup_slave_info & xtrabackup_binlog_info文件在1.5版本是在
mysql_lockall函數(shù)里更新的。但是新版本已經(jīng)把
write_slave_info提到
mysql_lockall外面了。