20180207mydumper 备份流程

Posted 2020-10-23

mydumper备份流程

1. mydumper和mysqldump比对
   • mysqldump备份是属于单进程备份，mydumper备份属于多线程备份。
   • mysqldump备份innodb引擎表和非innodb引擎表的时候使用一致性备份的时候备份的非innodb引擎表的数据可能会和show master status 获取得到binlog的filename和position不一致，因为mysqldump备份的时候开启事务的时候，innodb引擎表是遵循MVCC版本控制的，但是非innodb引擎表并不会，再由于进行数据备份的时候是在unlock tables之后，在备份期间非innodb引擎的表是可以修改数据的。要是不想备份的binlog的filename,position信息和实际数据存在差异，那么就必须添加-x参数，这个参数和一致性快照参数是相互冲突的，并且这个参数会导致全表锁定，并且是整个备份过程都是锁定的状态直到备份完成。
   • mydumper备份innodb和非innodb引擎表混杂的情况下，会将所有非innodb引擎备份完毕之后执行unlock tables操作。
   • mysqldump备份将所以的库表备份到一个文件内。当数据很大的时候，想要针对备份的文件进行有些修改会非常的不方便。mydumper备份根据表为单位进行备份，每个表都会存在俩个文件，一个存放的是表的DML信息，一个存放的是表的数据信息。可以很明确的针对某个表进行的字符集或者存储引擎进行修改。
2. mydunper特性
   • 支持多线程备份
   • 因为多线程备份，所以会生成多个备份文件
   • 备份会执行flush tables with read lock,阻塞DML，防止MyISAM表的写入。备份完毕非innodb引擎表之后会unlock tables。
   • 保证备份文件的一致性
   • 支持压缩备份
   • 支持导出binlog文件
   • 支持多线程恢复
   • 支持以守护进程的方式工作，定时快照和连续二进制日志
   • 支持将备份文件切块

3. mydumper备份流程图

   • 备份的时候线程会优先级备份非innodb引擎表，在备份之前会flush tables with read lock 操作，防止非innodb引擎表的DML操作，备份完非innodb引擎表之后会执行unlock tables；然后继续备份innodb引擎表
   • mydumper的master进程会以守护进程的方式运行，生成N个(默认是4个)线程连接数据库，由这N个进程执行备份过程
   • 在开启事务之后，会执行show master status得到binlog的filename和position信息，这些信息将存放到metadata文件内。
     
4. mydumper参数：

   -B, --database              要备份的数据库，不指定则备份所有库
   -T, --tables-list           需要备份的表，名字用逗号隔开
   -o, --outputdir             备份文件输出的目录
   -s, --statement-size        生成的insert语句的字节数，默认1000000
   -r, --rows                  将表按行分块时，指定的块行数，指定这个选项会关闭 --chunk-filesize
   -F, --chunk-filesize        将表按大小分块时，指定的块大小，单位是 MB
   -c, --compress              压缩输出文件
   -e, --build-empty-files     如果表数据是空，还是产生一个空文件（默认无数据则只有表结构文件）
   -x, --regex                 是同正则表达式匹配 ‘db.table‘
   -i, --ignore-engines        忽略的存储引擎，用都厚分割
   -m, --no-schemas            不备份表结构
   -k, --no-locks              不使用临时共享只读锁，使用这个选项会造成数据不一致
   --less-locking              减少对InnoDB表的锁施加时间（这种模式的机制下文详解）
   -l, --long-query-guard      设定阻塞备份的长查询超时时间，单位是秒，默认是60秒（超时后默认mydumper将会退出）
   --kill-long-queries         杀掉长查询 (不退出)
   -b, --binlogs               导出binlog
   -D, --daemon                启用守护进程模式，守护进程模式以某个间隔不间断对数据库进行备份
   -I, --snapshot-interval     dump快照间隔时间，默认60s，需要在daemon模式下
   -L, --logfile               使用的日志文件名(mydumper所产生的日志), 默认使用标准输出
   --tz-utc                    跨时区是使用的选项，不解释了
   --skip-tz-utc               同上
   --use-savepoints            使用savepoints来减少采集metadata所造成的锁时间，需要 SUPER 权限
   --success-on-1146           Not increment error count and Warning instead of Critical in case of table doesn‘t exist
   -h, --host                  连接的主机名
   -u, --user                  备份所使用的用户
   -p, --password              密码
   -P, --port                  端口
   -S, --socket                使用socket通信时的socket文件
   -t, --threads               开启的备份线程数，默认是4
   -C, --compress-protocol     压缩与mysql通信的数据
   -V, --version               显示版本号
   -v, --verbose               输出信息模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为 2

5. myloader使用参数

   -d, --directory                   备份文件的文件夹
   -q, --queries-per-transaction     每次事物执行的查询数量，默认是1000
   -o, --overwrite-tables            如果要恢复的表存在，则先drop掉该表，使用该参数，需要备份时候要备份表结构
   -B, --database                    需要还原的数据库
   -e, --enable-binlog               启用还原数据的二进制日志
   -h, --host                        主机
   -u, --user                        还原的用户
   -p, --password                    密码
   -P, --port                        端口
   -S, --socket                      socket文件
   -t, --threads                     还原所使用的线程数，默认是4
   -C, --compress-protocol           压缩协议
   -V, --version                     显示版本
   -v, --verbose                     输出模式, 0 = silent, 1 = errors, 2 = warnings, 3 = info, 默认为2

6. 实际生产案例：
   • 备份单库

     mydumper -u root -p redhat -h 172.16.3.5 -B percona -o /data/backup/01/

   • 全量备份

     mydumper -u root -p redhat -h 172.16.3.5 -o /data/backup/02/

7. general log日志信息：

   2018-02-06T16:40:09.029354+08:00       32 Connect   [email protected] on  using Socket
   2018-02-06T16:40:09.029887+08:00       32 Query select @@version_comment limit 1
   2018-02-06T16:40:09.034432+08:00       32 Query select USER()
   2018-02-06T16:40:19.565214+08:00       32 Query select user,host from mysql.user
   2018-02-06T16:40:40.140267+08:00       33 Connect   [email protected] on  using TCP/IP
   2018-02-06T16:40:40.140991+08:00       33 Query select @@version_comment limit 1
   2018-02-06T16:40:41.137537+08:00       33 Quit
   2018-02-06T16:41:51.738271+08:00       34 Connect   [email protected] on percona using TCP/IP
   2018-02-06T16:41:51.749860+08:00       34 Query SET SESSION wait_timeout = 2147483
   2018-02-06T16:41:51.750298+08:00       34 Query SET SESSION net_write_timeout = 2147483
   2018-02-06T16:41:51.750792+08:00       34 Query SHOW PROCESSLIST
   2018-02-06T16:41:51.751269+08:00       34 Query FLUSH TABLES WITH READ LOCK
   2018-02-06T16:41:51.769610+08:00       34 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
   2018-02-06T16:41:51.770122+08:00       34 Query /*!40101 SET NAMES binary*/
   2018-02-06T16:41:51.770491+08:00       34 Query SHOW MASTER STATUS
   2018-02-06T16:41:51.771023+08:00       34 Query SHOW SLAVE STATUS
   2018-02-06T16:41:51.773673+08:00       35 Connect   [email protected] on  using TCP/IP
   2018-02-06T16:41:51.774198+08:00       35 Query SET SESSION wait_timeout = 2147483
   2018-02-06T16:41:51.774508+08:00       35 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
   2018-02-06T16:41:51.774774+08:00       35 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
   2018-02-06T16:41:51.775863+08:00       35 Query /*!40103 SET TIME_ZONE=‘+00:00‘ */
   2018-02-06T16:41:51.776238+08:00       35 Query /*!40101 SET NAMES binary*/
   2018-02-06T16:41:51.778248+08:00       36 Connect   [email protected] on  using TCP/IP
   2018-02-06T16:41:51.778647+08:00       36 Query SET SESSION wait_timeout = 2147483
   2018-02-06T16:41:51.778970+08:00       36 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
   2018-02-06T16:41:51.779241+08:00       36 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
   2018-02-06T16:41:51.779526+08:00       36 Query /*!40103 SET TIME_ZONE=‘+00:00‘ */
   2018-02-06T16:41:51.779846+08:00       36 Query /*!40101 SET NAMES binary*/
   2018-02-06T16:41:51.782079+08:00       37 Connect   [email protected] on  using TCP/IP
   2018-02-06T16:41:51.782491+08:00       37 Query SET SESSION wait_timeout = 2147483
   2018-02-06T16:41:51.782816+08:00       37 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
   2018-02-06T16:41:51.783157+08:00       37 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
   2018-02-06T16:41:51.783459+08:00       37 Query /*!40103 SET TIME_ZONE=‘+00:00‘ */
   2018-02-06T16:41:51.783857+08:00       37 Query /*!40101 SET NAMES binary*/
   2018-02-06T16:41:51.786025+08:00       38 Connect   [email protected] on  using TCP/IP
   2018-02-06T16:41:51.786435+08:00       38 Query SET SESSION wait_timeout = 2147483
   2018-02-06T16:41:51.786839+08:00       38 Query SET SESSION TRANSACTION ISOLATION LEVEL REPEATABLE READ
   2018-02-06T16:41:51.787132+08:00       38 Query START TRANSACTION /*!40108 WITH CONSISTENT SNAPSHOT */
   2018-02-06T16:41:51.787455+08:00       38 Query /*!40103 SET TIME_ZONE=‘+00:00‘ */
   2018-02-06T16:41:51.787835+08:00       38 Query /*!40101 SET NAMES binary*/
   2018-02-06T16:41:51.788283+08:00       34 Init DB   percona
   2018-02-06T16:41:51.788709+08:00       34 Query SHOW TABLE STATUS
   2018-02-06T16:41:51.791089+08:00       34 Query SHOW CREATE DATABASE `percona`
   2018-02-06T16:41:51.792056+08:00       36 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `percona`.`sbtest1`
   2018-02-06T16:41:51.792211+08:00       38 Query SHOW CREATE TABLE `percona`.`sbtest1`
   2018-02-06T16:41:51.792108+08:00       35 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `percona`.`sbtest2`
   2018-02-06T16:41:51.792123+08:00       37 Query SELECT /*!40001 SQL_NO_CACHE */ * FROM `percona`.`sbtest3`
   2018-02-06T16:41:51.793281+08:00       38 Query SHOW CREATE TABLE `percona`.`sbtest2`
   2018-02-06T16:41:51.794070+08:00       38 Query SHOW CREATE TABLE `percona`.`sbtest3`
   2018-02-06T16:41:51.798308+08:00       34 Query UNLOCK TABLES /* FTWRL */
   2018-02-06T16:41:51.798666+08:00       34 Quit
   2018-02-06T16:41:51.798843+08:00       37 Quit
   2018-02-06T16:41:51.798906+08:00       36 Quit
   2018-02-06T16:41:51.798951+08:00       38 Quit
   2018-02-06T16:41:51.799045+08:00       35 Quit

8. 在上诉日志中，innodb引擎表也是在unlock tables之前就做备份那是因为备份的时候总共就只有3个表，但是存在备份的线程存在4个，非innodb引擎表和innodb引擎表都在创建线程开始的时候就开始备份，在这个期间备份非innodb引擎表的时候是全局读锁，这个时候也已经开始备份innodb引擎表，所以在日志可以看到在备份innodb引擎表的时候是没有unlock tables的。