数据库备份与恢复方案

以下内容概述订单库的备份方案与在误删表场景下的按时间点恢复（Point-in-Time Recovery, PITR）方案。内容聚焦数据可用性、完整性与可恢复性，覆盖通用策略与主流数据库的实现要点。

一、目标与恢复指标

• 恢复点目标（RPO）：建议≤5–15分钟，确保因故障丢失的数据量可控。
• 恢复时间目标（RTO）：建议≤30–60分钟（依规模与环境而定）。
• 覆盖范围：库级、表级、Schema、事务日志/WAL、二进制日志、元数据（DDL、用户与权限）。
• 合规与安全：备份加密、隔离存储（跨可用区/Region）、访问审计。

二、备份方案设计

• 备份类型与组合
  • 全量备份：定期（如每日/每周），用于基线恢复。
  • 增量/差异备份：缩短备份窗口与传输量，提高RPO。
  • 事务日志/WAL/二进制日志持续归档：实现PITR到任意时间点。
  • 逻辑备份（导出DDL与数据）：用于表级恢复与跨版本迁移。
  • 存储快照（块级/卷级）：作为快速应急手段（需与数据库一致性配合）。
• 关键配置与保障
  • 打开并保留事务日志（PostgreSQL WAL、MySQL Binlog、SQL Server Log），确保持续归档与足够保留周期。
  • 备份一致性：使用热备工具/快照协调（如冻结写入或使用一致性快照）。
  • 校验与可恢复性：备份校验（checksum）、周期性演练恢复、自动告警。
  • 元数据备份：定期导出全库DDL、用户/权限，以支持表级精准重建。
  • 存储与安全：多副本、跨区域、不可变存储（WORM、Object Lock）、加密（传输与静态）。
  • 自动化与可观测性：调度、日志、指标、失败重试、告警，记录备份时的日志/位点信息。

三、备份实现示例（按主流数据库） 1）MySQL（InnoDB）

• 必要配置
  • 开启二进制日志：log-bin=ON，设置server_id。
  • 推荐Row格式：binlog_format=ROW（确保重放行级变更的准确性）。
  • 落盘与一致性：sync_binlog=1（提高崩溃安全性），innodb_flush_log_at_trx_commit=1。
  • 保留周期：binlog_expire_logs_seconds（或expire_logs_days）满足PITR窗口。
• 物理热备
  • 使用Percona XtraBackup或MySQL Enterprise Backup执行每日全量与多次增量备份，记录备份时的binlog文件与position。
• 逻辑备份
  • 使用mysqldump/mysqlpump定期导出DDL（--no-data）与关键表数据（用于表级恢复）。
• 存储与校验
  • 压缩、加密、校验后上传到对象存储，并记录元数据（备份时间、binlog位点、版本）。

2）PostgreSQL

• 必要配置
  • wal_level=replica，archive_mode=on，配置archive_command将WAL归档到冗余存储。
  • 保留周期：确保WAL归档覆盖所需PITR窗口。
• 物理备份
  • pg_basebackup定期全量（如每晚），WAL持续归档以支持PITR到任意时间。
• 逻辑备份
  • pg_dump定期导出Schema与关键表数据。
• 恢复时通过recovery.signal与restore_command进行WAL回放。

3）SQL Server

• 必要配置
  • 数据库处于FULL恢复模式：ALTER DATABASE [Orders] SET RECOVERY FULL;
• 备份策略
  • 每日全量：BACKUP DATABASE ... WITH COMPRESSION, CHECKSUM;
  • 每小时差异（可选）：BACKUP DATABASE ... WITH DIFFERENTIAL;
  • 每5–15分钟事务日志：BACKUP LOG ... WITH COMPRESSION, CHECKSUM;
• 校验与维护
  • RESTORE VERIFYONLY校验备份可用性；维护日志链完整性与保留周期。

四、场景：误删表的按时间点恢复（PITR） 通用原则

• 避免影响线上写入与其他表：建议在“恢复实例/克隆库”上恢复到误删前的时间点，然后将目标表提取并导入生产库。
• 精准时间点：从审计日志/应用日志/数据库日志中确定DROP TABLE发生的时间；或使用日志解析工具扫出相应事件与位点。
• 表级导入前保障
  • 精确重建DDL（列类型、默认值、索引、约束、触发器）。
  • 处理外键依赖与数据一致性（必要时先恢复父表或暂时禁用约束）。
  • 控制并发写入窗口，避免数据冲突；在导入时使用事务与锁策略。

1）MySQL按时间点恢复步骤

• 前提：已启用binlog且有最近的全量/增量备份。
• 恢复到“误删前时间点”的恢复实例
  • 使用XtraBackup恢复最新全量并顺序应用增量：
    • 准备全量：xtrabackup --prepare --target-dir=/backups/full
    • 逐个应用增量：xtrabackup --prepare --apply-log-only --target-dir=/backups/full --incremental-dir=/backups/inc1（依序直至最后一个）
    • 最终准备：xtrabackup --prepare --target-dir=/backups/full
  • 启动恢复实例，回放binlog到误删前：
    • 确定起始位点（备份记录的binlog文件与position）
    • 回放：mysqlbinlog --start-position= --stop-datetime="YYYY-MM-DD HH:MM:SS" --database=orders /archive/binlog.* | mysql -h <recovery_host> -u -p
    • 若需定位事件：mysqlbinlog --verbose --base64-output=DECODE-ROWS /archive/binlog.* | grep -n "DROP TABLE schema.table"
• 提取与导入目标表
  • 简单方式（推荐）：在恢复实例导出表数据与DDL
    • 导出DDL：mysqldump -h <recovery_host> -u -p --no-data orders table > table_ddl.sql
    • 导出数据：mysqldump -h <recovery_host> -u -p --single-transaction orders table > table_data.sql
  • 在生产库执行：
    • 先重建表：mysql -h <prod_host> -u -p < table_ddl.sql
    • 再导入数据：mysql -h <prod_host> -u -p < table_data.sql
  • 备选方式（InnoDB可传输表空间，需file_per_table=ON）：
    • 恢复实例：FLUSH TABLES table FOR EXPORT（生成.cfg），复制table.ibd与.cfg
    • 生产库：按相同DDL重建表，ALTER TABLE table DISCARD TABLESPACE，复制.ibd/.cfg到数据目录，ALTER TABLE table IMPORT TABLESPACE
• 校验与收尾
  • 比对行数与校验和；恢复索引与约束；重新启用触发器；记录变更。

2）PostgreSQL按时间点恢复步骤

• 前提：已开启WAL归档并有最近的基线备份。
• 恢复到“误删前时间点”的恢复实例
  • 将基线备份还原到新数据目录，准备归档WAL路径
  • 创建recovery.signal并配置：
    • restore_command='cp /archive/%f %p'
    • recovery_target_time='YYYY-MM-DD HH:MM:SS UTC'
    • recovery_target_action='pause'（回放达到目标时间后暂停）
  • 启动PostgreSQL，等待回放完成（日志显示到达目标时间）
• 提取与导入目标表
  • 在恢复实例：pg_dump -h <recovery_host> -U -d orders -t schema.table --column-inserts > table.sql
  • 在生产库：psql -h <prod_host> -U -d orders -f table.sql
• 校验与收尾：数据一致性检查、约束与索引验证。

3）SQL Server按时间点恢复步骤

• 前提：FULL恢复模式，完整日志链（全量/差异/日志）。
• 恢复到“误删前时间点”的克隆库
  • RESTORE DATABASE [Orders_PITR] FROM 'full.bak' WITH NORECOVERY, MOVE ...;
  • 可选差异：RESTORE DATABASE [Orders_PITR] FROM 'diff.bak' WITH NORECOVERY;
  • 顺序恢复日志：RESTORE LOG [Orders_PITR] FROM 'log1.trn' WITH NORECOVERY; ... 最后一个使用STOPAT并RECOVERY：
    • RESTORE LOG [Orders_PITR] FROM 'last.trn' WITH STOPAT='YYYY-MM-DDTHH:MM:SS', RECOVERY;
• 提取与导入目标表
  • 生成表DDL（SSMS或脚本）在生产库重建
  • 数据导入：INSERT INTO [Orders].[dbo].[table] SELECT * FROM [Orders_PITR].[dbo].[table];
  • 若存在IDENTITY列：SET IDENTITY_INSERT [Orders].[dbo].[table] ON后插入，再关闭
  • 若有约束/触发器：根据需要暂时禁用，导入后恢复
• 校验与收尾：校验行数、约束与索引，记录操作。

五、备份验证、监控与演练

• 周期性恢复演练：在隔离环境执行全链路恢复与表级PITR，验证RPO/RTO达标。
• 备份可用性校验：校验和检查、试恢复、日志链完整性验证（SQL Server）、binlog/WAL可读性与覆盖窗口核对。
• 监控与告警：备份失败、归档延迟、存储容量、WAL/binlog保留期、复制/归档错误。
• 变更与文档：备份与恢复Runbook、DDL变更记录、关键时间点与位点记录、权限与密钥管理。

该方案确保订单库在误删表等操作失误场景下，可以在不影响线上整体数据与写入的情况下，通过恢复实例执行精准的按时间点恢复，并以表级粒度回填生产数据。同时通过严谨的备份策略、日志归档与验证机制，达成既定的RPO/RTO目标。

概述 目标是为数据库用户服务库制定可执行的备份方案、发布失败的回滚方案，以及主从故障切换的恢复方案。内容包含备份类型与频率、恢复与校验步骤、发布变更的控制与回退流程、以及主从复制架构下的故障检测、切换和一致性恢复。

一、备份方案

1. 备份类型

• 物理热备：数据库数据目录的块级或文件级拷贝，结合事务日志（例如 Binlog/WAL）归档。用于快速恢复与点时间恢复（PITR）。适合大数据量与严格RTO场景。
• 逻辑备份：按库/表导出数据与结构（如 SQL dump）。用于跨版本迁移、单表级恢复、审计与数据选择性恢复。对大库恢复速度较慢。
• 存储快照：基于卷/文件系统快照（如 LVM、云盘快照）获取一致性副本，结合数据库日志归档实现PITR。快照触发时需确保数据库处于一致状态（短暂锁或备份模式）。

2. 备份频率与保留

• 全量备：每日一次（低峰时段）；保留7–30天。
• 增量/日志归档：每5–15分钟上传事务日志（Binlog/WAL）到对象存储；保留与全量备份一致或更长。
• 周/月保留：每周归档一份全量，每月归档一份长期保留，用于满足审计与合规。
• 元数据备份：同时备份数据库用户、权限、触发器、存储过程、序列、事件调度配置与版本号。备份清单与校验和一并保存。

3. 一致性保障

• 备份前置操作：启动备份模式或获取一致性快照，确保在同一事务点；对于逻辑备份，启用一致性读取（可重复读）并避免并发 DDL。
• 负载影响控制：备份限速、I/O隔离、读副本执行逻辑备（避免阻塞主库）。

4. 安全与合规

• 传输与静态加密：备份文件使用加密（如 AES-256），传输采用 TLS。
• 访问控制与密钥管理：分离职责，审计访问；密钥轮换与最小权限。
• 存储多地冗余：本地存储 + 远端对象存储（跨区域）。

5. 备份验证与演练

• 校验：生成与核对校验和；解压与解密验证能否成功。
• 可恢复性演练：按季度在隔离环境进行全链路恢复与PITR演练，记录RTO/RPO与问题清单。
• 自动化报告：备份成功、容量、耗时、日志上传延迟告警。

二、恢复与点时间恢复（PITR）流程

• 选择恢复点：基于故障发生时间或发布回滚时间戳，确定目标时间。
• 准备环境：新建隔离恢复实例或读副本，加载最近一次全量物理备份。
• 应用增量日志：按顺序回放事务日志直至目标时间点（精确到秒级，避免超出）。
• 数据一致性校验：
  • 运行数据库内置一致性检查与系统表校验。
  • 样本表行数、哈希校验与关键业务表约束检查。
• 只读验证：以只读模式对关键查询与接口进行验证（烟囱测试）。
• 切换上线：
  • 通过负载均衡或连接字符串切换应用至恢复实例。
  • 观察关键监控（错误率、延迟、连接数），稳定后解除只读。

三、场景发布失败回滚方案

1. 变更策略

• 版本化的迁移工具：使用版本号管理的迁移与基线（如迁移脚本、校验摘要），确保变更可追踪与可重放。
• 兼容性发布（Expand-Contract）：先增加新结构（如添加列/表、双写），应用切换到新结构后再移除旧结构。
• 事务性变更：尽可能使用可回滚的事务性 DDL/DML；对于不可事务 DDL，准备对称的回滚脚本。
• 数据变更审慎：大批量更新采用分批与可重入脚本；记录变更前快照或变更清单以便反向恢复。

2. 发布前保障

• 预发布检查：干跑（dry-run）、权限与锁检查、与读写流量冲突分析。
• 快照与标记：在发布前做一次可快速恢复的物理备或存储快照；记录发布版本号与时间戳以便PITR定位。
• 回滚预案：每个迁移脚本提供反向脚本（包含索引、约束、默认值的还原），评估回滚副作用。

3. 发布失败回滚流程

• 立即止损：冻结新的写入或启用只读，避免扩大影响。
• 应用层回滚：回退应用版本或关闭新功能开关，恢复旧读写路径。
• 数据库回滚：
  • 可事务变更：执行回滚事务或反向脚本。
  • 不可事务或结构性问题：执行PITR至发布前时间点，在新实例验证后切换。
• 验证与解冻：完成数据完整性与性能验证后恢复正常写入。
• 复盘与记录：记录失败原因、影响范围、恢复耗时，更新回滚与发布清单。

四、主从（主备/主从）故障切换与恢复方案

1. 架构与前提

• 至少一个同步或低延迟的只读副本（从库/备库），启用事务日志复制。
• 应用通过中间层（连接代理、负载均衡或服务发现）连接数据库，便于快速重定向。
• 监控与心跳：持续监控主库可用性、复制延迟、错误率。

2. 故障检测与切换策略

• 触发条件：主库不可达、崩溃、严重性能退化或复制落后超阈值。
• 防分裂脑：
  • 主库失联时先隔离（下线、关闭写入、移除负载均衡目标）。
  • 采用仲裁/投票或外部协调服务，确保只有一个主库被提升。
• 提升副本为主库：
  • 在副本上停止复制并提升为可写主库。
  • 确认最后已应用的事务位点（日志位置/LSN），评估与主库的偏差。
• 客户端重配置：更新连接目标或服务发现记录，缩短DNS/缓存TTL，确保应用写入到新主库。
• 写入恢复：逐步放开写入，观察复制延迟与错误。

3. 原主恢复与重新加入

• 原主健康修复：完成崩溃恢复、数据校验，确保不再对外提供写入。
• 重新拉起为副本：
  • 清理不一致数据，使用新主库的全量备份重新同步。
  • 配置复制并从新主库最新事务位点开始追赶。
• 一致性验证：
  • 比对关键表的计数与校验和，抽样数据一致性检查。
  • 对复制延迟与错误进行持续监控。

4. 自动化与演练

• 使用故障切换控制器或编排工具进行自动化切换（具备仲裁与隔离能力）。
• 半年度演练：模拟主库宕机、网络分区、日志落后，验证RTO/RPO与操作步骤。
• 变更窗口策略：在低风险时段进行大规模DDL或拓扑变更。

五、监控与运行指标

• 备份：成功率、耗时、备份大小、日志归档延迟、恢复演练结果。
• 复制：延迟、错误计数、重试次数、当前位点差异。
• 可用性：连接错误率、查询延迟、锁等待、死锁。
• 安全：访问审计、密钥轮换状态、加密有效性。
• 容量与增长：表/索引膨胀、数据增长率、热点表写入分布。

附注与实施建议

• 引擎适配：上述方案适用于主流关系型数据库。事务日志归档与PITR分别对应如 Binlog（MySQL/MariaDB）或 WAL（PostgreSQL）。物理热备可采用对应引擎的热备工具或官方基线备份机制，逻辑备采用引擎自带导出工具。
• 文档与Runbook：为备份恢复、发布回滚、故障切换分别维护标准操作指引与检查清单，确保在值班与演练中可重复执行。
• 变更治理：所有DDL/DML迁移纳入评审与预演流程，含性能影响评估与回滚可行性评估。