xtrabackup 重建 Slave 复制
一:物理全备
优先选择 基于slave 节点全备;当不存在可用的 slave 节点时,选择 master 节点备份
基于 slave 节点: innobackupex --defaults-file=/etc/my.cnf -S /tmp/mysql.sock --ftwrl-wait-threshold=2 --ftwrl-wait-timeout=3 --slave-info --host=127.0.0.1 --user=xxx --password=xxx --port=3306 --stream=tar /tmp | gzip - > t_back_2023.tar.gz 基于 master 节点: innobackupex --defaults-file=/etc/my.cnf -S /tmp/mysql.sock --ftwrl-wait-threshold=2 --ftwrl-wait-timeout=3 --host=127.0.0.1 --user=xxx --password=xxx --port=3306 --stream=tar /tmp | gzip - > t_back_2023.tar.gz eg: innobackupex --defaults-file=/data/mysql/mysql3306/my.cnf -S /data/mysql/mysql3306/var/mysql.sock --ftwrl-wait-threshold=2 --ftwrl-wait-timeout=3 --host=xx --user=root --password=xx --port=3306 --stream=xbstream /tmp | gzip - > t_back_2023.xb.gz # 出现如下关键字表示备份成功: InnoDB: FTS optimize thread exiting. InnoDB: Starting shutdown... InnoDB: Shutdown completed; log sequence number 715724708392 230306 17:21:48 completed OK!
二:恢复备份
1. 将备份文件解压缩到 mysql 的数据目录: tar -xf t_back_2023.tar.gz -C /home/mysql/data 2. 应用此目录下的事务日志文件 xtrabackup_logfile 到备份集解压后的路径中: innobackupex --defaults-file=/home/mysql/data/backup-my.cnf --apply-log /home/mysql/data # 出现如下关键字表示 recover 成功: xtrabackup: Transaction log of lsn (715329573149) to (715724704682) was copied. 230306 16:30:13 completed OK! 3. 启动实例: mysqld --defaults-file=/etc/my.cnf --user=mysql &
三: 与主库 建立复制关系
恢复备份以后,实例需要与主库建立复制关系,同步增量数据
• 基于 slave 节点 恢复备份时: 1. 清除 GTID 和 slave 复制信息: mysql> reset master; reset slave 2. 设置 gtid_purged: (1)查看 xtrabackup_slave_info 文件,该文件记录了gtid_purged 信息: eg: mysql> SET GLOBAL gtid_purged='294c965f-eacd-11e9-a9c7-20040ff27868:1-19942458; (2)配置 MASTER_AUTO_POSITION (通常是默认配置) mysql> CHANGE MASTER TO MASTER_AUTO_POSITION=1; (3)开启 slave 同步, 并确认复制状态 mysql> start slave; mysql> start slave; • 基于 master 节点 恢复备份时: 参考文件 xtrabackup_binlog_info 设置 gtid_purged,执行以上步骤 change master to master_host='xxx', master_user='repluser', master_password='12346', master_port=3306, master_auto_position=1;
备份流程 与 注意事项:
xtarbackup 在备份过程中会有加 FTWRL 全局锁的操作,此时整个实例处于只读状态,通常这个过程有几秒;但当 实例在发生 DDL 或长事务时,xtrabackup 备份时将拿不到 FTWRL 锁,
而在 FTWRL 语句之后的所有 DML/DDL 都将阻塞,表现上就像实例 hang 住了一样。如果是在 主库上执行 备份,那么业务无法读写是不能接受的;如果是在 slave 节点执行备份,将会导致 binlog 无法回放,复制延迟,从库有业务查询的时,也将阻塞。
综上,xtarbackup 备份数据,应该选择业务低峰期,优先从 slave 节点备份,且确保在备份时实例中 无长事务发生!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· TypeScript + Deepseek 打造卜卦网站:技术与玄学的结合
· Manus的开源复刻OpenManus初探
· 三行代码完成国际化适配,妙~啊~
· .NET Core 中如何实现缓存的预热?
· 如何调用 DeepSeek 的自然语言处理 API 接口并集成到在线客服系统