宝哥软件园

全站导航

资讯攻略

安卓应用

手机游戏

首页 > 资讯攻略 > 编程开发 > 正文

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

编辑：宝哥软件园 来源：互联网 时间：2020-05-13
战地模拟器

战地模拟器

策略游戏 | 156.0M

5
评分
立即下载

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 statusG;
*************************** 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 statusG;
*************************** 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 statusG;
......
              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 statusG;
......
              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，很多时候是非常无奈的，虽然有各种规范，但是保不齐就是有漏网之鱼，这个时候，生活还得继续，工作还得做好， 那么，有什么办法可以缓解这个问题吗？有的：

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