备份防的是三种死法前几篇处理的都是活着的副本复制、选举、路由防的是机器死。但生产数据还有另外两种死法逻辑死——误删表、坏发布写脏数据、勒索加密这些会顺着复制链在毫秒内传播到所有从库副本越多死得越齐历史死——数据需要回到某时刻之前而在线系统只会向前。备份体系防的就是后两种它也因此成为整个容灾架构里唯一不能被复制替代的组件。本篇把三种主流手段——mysqldump 逻辑备份、XtraBackup 物理备份、文件系统/云盘快照——各自的机制、一致性与时间账算清楚第 7 篇再讲如何用它们把时间拨回去。三种备份各买哪种一致性mysqldump一致性快照的 SQL 转写。核心参数--single-transaction导出前开一个 REPEATABLE READ 事务借 MVCC 拿到一个冻结的读视图整个导出过程所见数据都停在这一刻只适用于事务引擎导出中途的 DDL 会破坏快照8.0 应配--tidl思路的替代——禁止并行 DDL 或错开窗口。--source-data28.0.26 前叫--master-data在导出文件头部写入CHANGE REPLICATION SOURCE TO注释文件名位点或 GTID 集这是第 7 篇 PITR 的锚点。它买到的是应用级一致点跨表外键、守恒关系都对代价是单线程逐表 SELECT INSERT 文本慢、体积大、恢复要重放 SQL 并重建索引。适合十 GB 级、或需要跨版本/跨引擎迁移的场景mydumper/mysqlsh util.dumpInstance的并行导出缓解了备份侧恢复侧依旧受限。XtraBackup热拷数据页 redo 尾巴。它绕过 Server 层直接拷 InnoDB 的.ibd/系统表空间因此不需要冻结 SQL但页与页的拷贝发生在不同瞬间天然不是一个一致点。它用两件事把账做平备份期间持续捕获 redo log备份结束前做一个检查点恢复--prepare时从检查点 LSN 重放 redo——页比检查点新的记录跳过比检查点老的补齐等价于一次定向的崩溃恢复把散落的时间戳拉回同一终点。所以 XtraBackup 的备份速度接近磁盘裸速、恢复也快一个量级但它买的只是一致性页面的集合逻辑错误把错删也备份进来照单全收。8.0 时代的主流实现是 Percona XtraBackup。快照断电一致性的拷贝。LVM/Storage Spaces/云盘快照在fsfreeze配合下把写入暂停几秒拿到块级一致点不 freeze 时得到的等价于突然拔电——InnoDB 能靠 redo 恢复crash recovery但应用层半执行的业务状态不受保护。快照的真正价值是速度与时空覆盖分钟级拿到全库、云快照天然跨区复制、配合 CBT变化块跟踪做增量链。它与备份完成之间还差一步快照是实例级而非表级恢复粒度粗回滚动作会吞掉快照点之后的全部数据必须有配套的 binlog 归档兜底。实验一500GB 库的时间账先算账再选型。以下模型按导出/重放/拷贝/回放四段速率估算估算值非实机测量看三种方式的备份窗口与整库恢复时长。DB_GB,CHURN500,0.05# 库大小, 日变更比例DUMP_MBPS,REPLAY_MBPS60,22# mysqldump 导出 / SQL 重放(含建索引)COPY_MBPS,REDO_MBPS250,400# 物理拷贝带宽 / redo 回放量速dbDB_GB*1024# MBday_redodb*CHURN# 当日 redo 量(用于物理备份追尾)defhrs(sec):returnsec/3600.0print(库 %dGB, 日变更 %dGB(%.0f%%)%(DB_GB,day_redo/1024,CHURN*100))dump_bakdb/DUMP_MBPS dump_resdb/REPLAY_MBPSprint(mysqldump: 备份 %.1fh, 整库恢复 %.1fh, RPO 取决于 dump 频率(binlog 另算)%(hrs(dump_bak),hrs(dump_res)))xb_bakdb/COPY_MBPSday_redo/REDO_MBPS xb_resdb/COPY_MBPSday_redo/REDO_MBPSprint(XtraBackup 全量: 备份 %.1fh(热拷页追redo尾), 恢复 %.1fh(拷回崩溃恢复)%(hrs(xb_bak),hrs(xb_res)))lvm_freeze2.0lvm_baklvm_freezedb/COPY_MBPS lvm_resdb/COPY_MBPSprint(LVM/云盘快照: 冻结 %.0fs 后台拷贝 %.1fh, 恢复需 crash recovery %.1fh%(lvm_freeze,hrs(db/COPY_MBPS),hrs(lvm_res*0.2)))print(\n把 RPO 补齐靠 binlog 连续归档, 与备份方式无关:)pitrxb_resdb*0.02/REDO_MBPS/60print( PITR 追加成本 距上次全量的 binlog 重放时长; 全量间隔越长, RTO 越长, 这是备份策略的核心权衡)print(\n压缩与传输(dump 侧收益最大): gzip 后 mysqldump 体积约 %.0f%%, 异地传输带宽 100MB/s 时:%25)print( dump 传输 %.1fh - 压缩后 %.1fh; 物理备份本身已近磁盘裸速, 压缩主要省存储不省时间%(hrs(dump_bak),hrs(dump_bak)*0.6))运行输出库 500GB, 日变更 25GB(5%) mysqldump: 备份 2.4h, 整库恢复 6.5h, RPO 取决于 dump 频率(binlog 另算) XtraBackup 全量: 备份 0.6h(热拷页追redo尾), 恢复 0.6h(拷回崩溃恢复) LVM/云盘快照: 冻结 2s 后台拷贝 0.6h, 恢复需 crash recovery 0.1h 把 RPO 补齐靠 binlog 连续归档, 与备份方式无关: PITR 追加成本 距上次全量的 binlog 重放时长; 全量间隔越长, RTO 越长, 这是备份策略的核心权衡 压缩与传输(dump 侧收益最大): gzip 后 mysqldump 体积约 25%, 异地传输带宽 100MB/s 时: dump 传输 2.4h - 压缩后 1.4h; 物理备份本身已近磁盘裸速, 压缩主要省存储不省时间这张表读出的不是谁快谁慢而是三段的分工全量备份决定恢复地板RTO 下限binlog 归档决定 RPO 上限两者相乘才等于真实风险敞口。500GB 级别 mysqldump 的 6.5 小时恢复已不可接受物理备份或快照是唯一选项而逻辑备份并未出局——它在表级抢救、跨版本迁移、以及给数仓喂一份可 grep 的数据这些物理手段到不了的点位上不可替代。成熟体系几乎都是物理全量 binlog 连续归档 少量逻辑备份做逃生舱。实验二被撕开的账本——不带 redo 的热拷长什么样把为什么物理拷贝必须配 redo做成一个可复算的账100 个账户每页 100 元、总额守恒 1000020 笔转账每秒一笔热拷贝每秒拷一页。拷贝结束后的账面与真相差多少再从检查点 LSN 重放 redo 看能否收敛。N_ACCOUNT,INIT100,100# 每页一个账户, 守恒总额 10000ops[]# (seq, 出账方, 入账方): 20 笔转账forkinrange(20):ops.append((5*(k1),(3*k)%N_ACCOUNT,(3*k7)%N_ACCOUNT))naive,page_lsn{},{}forpginrange(N_ACCOUNT):val,lsnINIT,0forseq,a,binops:ifseqpg1and(apgorbpg):val-1ifapgelse1lsnseq naive[pg],page_lsn[pg]val,lsnprint(守恒校验(朴素热拷): 应为 %d, 实际 %d, 差额 %d 元 - 跨页事务被撕开%(N_ACCOUNT*INIT,sum(naive.values()),sum(naive.values())-N_ACCOUNT*INIT))tornsum(1forseq,a,binopsif(seqa1)!(seqb1))print(被撕开的转账: %d / %d 笔(一端页已拷、另一端未拷)%(torn,len(ops)))final,applied,skippeddict(naive),0,0forseq,a,binops:forpg,deltain((a,-1),(b,1)):ifpage_lsn[pg]seq:final[pg]delta page_lsn[pg]seq applied1else:skipped1print(\nredo 重放: 生效 %d 条页级记录, 跳过 %d 条(页比检查点更新, 天然幂等)%(applied,skipped))print(守恒校验(redo 追平后): 总额 %d, 差额 %d - 所有页停在同一逻辑终点%(sum(final.values()),sum(final.values())-N_ACCOUNT*INIT))fixedsum(1forpginnaiveifnaive[pg]!final[pg])print(修正了 %d 个拷早了的页, 其余 %d 页原样可用%(fixed,N_ACCOUNT-fixed))print(\n边界: LVM/云盘快照 断电一致性(等价 crash, 靠 crash recovery 收敛, 不指定应用一致点))print(fsfreeze 防的是页内撕裂, --single-transaction 防的是跨页撕账——热备必须两样都有)运行输出守恒校验(朴素热拷): 应为 10000, 实际 10002, 差额 2 元 - 跨页事务被撕开 被撕开的转账: 2 / 20 笔(一端页已拷、另一端未拷) redo 重放: 生效 38 条页级记录, 跳过 2 条(页比检查点更新, 天然幂等) 守恒校验(redo 追平后): 总额 10000, 差额 0 - 所有页停在同一逻辑终点 修正了 38 个拷早了的页, 其余 62 页原样可用 边界: LVM/云盘快照 断电一致性(等价 crash, 靠 crash recovery 收敛, 不指定应用一致点) fsfreeze 防的是页内撕裂, --single-transaction 防的是跨页撕账——热备必须两样都有最值得注意的是钱凭空多出来的方向撕开的转账里入账端被拷进、出账端没拷进备份账面比现实多出两元。这类静默的守恒破坏不会让任何文件报错只有在恢复后跑对账才能暴露——这解释了为什么备份体系必须内建恢复验证而不是备份任务绿灯 数据安全。redo 重放的幂等性LSN 已追过的记录直接跳过正是 XtraBackup--prepare的语义内核也是随便什么顺序拷页都能收敛的底气。体系落地清单全量频率按恢复时长 全量恢复 binlog 重放倒推RTO 预算 4 小时500GB 库就绝不允许一周一次全量。binlog 归档独立于备份任务连续、带确认第 3 篇的 binlog server 顺手兼任断流要告警——RPO 全靠它。遵守 3-2-13 份副本、2 种介质、1 份离线/不可变对象存储 WORM/冷备勒索软件最先删的就是在线备份目录。每季度随机抽一个备份做真恢复恢复到临时实例、跑CHECK TABLE、抽样对账守恒关系、行数、checksum并把 RTO 实测值记录在案没恢复验证过的备份等于没有备份。备份要带坐标全量文件头记录对应的 GTID 集/binlog 位点--source-data、xtrabackup_info、START-SLAVE-POINTER没有坐标的备份进不了 PITR 链条。表级逃生通道确认 mysqldump 单表导出/导入演练过含外键与触发器误删单表的场景等不起整库恢复。备份有了、坐标有了下一篇把它用起来《数据库高可用与容灾实战7PITR 时间点恢复把误删的数据找回来》——如何用一份全量加两天空白日志把被DROP TABLE的账本精确恢复到误删前一秒。参考来源MySQL 8.0 Reference ManualDatabase Backup Methodshttps://dev.mysql.com/doc/refman/8.0/en/backup-methods.htmlMySQL 8.0 Reference Manualmysqldumphttps://dev.mysql.com/doc/refman/8.0/en/mysqldump.htmlPercona XtraBackup 8.0 Documentationhttps://docs.percona.com/percona-xtrabackup/8.0/en/introduction.htmlWikipediaSnapshot (computer storage)https://en.wikipedia.org/wiki/Snapshot_(computer_storage)WikipediaBackuphttps://en.wikipedia.org/wiki/Backup
数据库高可用与容灾实战（6）：备份体系设计：mysqldump、XtraBackup 与快照的边界
备份防的是三种死法前几篇处理的都是活着的副本复制、选举、路由防的是机器死。但生产数据还有另外两种死法逻辑死——误删表、坏发布写脏数据、勒索加密这些会顺着复制链在毫秒内传播到所有从库副本越多死得越齐历史死——数据需要回到某时刻之前而在线系统只会向前。备份体系防的就是后两种它也因此成为整个容灾架构里唯一不能被复制替代的组件。本篇把三种主流手段——mysqldump 逻辑备份、XtraBackup 物理备份、文件系统/云盘快照——各自的机制、一致性与时间账算清楚第 7 篇再讲如何用它们把时间拨回去。三种备份各买哪种一致性mysqldump一致性快照的 SQL 转写。核心参数--single-transaction导出前开一个 REPEATABLE READ 事务借 MVCC 拿到一个冻结的读视图整个导出过程所见数据都停在这一刻只适用于事务引擎导出中途的 DDL 会破坏快照8.0 应配--tidl思路的替代——禁止并行 DDL 或错开窗口。--source-data28.0.26 前叫--master-data在导出文件头部写入CHANGE REPLICATION SOURCE TO注释文件名位点或 GTID 集这是第 7 篇 PITR 的锚点。它买到的是应用级一致点跨表外键、守恒关系都对代价是单线程逐表 SELECT INSERT 文本慢、体积大、恢复要重放 SQL 并重建索引。适合十 GB 级、或需要跨版本/跨引擎迁移的场景mydumper/mysqlsh util.dumpInstance的并行导出缓解了备份侧恢复侧依旧受限。XtraBackup热拷数据页 redo 尾巴。它绕过 Server 层直接拷 InnoDB 的.ibd/系统表空间因此不需要冻结 SQL但页与页的拷贝发生在不同瞬间天然不是一个一致点。它用两件事把账做平备份期间持续捕获 redo log备份结束前做一个检查点恢复--prepare时从检查点 LSN 重放 redo——页比检查点新的记录跳过比检查点老的补齐等价于一次定向的崩溃恢复把散落的时间戳拉回同一终点。所以 XtraBackup 的备份速度接近磁盘裸速、恢复也快一个量级但它买的只是一致性页面的集合逻辑错误把错删也备份进来照单全收。8.0 时代的主流实现是 Percona XtraBackup。快照断电一致性的拷贝。LVM/Storage Spaces/云盘快照在fsfreeze配合下把写入暂停几秒拿到块级一致点不 freeze 时得到的等价于突然拔电——InnoDB 能靠 redo 恢复crash recovery但应用层半执行的业务状态不受保护。快照的真正价值是速度与时空覆盖分钟级拿到全库、云快照天然跨区复制、配合 CBT变化块跟踪做增量链。它与备份完成之间还差一步快照是实例级而非表级恢复粒度粗回滚动作会吞掉快照点之后的全部数据必须有配套的 binlog 归档兜底。实验一500GB 库的时间账先算账再选型。以下模型按导出/重放/拷贝/回放四段速率估算估算值非实机测量看三种方式的备份窗口与整库恢复时长。DB_GB,CHURN500,0.05# 库大小, 日变更比例DUMP_MBPS,REPLAY_MBPS60,22# mysqldump 导出 / SQL 重放(含建索引)COPY_MBPS,REDO_MBPS250,400# 物理拷贝带宽 / redo 回放量速dbDB_GB*1024# MBday_redodb*CHURN# 当日 redo 量(用于物理备份追尾)defhrs(sec):returnsec/3600.0print(库 %dGB, 日变更 %dGB(%.0f%%)%(DB_GB,day_redo/1024,CHURN*100))dump_bakdb/DUMP_MBPS dump_resdb/REPLAY_MBPSprint(mysqldump: 备份 %.1fh, 整库恢复 %.1fh, RPO 取决于 dump 频率(binlog 另算)%(hrs(dump_bak),hrs(dump_res)))xb_bakdb/COPY_MBPSday_redo/REDO_MBPS xb_resdb/COPY_MBPSday_redo/REDO_MBPSprint(XtraBackup 全量: 备份 %.1fh(热拷页追redo尾), 恢复 %.1fh(拷回崩溃恢复)%(hrs(xb_bak),hrs(xb_res)))lvm_freeze2.0lvm_baklvm_freezedb/COPY_MBPS lvm_resdb/COPY_MBPSprint(LVM/云盘快照: 冻结 %.0fs 后台拷贝 %.1fh, 恢复需 crash recovery %.1fh%(lvm_freeze,hrs(db/COPY_MBPS),hrs(lvm_res*0.2)))print(\n把 RPO 补齐靠 binlog 连续归档, 与备份方式无关:)pitrxb_resdb*0.02/REDO_MBPS/60print( PITR 追加成本 距上次全量的 binlog 重放时长; 全量间隔越长, RTO 越长, 这是备份策略的核心权衡)print(\n压缩与传输(dump 侧收益最大): gzip 后 mysqldump 体积约 %.0f%%, 异地传输带宽 100MB/s 时:%25)print( dump 传输 %.1fh - 压缩后 %.1fh; 物理备份本身已近磁盘裸速, 压缩主要省存储不省时间%(hrs(dump_bak),hrs(dump_bak)*0.6))运行输出库 500GB, 日变更 25GB(5%) mysqldump: 备份 2.4h, 整库恢复 6.5h, RPO 取决于 dump 频率(binlog 另算) XtraBackup 全量: 备份 0.6h(热拷页追redo尾), 恢复 0.6h(拷回崩溃恢复) LVM/云盘快照: 冻结 2s 后台拷贝 0.6h, 恢复需 crash recovery 0.1h 把 RPO 补齐靠 binlog 连续归档, 与备份方式无关: PITR 追加成本 距上次全量的 binlog 重放时长; 全量间隔越长, RTO 越长, 这是备份策略的核心权衡 压缩与传输(dump 侧收益最大): gzip 后 mysqldump 体积约 25%, 异地传输带宽 100MB/s 时: dump 传输 2.4h - 压缩后 1.4h; 物理备份本身已近磁盘裸速, 压缩主要省存储不省时间这张表读出的不是谁快谁慢而是三段的分工全量备份决定恢复地板RTO 下限binlog 归档决定 RPO 上限两者相乘才等于真实风险敞口。500GB 级别 mysqldump 的 6.5 小时恢复已不可接受物理备份或快照是唯一选项而逻辑备份并未出局——它在表级抢救、跨版本迁移、以及给数仓喂一份可 grep 的数据这些物理手段到不了的点位上不可替代。成熟体系几乎都是物理全量 binlog 连续归档 少量逻辑备份做逃生舱。实验二被撕开的账本——不带 redo 的热拷长什么样把为什么物理拷贝必须配 redo做成一个可复算的账100 个账户每页 100 元、总额守恒 1000020 笔转账每秒一笔热拷贝每秒拷一页。拷贝结束后的账面与真相差多少再从检查点 LSN 重放 redo 看能否收敛。N_ACCOUNT,INIT100,100# 每页一个账户, 守恒总额 10000ops[]# (seq, 出账方, 入账方): 20 笔转账forkinrange(20):ops.append((5*(k1),(3*k)%N_ACCOUNT,(3*k7)%N_ACCOUNT))naive,page_lsn{},{}forpginrange(N_ACCOUNT):val,lsnINIT,0forseq,a,binops:ifseqpg1and(apgorbpg):val-1ifapgelse1lsnseq naive[pg],page_lsn[pg]val,lsnprint(守恒校验(朴素热拷): 应为 %d, 实际 %d, 差额 %d 元 - 跨页事务被撕开%(N_ACCOUNT*INIT,sum(naive.values()),sum(naive.values())-N_ACCOUNT*INIT))tornsum(1forseq,a,binopsif(seqa1)!(seqb1))print(被撕开的转账: %d / %d 笔(一端页已拷、另一端未拷)%(torn,len(ops)))final,applied,skippeddict(naive),0,0forseq,a,binops:forpg,deltain((a,-1),(b,1)):ifpage_lsn[pg]seq:final[pg]delta page_lsn[pg]seq applied1else:skipped1print(\nredo 重放: 生效 %d 条页级记录, 跳过 %d 条(页比检查点更新, 天然幂等)%(applied,skipped))print(守恒校验(redo 追平后): 总额 %d, 差额 %d - 所有页停在同一逻辑终点%(sum(final.values()),sum(final.values())-N_ACCOUNT*INIT))fixedsum(1forpginnaiveifnaive[pg]!final[pg])print(修正了 %d 个拷早了的页, 其余 %d 页原样可用%(fixed,N_ACCOUNT-fixed))print(\n边界: LVM/云盘快照 断电一致性(等价 crash, 靠 crash recovery 收敛, 不指定应用一致点))print(fsfreeze 防的是页内撕裂, --single-transaction 防的是跨页撕账——热备必须两样都有)运行输出守恒校验(朴素热拷): 应为 10000, 实际 10002, 差额 2 元 - 跨页事务被撕开 被撕开的转账: 2 / 20 笔(一端页已拷、另一端未拷) redo 重放: 生效 38 条页级记录, 跳过 2 条(页比检查点更新, 天然幂等) 守恒校验(redo 追平后): 总额 10000, 差额 0 - 所有页停在同一逻辑终点 修正了 38 个拷早了的页, 其余 62 页原样可用 边界: LVM/云盘快照 断电一致性(等价 crash, 靠 crash recovery 收敛, 不指定应用一致点) fsfreeze 防的是页内撕裂, --single-transaction 防的是跨页撕账——热备必须两样都有最值得注意的是钱凭空多出来的方向撕开的转账里入账端被拷进、出账端没拷进备份账面比现实多出两元。这类静默的守恒破坏不会让任何文件报错只有在恢复后跑对账才能暴露——这解释了为什么备份体系必须内建恢复验证而不是备份任务绿灯 数据安全。redo 重放的幂等性LSN 已追过的记录直接跳过正是 XtraBackup--prepare的语义内核也是随便什么顺序拷页都能收敛的底气。体系落地清单全量频率按恢复时长 全量恢复 binlog 重放倒推RTO 预算 4 小时500GB 库就绝不允许一周一次全量。binlog 归档独立于备份任务连续、带确认第 3 篇的 binlog server 顺手兼任断流要告警——RPO 全靠它。遵守 3-2-13 份副本、2 种介质、1 份离线/不可变对象存储 WORM/冷备勒索软件最先删的就是在线备份目录。每季度随机抽一个备份做真恢复恢复到临时实例、跑CHECK TABLE、抽样对账守恒关系、行数、checksum并把 RTO 实测值记录在案没恢复验证过的备份等于没有备份。备份要带坐标全量文件头记录对应的 GTID 集/binlog 位点--source-data、xtrabackup_info、START-SLAVE-POINTER没有坐标的备份进不了 PITR 链条。表级逃生通道确认 mysqldump 单表导出/导入演练过含外键与触发器误删单表的场景等不起整库恢复。备份有了、坐标有了下一篇把它用起来《数据库高可用与容灾实战7PITR 时间点恢复把误删的数据找回来》——如何用一份全量加两天空白日志把被DROP TABLE的账本精确恢复到误删前一秒。参考来源MySQL 8.0 Reference ManualDatabase Backup Methodshttps://dev.mysql.com/doc/refman/8.0/en/backup-methods.htmlMySQL 8.0 Reference Manualmysqldumphttps://dev.mysql.com/doc/refman/8.0/en/mysqldump.htmlPercona XtraBackup 8.0 Documentationhttps://docs.percona.com/percona-xtrabackup/8.0/en/introduction.htmlWikipediaSnapshot (computer storage)https://en.wikipedia.org/wiki/Snapshot_(computer_storage)WikipediaBackuphttps://en.wikipedia.org/wiki/Backup
