mysqldump的备份原理
mysqldump在备份过程中,是采用查询备份相关表的数据,然后导出,拼接成insert语句的形式进行备份。
关于--single-transaction 和--lock-tables
--single-transaction选项和--lock-tables选项是互斥的,因为LOCK TABLES会使任何挂起的事务隐含提交
相关探究实验
1.开启mysql general log
2.对数据库进行备份
/usr/local/mysql/bin/mysqldump -uroot -p -h 127.0.0.1 --hex-blob -A --events --ignore-table=mysql.events --single-transaction --master-data=2 >/tmp/20160304alls.sql
在不同参数的配合下,备份方式有所不同,因为mysqldump是查询数据库的备份方式,所以我们开启general-log来查看mysqldump究竟如何完成备份过程。在备份过程中,获取对应的部分备份的执行的语句列表进行分析
--master-data=2
备份头部:
25646 Query /*!40100 SET @@SQL_MODE='' */
25646 Query /*!40103 SET TIME_ZONE='+00:00' */
25646 Query FLUSH /*!40101 LOCAL */ TABLES
25646 Query FLUSH TABLES WITH READ LOCK
25646 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
25646 Query START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
25646 Query SHOW VARIABLES LIKE 'gtid\_mode'
25646 Query SHOW MASTER STATUS
25646 Query UNLOCK TABLES
--master-data=2的作用:
这段代码,
通过FLUSH TABLES WITH READ LOCK ,然后SHOW MASTER STATUS,再然后UNLOCK TABLES,在这个过程中获取到了master在lock时刻的binlog,获取binlog位置的过程一定是在加锁后,这样才可以准确获取响应的binlog
位置,而这个位置,会在备份文件的-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000009', MASTER_LOG_POS=655717;来体现,非常适合用于点对点的备份恢复 (--master-data=2)
--single-transaction
5646 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
25646 Query START TRANSACTION /*!40100 WITH CONSISTENT SNAPSHOT */
25646 Query SHOW VARIABLES LIKE 'gtid\_mode'
25646 Query SHOW MASTER STATUS
25646 Query UNLOCK TABLES
25646 Query SELECT LOGFILE_GROUP_NAME, FILE_NAME, TOTAL_EXTENTS, INITIAL_SIZE, ENGINE, EXTRA FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'UNDO LOG' AND FILE_NAME IS NOT NULL GROUP BY LOGFILE_GROUP_NAME, FILE_NAME, ENGINE ORDER BY LOGFILE_GROUP_NAME
25646 Query SELECT DISTINCT TABLESPACE_NAME, FILE_NAME, LOGFILE_GROUP_NAME, EXTENT_SIZE, INITIAL_SIZE, ENGINE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE' ORDER BY TABLESPACE_NAME, LOGFILE_GROUP_NAME
25646 Query SHOW DATABASES
25646 Query SHOW VARIABLES LIKE 'ndbinfo\_version'
25646 Init DB hive
25646 Query SHOW CREATE DATABASE IF NOT EXISTS `hive`
25646 Query SAVEPOINT sp
25646 Query show tables
25646 Query show table status like 'bucketing\_cols'
25646 Query SET SQL_QUOTE_SHOW_CREATE=1
25646 Query SET SESSION character_set_results = 'binary'
25646 Query show create table `bucketing_cols`
25646 Query SET SESSION character_set_results = 'utf8'
25646 Query show fields from `bucketing_cols`
25646 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `bucketing_cols`
25646 Query SET SESSION character_set_results = 'binary'
25646 Query use `hive`
25646 Query select @@collation_database
25646 Query SHOW TRIGGERS LIKE 'bucketing\_cols'
25646 Query SET SESSION character_set_results = 'utf8'
25646 Query ROLLBACK TO SAVEPOINT sp
在搭配--single-transaction 参数后,会在FLUSH TABLES WITH READ LOCK 后添加START TRANSACTION 语句,用来开启
单一事务 ,
这个时候的加锁,仅仅是为了确定master-data中的binlog的具体位置和开启事务,开启事务后,就已经把读锁释放了,而且在由日志可以看出,在日志的回滚过程中,是回滚到单一的TRANSACTION,也是sp点,每次进行对表和参数的改动后,都会对事务进行回滚。 通过对备份log的分析,可以发现,所有的的备份阶段完成后,都是rollback到sp点的。也就是返回到
SAVEPOINT sp时间点,也就是备份完成后,实际上备份库仍然是在sp点,而这个所谓的sp回滚,其实是调用的undo中的数据快照来实现的。
使用--single-transaction 可以保证在备份过程中,整个备份集的数据一致性。
--lock-tables
14707 Query SET autocommit=0
14707 Query SELECT @@session.tx_isolation
14707 Query rollback
14707 Query SET autocommit=1
14707 Query set session transaction read write
14711 Query select @@session.tx_read_only
14711 Query SET autocommit=0
14711 Query SELECT @@session.tx_isolation
14711 Query SELECT 'org.apache.hadoop.hive.metastore.model.MDatabase' AS `NUCLEUS_TYPE`,`A0`.`DESC`,`A0`.`DB_LOCATION_URI`,`A0`.`NAME`,`A0`.`OWNER_NAME`,`A0`.`OWNER_TYPE`,`A0`.`DB_ID` FROM `DBS` `A0` WHERE `A0`.`NAME` = ''
14711 Query SELECT 'org.apache.hadoop.hive.metastore.model.MTableColumnStatistics' AS `NUCLEUS_TYPE`,`A0`.`AVG_COL_LEN`,`A0`.`COLUMN_NAME`,`A0`.`COLUMN_TYPE`,`A0`.`DB_NAME`,`A0`.`BIG_DECIMAL_HIGH_VALUE`,`A0`.`BIG_DECIMAL_LOW_VALUE`,`A0`.`DOUBLE_HIGH_VALUE`,`A0`.`DOUBLE_LOW_VALUE`,`A0`.`LAST_ANALYZED`,`A0`.`LONG_HIGH_VALUE`,`A0`.`LONG_LOW_VALUE`,`A0`.`MAX_COL_LEN`,`A0`.`NUM_DISTINCTS`,`A0`.`NUM_FALSES`,`A0`.`NUM_NULLS`,`A0`.`NUM_TRUES`,`A0`.`TABLE_NAME`,`A0`.`CS_ID` FROM `TAB_COL_STATS` `A0` WHERE `A0`.`DB_NAME` = ''
14711 Query SELECT 'org.apache.hadoop.hive.metastore.model.MPartitionColumnStatistics' AS `NUCLEUS_TYPE`,`A0`.`AVG_COL_LEN`,`A0`.`COLUMN_NAME`,`A0`.`COLUMN_TYPE`,`A0`.`DB_NAME`,`A0`.`BIG_DECIMAL_HIGH_VALUE`,`A0`.`BIG_DECIMAL_LOW_VALUE`,`A0`.`DOUBLE_HIGH_VALUE`,`A0`.`DOUBLE_LOW_VALUE`,`A0`.`LAST_ANALYZED`,`A0`.`LONG_HIGH_VALUE`,`A0`.`LONG_LOW_VALUE`,`A0`.`MAX_COL_LEN`,`A0`.`NUM_DISTINCTS`,`A0`.`NUM_FALSES`,`A0`.`NUM_NULLS`,`A0`.`NUM_TRUES`,`A0`.`PARTITION_NAME`,`A0`.`TABLE_NAME`,`A0`.`CS_ID` FROM `PART_COL_STATS` `A0` WHERE `A0`.`DB_NAME` = ''
14711 Query commit
14711 Query rollback
14711 Query SET autocommit=1
14711 Query set session transaction read write
--lock-tables
从日志可以看出,在采用该参数后,在每次的不同备份id的备份过程中,都会先开启一个事务,然后再提交,这样在整个备份过程中,会有多次的事务开启与提交过程,在备份过程中的大量事务的开启与关闭,这样势必会和带--single-transaction出现差距 。
我们可以得到如下结论:
1. 带--lock-tables参数的备份过程在时间上会比较长,而且这种时间的差距,在大表的时候会表现的更加明显
2. 带--lock-tables参数后,只会影响对应备份过程中的表,而不会对备份过后的表有所影响,但是在--single-transaction过程中,因为单一事务的检查点已经在刚开始时候就已经被确定为sp,所有的备份过程的回滚过程都是sp点,所以,即使备份完成后的表,也会受到事务内相关锁的影响。因此可见在--single-transaction备份过程中,虽然备份速度有所加快,但是对于数据库的影响时间也是比较长的。
3.带--lock-tables参数的情况下,并不能保证全库备份情况下的数据一致性。即所有的数据,不一定是在一个时间点的数据。
--lock-all-tables
14707 Query SET autocommit=0
14707 Query SELECT @@session.tx_isolation
14707 Query rollback
14707 Query SET autocommit=1
14707 Query set session transaction read write
14710 Query select @@session.tx_read_only
14710 Query SET autocommit=0
14710 Query SELECT @@session.tx_isolation
14710 Query SELECT 'org.apache.hadoop.hive.metastore.model.MDatabase' AS `NUCLEUS_TYPE`,`A0`.`DESC`,`A0`.`DB_LOCATION_URI`,`A0`.`NAME`,`A0`.`OWNER_NAME`,`A0`.`OWNER_TYPE`,`A0`.`DB_ID` FROM `DBS` `A0` WHERE `A0`.`NAME` = ''
14710 Query SELECT 'org.apache.hadoop.hive.metastore.model.MTableColumnStatistics' AS `NUCLEUS_TYPE`,`A0`.`AVG_COL_LEN`,`A0`.`COLUMN_NAME`,`A0`.`COLUMN_TYPE`,`A0`.`DB_NAME`,`A0`.`BIG_DECIMAL_HIGH_VALUE`,`A0`.`BIG_DECIMAL_LOW_VALUE`,`A0`.`DOUBLE_HIGH_VALUE`,`A0`.`DOUBLE_LOW_VALUE`,`A0`.`LAST_ANALYZED`,`A0`.`LONG_HIGH_VALUE`,`A0`.`LONG_LOW_VALUE`,`A0`.`MAX_COL_LEN`,`A0`.`NUM_DISTINCTS`,`A0`.`NUM_FALSES`,`A0`.`NUM_NULLS`,`A0`.`NUM_TRUES`,`A0`.`TABLE_NAME`,`A0`.`CS_ID` FROM `TAB_COL_STATS` `A0` WHERE `A0`.`DB_NAME` = ''
14710 Query SELECT 'org.apache.hadoop.hive.metastore.model.MPartitionColumnStatistics' AS `NUCLEUS_TYPE`,`A0`.`AVG_COL_LEN`,`A0`.`COLUMN_NAME`,`A0`.`COLUMN_TYPE`,`A0`.`DB_NAME`,`A0`.`BIG_DECIMAL_HIGH_VALUE`,`A0`.`BIG_DECIMAL_LOW_VALUE`,`A0`.`DOUBLE_HIGH_VALUE`,`A0`.`DOUBLE_LOW_VALUE`,`A0`.`LAST_ANALYZED`,`A0`.`LONG_HIGH_VALUE`,`A0`.`LONG_LOW_VALUE`,`A0`.`MAX_COL_LEN`,`A0`.`NUM_DISTINCTS`,`A0`.`NUM_FALSES`,`A0`.`NUM_NULLS`,`A0`.`NUM_TRUES`,`A0`.`PARTITION_NAME`,`A0`.`TABLE_NAME`,`A0`.`CS_ID` FROM `PART_COL_STATS` `A0` WHERE `A0`.`DB_NAME` = ''
14710 Query commit
14710 Query rollback
14710 Query SET autocommit=1
14710 Query set session transaction read write
虽然官方说,--lock-all-tables对所有的表都进行了加锁,但是我发现,其加锁过程和--lock-tables几乎是一致的。
如果你感觉上面讲的很乱,看结论就行了:
总结:
1.要实现点对点的备份恢复,或者对于某点的数据完整备份,必须使用--single-transaction 和--master-data=2两个参数,比如主从搭建时候的,因为在--single-transaction参数中,没可以保证数据备份的备份时间点的事务一致性
2.--single-transaction备份对于数据库的影响时间比较长,影响范围比较大 ,但是加入该参数后,对于多张大表的备份速度肯定会加快。
3.--lock-all-tables并不能保持所有数据对于某个时间点的一致性。