mysql备份恢复之-xtrabackup原理
mysql备份恢复之-xtrabackup原理
一、前言
• 快速可靠地完成备份。
• 在备份期间不间断地处理事务。
• 节省磁盘空间和网络带宽。
• 自动备份验证。
• 更快地恢复,以保障业务有更长的在线时间。
二、完全备份与恢复原理
(2)完全备份流程解析
• innobackupex在开始备份时,首先使用指定的账号和密码连接MySQL,该数据库 连接用于在备份过程中执行如加锁、解锁,刷新redo日志等与数据库进行交互操作。
• 读取--defaults-file选项指定的配置文件,解析innodb_data_home_dir和innodb_log_ group_home_dir等系统参数,找到数据表空间和redo日志文件的位置。
创建 xtrabackup_logfile文件,模拟MySQL实例方式,以读写模式打开并读取redo日志,检查当 前检查点,从当前检查点位置开始复制redo日志,
同时持续扫描redo日志,有新产生的 redo日志数据就复制到xtrabackup_logfile文件中(在整个备份过程中一直在复制redo日 志,通过查看备份目录下的xtrabackup_logfile文件,
可以看到这个文件在不断增长)。
• 另外一个线程调用xtrabackup命令开始复制数据文件(包括共享表空间文件和独立 表空间文件,相当于获得了redo日志、undo日志和数据文件,只是没有内存中的脏页数 据,
不过没有关系,直接用redo日志来恢复就可以了)。
• 全局执行FLUSH TABLES WITH READ LOCK语句(下文中提到的FTWRL为该语 句的简写)加一个S锁,此时数据库处于不可写状态(执行FLUSH TABLES WITH READ
LOCK语句的目的是为了防止读取数据时发生DDL操作,并且获取binlog文件位置)。 redo日志暂时也会卡在这里。
• 开始复制表结构文件,即.MYD和.MYI文件(由于前面步骤会锁定表,所以如果 数据库中有很大的MyISAM表就要注意了,会一直锁定到MyISAM的.MYD、.MYI、.frm
文件复制完成且获取了binlog文件位置之后才解锁。如果没有MyISAM表,那么在复制完
表空间文件之后的操作是非常快的,可能不到1分钟就完成了复制表.frm文件,获取到 binlog文件位置。
• 先执行FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS语句将InnoDB层的redo日 志持久化到磁盘后进行复制(因为xtrabackup并不备份二进制日志,所以,如果这个过程出现问题,
就会导致恢复之后丢失redo日志中的数据,做主从复制可能会同步出错,但在 XtraBackup 2.2.3之后不会再出现丢失redo日志的情况),
然后停止读redo日志复制的线 程。需要注意,innobackupex备份数据的时间点是停止redo日志复制时的数据对应的时间 点。
• 当redo日志的复制线程停止之后,执行UNLOCK TABLES语句解锁表。
• innobackupex完成收尾工作,如释放资源、记录与备份相关的元数据信息等(例如 backup-my.cnf和xtrabackup_info文件),
最后退出innobackupex备份进程(在XtraBackup 2.3之前的版本中,innobackupex和xtrabackup是两个程序,innobackupex需要等待 xtrabackup子进程结束后再退出。
关于两个程序之间的协调下文中会详细介绍,这里不再 赘述)。