mysqldump与innobackupex备份过程知多少（三）

最新推荐文章于 2024-07-02 00:50:11 发布

仲培艺

最新推荐文章于 2024-07-02 00:50:11 发布

阅读量470

点赞数

文章标签：数据库备份 MySQL InnoDB

本文链接：https://blog.csdn.net/Joy0921/article/details/80130785

版权

【前文传送门】

1.3 mysqldump有什么坑吗？

想必大家都知道，mysqldump备份时可以使用--single-transaction + --master-data两个选项执行备份（老实讲，为图方便，本人之前很长一段时间，生产库也是使用mysqldudmp远程备份的），这样备份过程中既可以尽量不锁表，也可以获取到binlog pos位置，备份文件可以用于数据恢复，也可以用于搭建备库。看起来那么美好，然而……其实一不小心你就发现踩到坑了

1.3.1 坑一

使用--single-transaction + --master-data时，myisam表持续不断插入，并用于搭建备库。

首先在A库上把myisam表的数据行数弄到100W以上：

......
root@localhost : luoxiaobo 11:26:42> insert into t_luoxiaobo2(test,datet_time) select test,now() from t_luoxiaobo2;
Query OK, 1572864 rows affected (4.47 sec)
Records: 1572864  Duplicates: 0  Warnings: 0
root@localhost : luoxiaobo 11:26:47> select count(*) from t_luoxiaobo2;
+----------+
| count(*) |
+----------+
|  3145728 |
+----------+
1 row in set (0.00 sec)

A库新开一个ssh会话2，使用如下脚本持续对表t_luoxiaobo2进行插入操作（该表为myisam表），限于篇幅，请点击此处获取。

A库新开一个ssh会话3，清空查询日志：

[root@localhost ~]# echo > /home/mysql/data/mysqldata1/mydata/localhost.log

现在，A库在ssh会话3中，使用mysqldump备份整个实例：

[root@localhost ~]# mysqldump -h 192.168.2.111 -uadmin -pletsg0 --single-transaction --master-data=2 --triggers --routines --events -A >\
 backup_`date +%F_%H_%M_%S`.sql 
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@localhost ~]# ls -lh backup_2017-07-03_00_47_50.sql 
-rw-r--r-- 1 root root 112M 7月   3 00:47 backup_2017-07-03_00_47_50.sql

备份完成之后，A库在ssh会话2中，停止持续造数脚本。

A库在ssh会话2中，查看备份文件中的binlog pos：

[root@localhost ~]# head -100 backup_*.sql |grep -i 'change master to'
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000005', MASTER_LOG_POS=76657819;

A库在ssh会话3中，查看查询日志，可以发现在UNLOCK TABLES之后，select *…t_luoxiaobo2表之前，还有数据插入到该表中：

2017-07-03T00:47:50.366670+08:00    87364 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2017-07-03T00:47:50.366795+08:00    87363 Query insert into t_luoxiaobo2(test,datet_time) values(11377,now())
2017-07-03T00:47:50.366862+08:00    87364 Query START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
2017-07-03T00:47:50.367023+08:00    87364 Query SHOW VARIABLES LIKE 'gtid\_mode'
2017-07-03T00:47:50.372331+08:00    87364 Query SELECT @@GLOBAL.GTID_EXECUTED
2017-07-03T00:47:50.372473+08:00    87364 Query SHOW MASTER STATUS
2017-07-03T00:47:50.372557+08:00    87364 Query UNLOCK TABLES
......
2017-07-03T00:47:50.381256+08:00    87366 Query insert into t_luoxiaobo2(test,datet_time) values(11383,now())
......
2017-07-03T00:47:50.381577+08:00    87365 Query insert into t_luoxiaobo2(test,datet_time) values(11380,now())
2017-07-03T00:47:50.381817+08:00    87360 Init DB   luoxiaobo
2017-07-03T00:47:50.381886+08:00    87360 Query insert into t_luoxiaobo2(test,datet_time) values(11382,now())
......
2017-07-03T00:47:50.391873+08:00    87364 Query show fields from `t_luoxiaobo2`
2017-07-03T00:47:50.392116+08:00    87364 Query show fields from `t_luoxiaobo2`
2017-07-03T00:47:50.392339+08:00    87364 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `t_luoxiaobo2`

现在，我们将这个备份文件用于B库上搭建备库，并启动复制，可以发现有如下复制报错：

root@localhost : (none) 12:59:12> show slave status\G;
*************************** 1\. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.2.111
                  Master_User: qfsys
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 79521301
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 320
        Relay_Master_Log_File: mysql-bin.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
......
               Last_SQL_Errno: 1062
               Last_SQL_Error: Could not execute Write_rows event on table luoxiaobo.t_luoxiaobo2; Duplicate entry '6465261' for key 'PRIMARY', Error_code: 1062;\
 handler error HA_ERR_FOUND_DUPP_KEY; the event's master log mysql-bin.000005, end_log_pos 76658175
......
ERROR: 
No query specified

从上面的结果中可以看到，主键冲突了，也就是说备份的表t_luoxiaobo2中的数据与备份文件中获取的binlog pos点并不一致，咱们现在在B库中，查询一下这个表中大于等于这个冲突主键的数据，从下面的结果中可以看到，备份文件中如果严格按照一致性要求，备份文件中的数据必须和binlog pos点一致，但是现在，备份文件中的数据却比获取的binlog pos点多了5行数据：

root@localhost : (none) 12:59:24> use luoxiaobo
Database changed
root@localhost : luoxiaobo 12:59:44> select id from t_luoxiaobo2 where id>=6465261;
+---------+
| id      |
+---------+
| 6465261 |
| 6465263 |
| 6465265 |
| 6465267 |
| 6465269 |
+---------+
5 rows in set (0.01 sec)

现在，咱们去掉--single-transaction选项，重新执行本小节以上步骤，重新搭建从库，看看是否还有问题（这里限于篇幅，步骤省略，只贴出最后结果）：

root@localhost : (none) 01:09:12> change master to master_host='192.168.2.111',master_user='qfsys',master_password='letsg0',master_log_file='mysql-bin.000005',\
master_log_pos=83601517;
Query OK, 0 rows affected, 2 warnings (0.02 sec)
Note (Code 1759): Sending passwords in plain text without SSL/TLS is extremely insecure.
Note (Code 1760): Storing MySQL user name or password information in the master info repository is not secure and is therefore not recommended. Please consider \
using the USER and PASSWORD connection options for START SLAVE; see the 'START SLAVE Syntax' in the MySQL Manual for more information.
root@localhost : (none) 01:09:23> start slave;
Query OK, 0 rows affected (0.01 sec)
root@localhost : (none) 01:09:25> show slave status\G;
*************************** 1\. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.2.111
                  Master_User: qfsys
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000005
          Read_Master_Log_Pos: 84697699
               Relay_Log_File: mysql-relay-bin.000002
                Relay_Log_Pos: 1096502
        Relay_Master_Log_File: mysql-bin.000005
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......
          Exec_Master_Log_Pos: 84697699
......

从上面的show slave status输出信息中我们可以看到，去掉了--single-transaction选项之后的备份，用于搭建备库就正常了。另外，我们重新在A库上查看查询日志也可以发现，只搜索到flush语句而没有搜索到unlock tables、set session transaction.. 、start transaction.. 语句，说明备份过程没有开启一致性快照事务，没有修改隔离级别，是全程加全局读锁的，mysqldump备份进程结束退出之后mysql server自动回收锁资源：

[root@localhost ~]# grep -iE 'flush|unlock tables|transaction' /home/mysql/data/mysqldata1/mydata/localhost.log 
2017-07-03T01:07:08.195470+08:00    102945 Query    FLUSH /*!40101 LOCAL */ TABLES
2017-07-03T01:07:08.206607+08:00    102945 Query    FLUSH TABLES WITH READ LOCK

也许你会说，我们数据库环境很规范，没有myisam表，不会有这个问题，OK，赞一个。

1.3.2 坑二

使用--single-transaction + --master-data时，InnoDB表执行online ddl，备份文件用于搭建备库（注意，本小节中的数据库实例与前一小节不同）。

这次我们操作InnoDB表，在A库上先把t_luoxiaobo表的数据也弄到几百万行。

qogir_env@localhost : luoxiaobo 10:03:35> insert into t_luoxiaobo(test,datet_time) select test,now() from t_luoxiaobo;
Query OK, 1048576 rows affected (9.83 sec)
Records: 1048576  Duplicates: 0  Warnings: 0
qogir_env@localhost : luoxiaobo 10:03:46> select count(*) from t_luoxiaobo;
+----------+
| count(*) |
+----------+
|  2097152 |
+----------+
1 row in set (0.39 sec)

A库在ssh会话2中，使用如下脚本持续对表t_luoxiaobo进行DDL操作（该表为InnoDB表），限于篇幅，请点击此处获取。

A库在ssh会话3中，清空查询日志：

[root@localhost ~]# echo > /home/mysql/data/mysqldata1/mydata/localhost.log

现在，A库在ssh会话3中，使用mysqldump备份整个实例：

[root@localhost ~]# mysqldump -h 192.168.2.111 -uadmin -pletsg0 --single-transaction --master-data=2 --triggers --routines --events -A > \
backup_`date +%F_%H_%M_%S`.sql 
mysqldump: [Warning] Using a password on the command line interface can be insecure.
[root@5f1772e3-0c7a-4537-97f9-9b57cf6a04c2 ~]# ls -lh backup_2017-07-03_12_46_49.sql 
-rw-r--r-- 1 root root 74M Jul  3 12:46 backup_2017-07-03_12_46_49.sql

A库在ssh会话2中，停止DDL添加脚本。

A库在ssh会话2中，查看备份文件中的binlog pos：

[root@5f1772e3-0c7a-4537-97f9-9b57cf6a04c2 ~]# head -100 backup_*.sql |grep -i 'change master to'
-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000257', MASTER_LOG_POS=62109599;

现在，我们将这个备份文件用于在B库中搭建备库，并启动复制，从下面的结果中可以看到，复制状态正常：

qogir_env@localhost : (none) 01:32:00> show slave status\G;
......
              Master_Log_File: mysql-bin.000257
          Read_Master_Log_Pos: 62110423
               Relay_Log_File: mysql-relay-bin-channel@002d241.000002
                Relay_Log_Pos: 1144
        Relay_Master_Log_File: mysql-bin.000257
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......
          Exec_Master_Log_Pos: 62110423
......
        Seconds_Behind_Master: 0
......
           Retrieved_Gtid_Set: 799ef59c-4126-11e7-83ce-00163e407cfb:53831090-53831093
            Executed_Gtid_Set: 799ef59c-4126-11e7-83ce-00163e407cfb:1-53831093,
f9b1a9b6-46b7-11e7-9e8b-00163e4fde29:1
                Auto_Position: 0
......

现在我们回到A库上，对表t_luoxiaobo插入一些测试数据：

qogir_env@localhost : luoxiaobo 12:43:30> insert into t_luoxiaobo(test,datet_time) values('test_replication',now());
Query OK, 1 row affected (0.00 sec)
qogir_env@localhost : luoxiaobo 01:36:31> select * from t_luoxiaobo where test='test_replication';
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| id      | test             | datet_time          | test1 | test2 | test3 | test4 | test5 | test6 | test8 | test7 | test9 |
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| 7470943 | test_replication | 2017-07-03 13:36:31 | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  |
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
1 row in set (0.96 sec)

在B库上查询复制状态和表t_luoxiaobo中的数据：

qogir_env@localhost : luoxiaobo 01:32:21> show slave status\G;
......
              Master_Log_File: mysql-bin.000257
          Read_Master_Log_Pos: 62110862
               Relay_Log_File: mysql-relay-bin-channel@002d241.000002
                Relay_Log_Pos: 1583
        Relay_Master_Log_File: mysql-bin.000257
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
......
          Exec_Master_Log_Pos: 62110862
......
        Seconds_Behind_Master: 0
......
           Retrieved_Gtid_Set: 799ef59c-4126-11e7-83ce-00163e407cfb:53831090-53831094
            Executed_Gtid_Set: 799ef59c-4126-11e7-83ce-00163e407cfb:1-53831094,
f9b1a9b6-46b7-11e7-9e8b-00163e4fde29:1
......
1 row in set (0.00 sec)
qogir_env@localhost : luoxiaobo 01:38:23> select * from t_luoxiaobo where test='test_replication';
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| id      | test             | datet_time          | test1 | test2 | test3 | test4 | test5 | test6 | test8 | test7 | test9 |
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
| 7470943 | test_replication | 2017-07-03 13:36:31 | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  | NULL  |
+---------+------------------+---------------------+-------+-------+-------+-------+-------+-------+-------+-------+-------+
1 row in set (0.05 sec)

到这里，看起来一切正常，对不对？开心吗？先等等，请保持DBA一贯严谨的优良传统，咱们在主库上使用pt-table-checksum工具检查一下：

# 删除了一部分无用信息，只保留了我们之前造数的两张表
[root@5f1772e3-0c7a-4537-97f9-9b57cf6a04c2 ~]# pt-table-checksum --nocheck-replication-filters  --no-check-binlog-format --replicate=xiaoboluo.checksums   \
h=localhost,u=admin,p=letsg0,P=3306
            TS ERRORS  DIFFS     ROWS  CHUNKS SKIPPED    TIME TABLE
07-03T13:57:48      0     16  2097153      18       0   7.543 luoxiaobo.t_luoxiaobo
07-03T13:57:57      0      0  2097152      18       0   9.281 luoxiaobo.t_luoxiaobo2
......

从上面的信息中可以看到，表luoxiaobo.t_luoxiaobo的检测DIFFS 列为16，代表主从有数据差异，神马情况？别急，咱们先来分别在AB库查询下这张表的数据行数，从下面的结果可以看到，该表主从数据差异2097152行！！

# A库
qogir_env@localhost : (none) 01:57:03> use luoxiaobo
Database changed
qogir_env@localhost : luoxiaobo 02:09:40> select count(*) from t_luoxiaobo;
+----------+
| count(*) |
+----------+
|  2097153 |
+----------+
1 row in set (0.41 sec)
B库
qogir_env@localhost : (none) 01:55:28> use luoxiaobo
Database changed
qogir_env@localhost : luoxiaobo 02:10:30> select count(*) from t_luoxiaobo;
+----------+
| count(*) |
+----------+
|        1 |
+----------+
1 row in set (0.00 sec)

发生什么了？也许你会说，平时使用mysqldump不都是这样的吗？没毛病啊。

回想一下，从咱们上篇《mysqldump与innobackupex备份过程知多少（二）》中提到的“WITH CONSISTENT SNAPSHOT语句的作用”时的演示过程可以知道，DDL的负载是刻意加上去的，还记得之前演示mysqldump使用savepoint的作用的时候，使用start transaction with consistent snapshot语句显式开启一个事务之后，该事务执行select之前，该表被其他会话执行了DDL之后无法查询数据，我们知道mysqldump备份数据的时候，就是在start transaction with consistent snapshot语句开启的一个一致性快照事务下使用select语句查询数据进行备份的。

为了证实这个问题，下面我们打开查询日志查看一下在start transaction with consistent snapshot语句和select … 之间是否有DDL语句，如下：

.......
2017-07-03T12:46:57.082727+08:00    1649664 Query   SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
2017-07-03T12:46:57.082889+08:00    1649664 Query   START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
......
2017-07-03T12:46:57.085821+08:00    1649664 Query   SELECT @@GLOBAL.GTID_EXECUTED
2017-07-03T12:46:57.085954+08:00    1649664 Query   SHOW MASTER STATUS
......
' # 这里可以看到，在START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */语句之后，select 备份表t_luoxiaobo表之前，有一个DDL语句插入进来'
2017-07-03T12:46:57.089833+08:00    1649667 Query   alter table t_luoxiaobo add column test8 varchar(10)
2017-07-03T12:46:57.095153+08:00    1649664 Query   UNLOCK TABLES
......
2017-07-03T12:46:57.098199+08:00    1649664 Init DB luoxiaobo
2017-07-03T12:46:57.098273+08:00    1649664 Query   SHOW CREATE DATABASE IF NOT EXISTS `luoxiaobo`
2017-07-03T12:46:57.098360+08:00    1649664 Query   SAVEPOINT sp
2017-07-03T12:46:57.098435+08:00    1649664 Query   show tables
2017-07-03T12:46:57.098645+08:00    1649664 Query   show table status like 't\_luoxiaobo'
2017-07-03T12:46:57.098843+08:00    1649664 Query   SET SQL_QUOTE_SHOW_CREATE=1
2017-07-03T12:46:57.098927+08:00    1649664 Query   SET SESSION character_set_results = 'binary'
2017-07-03T12:46:57.099013+08:00    1649664 Query   show create table `t_luoxiaobo`
2017-07-03T12:46:57.105056+08:00    1649664 Query   SET SESSION character_set_results = 'utf8'
2017-07-03T12:46:57.105165+08:00    1649664 Query   show fields from `t_luoxiaobo`
2017-07-03T12:46:57.105538+08:00    1649664 Query   show fields from `t_luoxiaobo`
'# 这里原本应该是一句：SELECT /*!40001 SQL_NO_CACHE */ * FROM `t_luoxiaobo`，但是却没有，我们可以推理一下，因为select的时候报了表定'\
'# 义已经发生变化的错误，所以这句select并没有被记录到查询日志中来'
2017-07-03T12:46:57.105857+08:00    1649664 Query   SET SESSION character_set_results = 'binary'
2017-07-03T12:46:57.105929+08:00    1649664 Query   use `luoxiaobo`
2017-07-03T12:46:57.106021+08:00    1649664 Query   select @@collation_database
2017-07-03T12:46:57.106116+08:00    1649664 Query   SHOW TRIGGERS LIKE 't\_luoxiaobo'
2017-07-03T12:46:57.106394+08:00    1649664 Query   SET SESSION character_set_results = 'utf8'
2017-07-03T12:46:57.106466+08:00    1649664 Query   ROLLBACK TO SAVEPOINT sp
2017-07-03T12:46:57.106586+08:00    1649664 Query   show table status like 't\_luoxiaobo2'
......
2017-07-03T12:46:57.107063+08:00    1649664 Query   show create table `t_luoxiaobo2`
2017-07-03T12:46:57.107151+08:00    1649664 Query   SET SESSION character_set_results = 'utf8'
2017-07-03T12:46:57.107233+08:00    1649664 Query   show fields from `t_luoxiaobo2`
2017-07-03T12:46:57.107511+08:00    1649664 Query   show fields from `t_luoxiaobo2`
2017-07-03T12:46:57.107807+08:00    1649664 Query   SELECT /*!40001 SQL_NO_CACHE */ * FROM `t_luoxiaobo2`
......

现在，我们打开备份文件，找到表t_luoxiaob的备份语句位置，可以看到并没有生成INSERT语句：

DROP TABLE IF EXISTS `t_luoxiaobo`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `t_luoxiaobo` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `test` varchar(50) COLLATE utf8_bin DEFAULT NULL,
  `datet_time` datetime DEFAULT NULL,
  `test1` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `test2` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `test3` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `test4` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  `test5` varchar(10) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7470943 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
/*!40101 SET character_set_client = @saved_cs_client */;
'# 正常情况下，在这个位置，应该出现LOCK TABLES `t_luoxiaobo` WRITE; + /*!40000 ALTER TABLE `t_luoxiaobo2` DISABLE KEYS */; + INSERT INTO语句的，然而，现在这里却是空的'
--
-- Table structure for table `t_luoxiaobo2`
--
DROP TABLE IF EXISTS `t_luoxiaobo2`;
......
LOCK TABLES `t_luoxiaobo2` WRITE;
/*!40000 ALTER TABLE `t_luoxiaobo2` DISABLE KEYS */;
INSERT INTO `t_luoxiaobo2` VALUES (1,'1','2017-07-03 09:22:16'),(4,'2','2017-07-03 09:22:19'),(7,'3','2017-07-03 09:22:21'),
......

到这里，是不是突然心弦一紧呢？so..如果你决定继续使用mysqldump，那么以后搭建好备库之后，一定要记得校验一下主备数据一致性！！

1.3.3 有办法改善这这些问题吗？

在寻找解决办法之前，咱们先来看看mysqldump的备份选项--single-transaction和--master-data[=value]的作用和使用限制。

--single-transaction

此选项将事务隔离模式设置为REPEATABLE READ，并在备份数据之前向server发送START TRANSACTION SQL语句以显示开启一个事务快照。仅适用于InnoDB这样的事务表，由于是在事务快照内进行备份，这样可以使得备份的数据与获取事务快照时的数据是一致的，而且不会阻塞任何应用程序对server的访问。

在进行单事务备份时，为确保有效的备份文件（正确的表内容和二进制日志位置），不能有其他连接应使用语句：ALTER TABLE，CREATE TABLE，DROP TABLE，RENAME TABLE，TRUNCATE等DDL语句。这会导致一致状态被破坏，可能导致mysqldump执行SELECT检索表数据时查询到不正确的内容或备份失败。

注意：该选项仅适用于事务引擎表，对于MyISAM或MEMORY表由于不支持事务，所以备份过程中这些引擎表的数据仍可能发生更改。

--master-data[=value]

使用此选项备份时会在备份文件中生成change master to语句，使用的binlog pos是使用的备份server自己的binlog pos，可使用备份文件用于将另一台服务器（恢复这个备份文件的服务器）设置为备份server的从库。

与--dump-slave选项类似，如果选项值为2，则CHANGE MASTER TO语句将作为SQL注释写入备份文件，因此仅供参考；当备份文件被重新加载时，这个注释不起作用。如果选项值为1，则该语句不会注释，并在重新加载备份文件时会生效（被执行）。如果未指定选项值，则默认值为1。

指定此选项的用户需要RELOAD权限，并且server必须启用二进制日志，因为这个位置是使用show master status获取的（如果没有开启log_bin参数，则show master status输出信息为空），而不是使用show slave status获取的。

--master-data选项自动关闭--lock-tables选项。同时还会打开--lock-all-tables，除非指定了--single-transaction选项，在指定了--single-transaction选项之后，只有在备份开始时间内才加全局读取锁。

so，--single-transaction选项中明确说明了如果使用了该选项，那么在备份期间如果发生DDL，则可能导致备份数据一致性被破坏，select检索不到正确的内容。另外，该选项仅仅只适用于事务引擎表，不适用于非事务引擎。作为DBA，很多时候是非常无奈的，虽然有各种规范，但是保不齐就是有漏网之鱼，这个时候，生活还得继续，工作还得做好，那么，有什么办法可以缓解这个问题吗？有的：

1) 就如同上文中演示步骤中那样，去掉--single-transaction选项进行备份，此时单独使用--master-data选项时会自动开启--lock-all-tables，备份过程中整个实例全程锁表，不会发生备份数据与获取的binlog pos点不一致的问题，这样，用该备份来搭建备库时就不会出现数据冲突。但是问题显而易见，备份期间数据库不可用，如果采用这种方法，至少需要在业务低峰期进行备份
2) 使用innobackupex备份工具

到这里，如何做选择就看你有什么样的需求了，下一篇我们将谈一谈innobackupex的备份过程和原理。

作者：罗小波
来源：沃趣科技（woqutech）

仲培艺

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
mysqldump与innobackupex备份过程知多少（三）

【前文传送门】mysqldump与innobackupex备份过程知多少（一）mysqldump与innobackupex备份过程知多少（二）1.3 mysqldump有什么坑吗？想必大家都知道，mysqldump备份时可以使用--single-transaction + --master-data两个选项执行备份（老实讲，为图方便，本人之前很长一段时间，生产库也是使用mysqldudmp远...
复制链接

扫一扫