mysqldump备份恢复--一致性

mysqldump --lock-all-tables  --flush-logs --master-data=2 --all-databases > backup.sql

shell脚本判断mysqldump锁表

[root@faxian ~]# more mysql.sh 
#/bin/bash
for (( i=1; i<=150; i=i+1 ))
do
mysql test -e 'insert into test02(name) values(1)'
sleep 2
done
exit 0
[root@faxian ~]# 

操作步骤

1.sh mysql.sh

2、mysqldump --lock-all-tables  --flush-logs --master-data=2 --all-databases > backup.sql

3、查看binlog刷新情况，还有backup.sql头部

--
-- Position to start replication or point-in-time recovery from

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000006', MASTER_LOG_POS=120;

-- Current Database: `mysql`
-绿色部分就是mysql<backup.sql之后需要恢复的起始日志序列

mysqldump --single-transaction   --flush-logs --master-data=2   --all-databases  > backup.sql

操作步骤和上面一致。

发现 --single-transaction只是切换了binlog日志，而没有锁表，--lock-all-tables 则是一致备份阶段一致锁表，直到备份结束。

 backup.sql文件头部一样

测试表明：myisam和innodb引擎都可以用上面语句进行全备

lock-all-table 表示把所有的库，表都锁住了，此时不允许写入，MyISAM和InnoDB肯定是一致的。

flush tables with read lock;flush logs;cp.....;unlock table;还是flush tables with read lock;cp......;flush logs;unlock table;
这两种方式都没有问题。重要的是，你恢复数据库以后，从备份库的哪个位置开始应用binlog。

具体一点来说。备份是做什么用的列？它是为了恢复用的，首先，将所有的数据逻辑导入。这里并没有完，你保证了MyISAM和InnoDB或者其他引擎的一致性，没问题。因为备份完成后，你就解锁了，数据又有变更。你如果先把后面的这些变更赶上，那么就必须从备份库的某一个位置开始应用binlog。这个位置必须在lock table 和unlock table之间记录，只有在这段时间内，binlog是不变的，也正是在这段时间内，你把所有的数据拷贝出去了。所以，flush logs在你说的这两种情况下，并没有太大的区别。它只是在当前binlog最末尾的位置上加上Rotate Event，提示下一个binlog文件是谁。而你恢复的时候是从文件的末尾开始恢复，还是从下一个文件的开头位置恢复都没有问题。因为这里的binlog并不设计到业务数据的变化。
这里应该没有必要看MySQL的源码，你直接试试在lock和unlock之间，flush logs，然后用mysqlbinlog看看它做了什么事情就好了