image.png
xtrabackup为了完成备份会做两个主要的工作：
- xtrabackup会在后台开启一个log-copying的线程，该线程会对redo log file进行监视，并把从lsn1(lsn1是Xtrabackup在启动时会从redo log file中获取最近一次的checkpoint对应的log sequence number lsn1 )开始增加的数据块（日志记录）不断的复制到备份集中一个叫xtrabackup_logfile的文件里面。日志copy操作，会在整个备份过程中一直进行，因为备份集做恢复的时候需要从lsn1开始到备份结束时所有日志记录，恢复原理就是 crash recover 的过程。
注：- log-copying 线程每一秒都会去 check 事务日志，看是否有新写入的需要copy走的日志项.但是有种可能性：
- 如果log-copying 线程的copy的速度比写入redofile 的速度慢，有可能事务日志循环一周，造成会有一部分日志
还没有被读取就被覆盖了,此时 log-copying 线程会报错，备份失败。
- xtrabackup在进行copy redo 日志的同时会copy innodb的data file ， 当然这不是简单的复制，它使用了跟innodb类似的方式访问数据文件,访问数据字典，并以数据页为单位来进行copy。具体的细节如下：
- xtrabackup是以读写的方式打开数据文件的，尽管它不会修改数据。这是因为它使用内置的innodb的lib库
来访问数据文件的，也隐含了你要用对数据文件有读写权限的用户来进行备份。innodb的lib库使用读写方式打
开是因为正常情况下打开文件就预示着写数据。 -
在copy数据到备份目标目录的过程中，xtrabackup 每次读取1M数据（不可配置），copy日志文件的时候，
每次读写512字节，同样不可以配置。数据读取之后，xtrabackup会对这1M的缓存数据块进行扫描，并对每一个
数据页使用buf_page_is_corrupted()函数进行验证，看起是否损坏，如果page损坏了，对其重新读取并重新
验证。如果重读10次都失败了，本次备份失败，那么备份失败。
注意: 跳过了doublewrite buffer
image.png
- xtrabackup是以读写的方式打开数据文件的，尽管它不会修改数据。这是因为它使用内置的innodb的lib库
- innobackupex 在启动后，会先 fork 一个进程，启动 xtrabackup进程，然后就等待 xtrabackup 备份完 ibd 数据文件；
- xtrabackup 在备份 InnoDB 相关数据时，是有2种线程的，1种是 redo 拷贝线程，负责拷贝 redo 文件，1种是 ibd 拷贝线程，负责拷贝 ibd 文件；redo 拷贝线程只有一个，在 ibd 拷贝线程之前启动，在 ibd 线程结束后结束。xtrabackup 进程开始执行后，先启动 redo 拷贝线程，从最新的 checkpoint 点开始顺序拷贝 redo 日志；然后再启动 ibd 数据拷贝线程，在 xtrabackup 拷贝 ibd 过程中，innobackupex 进程一直处于等待状态（等待文件被创建）。
- xtrabackup 拷贝完成idb后，通知 innobackupex（通过创建文件），同时自己进入等待（redo 线程仍然继续拷贝）;
- innobackupex 收到 xtrabackup 通知后，执行FLUSH TABLES WITH READ LOCK (FTWRL)，取得一致性位点，然后开始备份非 InnoDB 文件（包括 frm、MYD、MYI、CSV、opt、par等）。拷贝非 InnoDB 文件过程中，因为数据库处于全局只读状态，如果在业务的主库备份的话，要特别小心，非 InnoDB 表（主要是MyISAM）比较多的话整库只读时间就会比较长，这个影响一定要评估到。
- 当 innobackupex 拷贝完所有非 InnoDB 表文件后，通知 xtrabackup（通过删文件） ，同时自己进入等待（等待另一个文件被创建）；
- xtrabackup 收到 innobackupex 备份完非 InnoDB 通知后，就停止 redo 拷贝线程，然后通知 innobackupex redo log 拷贝完成（通过创建文件）；
- innobackupex 收到 redo 备份完成通知后，就开始解锁，执行 UNLOCK TABLES；
- 最后 innobackupex 和 xtrabackup 进程各自完成收尾工作，如资源的释放、写备份元数据信息等，innobackupex 等待 xtrabackup 子进程结束后退出。
网友评论