XtraBackup全备工作流程解读与总结

背景

出于对XtraBackup工作原理好奇，做了下面的日志解读

备份输出日志解读

[root@node1 09:23:35 /root]#time innobackupex --defaults-file=/data/mysql/mysql3306/my3306.cnf -S /tmp/mysql3306.sock -uroot -plmlm /data/backup/180525 09:24:24 innobackupex: Starting the backup operation#开始备份操作#为什么使用innobackupex，因为5.7及以前版本，mysql表是myisam引擎表，innobackupex可以备份所有引擎表IMPORTANT: Please check that the backup run completes successfully.           At the end of a successful backup run innobackupex           prints "completed OK!".#重要提示：请检查备份运行是否成功完成。#在成功的备份运行结束时，innobackupex会打印"completed OK!"，也就是完成状态是OK。180525 09:24:24  version_check Connecting to MySQL server with DSN 'dbi:mysql:;mysql_read_default_group=xtrabackup;port=3306;mysql_socket=/tmp/mysql3306.sock' as 'root'  (using password: YES).#版本检查：使用DSN连接到MySQL服务器，DSN是数据源名称，也就是连接数据库需要的参数。180525 09:24:24  version_check Connected to MySQL server180525 09:24:24  version_check Executing a version check against the server...#对服务器执行版本检查180525 09:24:24  version_check Done.180525 09:24:24 Connecting to MySQL server host: localhost, user: root, password: set, port: 3306, socket: /tmp/mysql3306.sockUsing server version 5.7.22-log#连接到MySQL服务器，使用的参数是：host=localhost,user=root,password=使用命令行输入的，但不打印进日志；port=3306,socket=/tmp/mysql3306.sock,使用的版本是5.7.22innobackupex version 2.4.11 based on MySQL server 5.7.19 Linux (x86_64) (revision id: b4e0db5)#innobackupex版本是2.4.11，是基于64位Linux的5.7.19版本的MySQL服务器xtrabackup: uses posix_fadvise().#xtrabckup：使用posix_fadvise()函数，这是程序的函数入口？xtrabackup: cd to /data/mysql/mysql3306/data#xtrabckup：cd到/data/mysql/mysql3306/data目录下xtrabackup: open files limit requested 65535, set to 65535#xtrabckup：打开文件请求限制65535，设置为65535xtrabackup: using the following InnoDB configuration:#xtrabckup：使用以下InnoDB配置信息xtrabackup:   innodb_data_home_dir = .#设置innodb数据的存放目录为当前目录xtrabackup:   innodb_data_file_path = ibdata1:100M:autoextend#设置innodb共享表空间文件的个数和初始分配大小值，autoextend是自动扩展xtrabackup:   innodb_log_group_home_dir = ./#设置innodb日志文件的存放目录为当前目录（.和./是等效的）xtrabackup:   innodb_log_files_in_group = 3#设置innodb日志文件的个数为3xtrabackup:   innodb_log_file_size = 104857600#设置innodb日志文件的大小为100Mxtrabackup: using O_DIRECT#使用无缓存的输入、输出InnoDB: Number of pools: 1#备份的线程是1个，还是线程池？不太明白180525 09:24:24 >> log scanned up to (2643241)#从2643241字节开始扫描日志xtrabackup: Generating a list of tablespaces#生成表空间列表InnoDB: Allocated tablespace ID 2 for mysql/plugin, old maximum was 0#为mysql/插件分配的表空间ID 2，旧的最大值为0180525 09:24:25 [01] Copying ./ibdata1 to /data/backup/2018-05-25_09-24-24/ibdata1180525 09:24:25 [01]        ...done#首先完成ibdata1的拷贝，这是存放innodb引擎表的元数据信息180525 09:24:25 [01] Copying ./mysql/plugin.ibd to /data/backup/2018-05-25_09-24-24/mysql/plugin.ibd180525 09:24:25 [01]        ...done#接着完成一堆ibd文件的拷贝，也就是innodb引擎表的数据和索引180525 09:24:25 [01] Copying ./mysql/servers.ibd to /data/backup/2018-05-25_09-24-24/mysql/servers.ibd180525 09:24:25 [01]        ...done.....省略部分输出......180525 09:24:25 [01] Copying ./db1/tb1.ibd to /data/backup/2018-05-25_09-24-24/db1/tb1.ibd180525 09:24:25 [01]        ...done180525 09:24:25 >> log scanned up to (2643241)#日志扫描到2643241180525 09:24:26 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...#执行刷新表的语句，作用是关闭所有打开的表，但是不记录到二进制日志里面180525 09:24:26 Executing FLUSH TABLES WITH READ LOCK...#执行FTWRL操作，对整个实例施加只读锁，只能读，不能写#实际他做的是关闭所有表，使用全局读锁来锁定所有数据库的所有表。180525 09:24:26 Starting to backup non-InnoDB tables and files#开始备份非innodb引擎表和文件，这里主要是为了备份mysql库，sys库和performance_schema库，因为该库下的表都是myisam引擎表#Performance Schema 收集数据库服务器性能参数，并且表的存储引擎均为PERFORMANCE_SCHEMA180525 09:24:26 [01] Copying ./mysql/db.opt to /data/backup/2018-05-25_09-24-24/mysql/db.opt180525 09:24:26 [01]        ...done.....省略部分输出......180525 09:24:26 [01] Copying ./performance_schema/session_status.frm to /data/backup/2018-05-25_09-24-24/performance_schema/session_status.frm180525 09:24:26 [01]        ...done180525 09:24:26 Finished backing up non-InnoDB tables and files#完成非innodb引擎表和文件的备份180525 09:24:26 [00] Writing /data/backup/2018-05-25_09-24-24/xtrabackup_binlog_info#往xtrabackup_binlog_info写入信息，也就是GTID执行过的值和binlog的位点信息180525 09:24:26 [00]        ...done180525 09:24:26 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...#执行FEL，但不记录到二进制日志#为已安装的存储引擎关闭和重新打开任何可刷新的日志。这是因为，InnoDB会把日志刷新到磁盘。xtrabackup: The latest check point (for incremental): '2643232'#有关自增的最后一个检查点是2643232xtrabackup: Stopping log copying thread.#停止日志拷贝线程.180525 09:24:26 >> log scanned up to (2643241)#日志扫描到2643241字节180525 09:24:26 Executing UNLOCK TABLES#执行UNLOCK TABLES，也就是是否全局读锁180525 09:24:26 All tables unlocked#所有的表解锁180525 09:24:26 [00] Copying ib_buffer_pool to /data/backup/2018-05-25_09-24-24/ib_buffer_pool180525 09:24:26 [00]        ...done#拷贝内存中的数据到相应的备份文件中180525 09:24:26 Backup created in directory '/data/backup/2018-05-25_09-24-24/'#备份创建在/data/backup/2018-05-25_09-24-24/目录里面MySQL binlog position: filename 'mysql-bin.000012', position '194', GTID of the last change '81c310cb-5428-11e8-8c27-080027801684:1-21'#打印出备份结束位点信息和执行过的GTID信息180525 09:24:26 [00] Writing /data/backup/2018-05-25_09-24-24/backup-my.cnf180525 09:24:26 [00]        ...done#开始写backup-my.cnf文件180525 09:24:26 [00] Writing /data/backup/2018-05-25_09-24-24/xtrabackup_info#开始写xtrabackup_info文件180525 09:24:26 [00]        ...donextrabackup: Transaction log of lsn (2643232) to (2643241) was copied.#lsn编号从2643232到2643241的事务日志已经拷贝完成180525 09:24:26 completed OK!real    0m2.122suser    0m0.177ssys     0m0.261s

general log解读

2018-05-26T06:31:22.661529Z         3 Connect   root@localhost on  using Socket2018-05-26T06:31:22.662086Z         3 Query     SET SESSION wait_timeout=21474832018-05-26T06:31:22.662627Z         3 Query     SELECT CONCAT(@@hostname, @@port)2018-05-26T06:31:22.666879Z         3 Quit2018-05-26T06:31:22.667426Z         4 Connect   root@localhost on  using Socket2018-05-26T06:31:22.667619Z         4 Query     SET SESSION wait_timeout=21474832018-05-26T06:31:22.667913Z         4 Query     SHOW VARIABLES#查看MySQL服务器的环境变量状态2018-05-26T06:31:22.670727Z         4 Query     SHOW ENGINE INNODB STATUS#查看InnoDB引擎状态信息2018-05-26T06:31:22.673329Z         4 Query     SELECT PLUGIN_NAME, PLUGIN_LIBRARY FROM information_schema.plugins WHERE PLUGIN_STATUS = 'ACTIVE' AND PLUGIN_TYPE = 'KEYRING'#查看活跃的类型是KEYRING的插件2018-05-26T06:31:22.674371Z         4 Query     SELECT  CONCAT(table_schema, '/', table_name), engineFROM information_schema.tablesWHERE engine NOT IN (  'MyISAM', 'InnoDB', 'CSV', 'MRG_MYISAM')AND table_schema NOT IN (  'performance_schema', 'information_schema',  'mysql')2018-05-26T06:31:23.984461Z         4 Query     SET SESSION lock_wait_timeout=315360002018-05-26T06:31:23.985374Z         4 Query     FLUSH NO_WRITE_TO_BINLOG TABLES2018-05-26T06:31:23.989832Z         4 Query     FLUSH TABLES WITH READ LOCK2018-05-26T06:31:24.392888Z         4 Query     SHOW MASTER STATUS#获取当前数据库的位置2018-05-26T06:31:24.393268Z         4 Query     SHOW VARIABLES2018-05-26T06:31:24.396572Z         4 Query     FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS#把日志刷到磁盘2018-05-26T06:31:24.603445Z         4 Query     UNLOCK TABLES2018-05-26T06:31:24.623980Z         4 Query     SELECT UUID()2018-05-26T06:31:24.625019Z         4 Query     SELECT VERSION()2018-05-26T06:31:24.835667Z         4 Quit

总结

第一阶段：检查与连接的准备阶段执行备份命令之后，备份开始，XtraBackup工具尝试去连接MySQL服务器，连接成功之后，执行MySQL版本检查，版本检查完毕。使用给定的用户、密码、端口、socket文件连接使用5.7.22版本的MySQL服务器。第二阶段：持续拷贝redo log这部分内容并没有在备份的输出日志里体现，推测通过开启general log可以看到，也不一定，也许要通过源码才能看到。修正：我的测试备份环境是一个静止的数据库，在备份时，既没有发生写操作，也没有发生读操作。所以没有看到一直在做"输出看到大量log scanned up to (xxx)，对应就是持续扫描redo log"第三阶段：拷贝ibdata1和ibd文件xtrabackup进程开始执行一系列工作1、调用系统函数posix_fadvise()，该函数是用来清理缓存的，不太理解此处使用的意图？了解的童鞋给我科普下，谢谢。2、进入到/data/mysql/mysql3306/data目录下面3、把打开文件请求限制调整为655354、使用以下InnoDB配置：innodb_data_home_dir = .#innodb数据存放在当前目录innodb_data_file_path = ibdata1:100M:autoextend#innodb共享表空间文件为1个，初始大小为100M，类型为自动扩展innodb_log_group_home_dir = ./#innodb日志文件存放在当前目录innodb_log_files_in_group = 3#innodb日志文件个数为3个innodb_log_file_size = 104857600#innodb日志文件大小为100M5、使用O_DIRECT标志，目的为绕过缓冲区高速缓存，直接把数据传递到文件或设备，实际就是无需缓存来拷贝数据6、默认使用单线程进行备份7、日志扫描到2643241字节的位置8、形成一个表表空间的列表9、为mysql/plugin分配表空间为2，旧的最大值是010、把ibdata1文件拷贝到备份目录下面，直到完成11、把ibd文件拷贝到备份目录下面，直到所有的ibd文件拷贝完成第四阶段：备份非事务表的准备阶段innobackupex进程开始执行一系列工作1、扫描日志文件到2643241，这是已经写入redo的LSN2、执行FLUSH TABLES，关闭所有打开的表，使用NO_WRITE_TO_BINLOG选项，也就是该语句不会被记录到binlog里面3、执行FTWRL，使用全局读锁来锁定整个实例第五阶段：备份非事务表开始拷贝非innodb引擎表和文件，包括所有的.frm文件等，直到所有的都拷贝完成修正：.frm文件：保存了每个表的元数据，包括表结构的定义等；.ibd文件：InnoDB引擎开启了独立表空间(my.ini中配置innodb_file_per_table = 1)产生的存放该表的数据和索引的文件。第六阶段：整个备份完成后的后续工作1、开始写xtrabackup_binlog_info文件，此处推测，获取执行过的GTID值和位点信息的语句在general log里面有记录2、执行引擎的日志刷新，也就是把日志刷新到磁盘3、最后的检查点是2643232字节的位置，也就是数据持久化到的LSN4、停止拷贝线程5、扫描日志文件到26432416、执行UNLOCK TABLES，释放全局读锁7、开始拷贝ib_buffer_pool，直到拷贝完成，这是一堆数字，不知道做什么用处，了解的童鞋给我科普下，谢谢。修正：拷贝缓冲池里的数据，以备恢复后，可以快速加载和预热访问量最高的数据。8、打印出备份结束的位点和执行过的GTID值9、写backup-my.cnf文件10、写xtrabckup_info11、LSN从2643232到2643241的事务日志拷贝完成12、打印备份成功的标志，completed OK!