SQL Server、MySQL (InnoDB)、PostgreSQL、达梦 (DM)、金仓 (KingbaseES) 在事务日志（Transaction Log / WAL）管理架构上的核心差异及简单对比

🔧 一、核心事务日志架构差异对比

📌 二、事务日志架构差异详解

1️⃣ SQL Server

• 日志单位：每个数据库有独立事务日志（.ldf）

• 日志链完整性非常重要，否则无法还原

• 日志记录仅包含该数据库内的事务操作。

• 日志的生成、截断、备份、恢复均在数据库级别进行。

• 无归档日志概念，PITR 依赖于连续的日志链备份

✅ 优势：

• 单库粒度的高可用和还原操作更加灵活

• 支持数据库独立的备份策略

❌ 挑战：

• 日志链断开则无法做时间点恢复（需频繁日志备份）

• 多库同步事务需要外部协调机制（如 DTC）

2️⃣ MySQL（InnoDB 引擎）

• redo log：循环写入 ib_logfile0, ib_logfile1... 崩溃恢复所用（物理日志，循环使用）

• binlog（逻辑日志）：用于主从复制、PITR、CDC

• redo log 是实例级的，所有 DB 共用；binlog 也一样

• 关键配置参数 innodb_log_file_size, innodb_log_files_in_group

✅ 优势：

• binlog 支持时间点恢复（通过 mysqlbinlog + --start-datetime）

• redo + binlog 分离，分别服务于不同场景（恢复 vs. 复制）

❌ 挑战：

• redo log 非归档型，无法用于 PITR，只支持最近一次 crash recovery

• 多租户场景下日志隔离性差

3️⃣ PostgreSQL

• 事务日志为 WAL（Write-Ahead Log），实例级；

• 文件结构 分段文件 (000000010000000A000000FD)

• 支持 WAL 归档（archive_command），用于时间点恢复与主备同步

• PITR、逻辑复制、流复制均依赖 WAL

• 关键配置参数wal_level, archive_mode, archive_command

✅ 优势：

• 强大的 WAL + base backup 架构：易于实现 PITR 和高可用

• WAL 文件格式清晰，便于远程传输、压缩

❌ 挑战：

• 所有数据库共享日志 → 多库同步备份需协调

• 未归档的 WAL 丢失即意味着 PITR 中断

4️⃣ DM（达梦）

• 类 Oracle 设计：日志文件组 + 归档日志

• 日志归档 + 控制文件共同保障恢复流程

• 支持基于 SCN（系统变化号）的时间点恢复

• 关键配置参数RLOG_PATH, RLOG_SIZE

✅ 优势：

• 归档日志管理完善，支持完整恢复链

• 高可用通过 双机热备、主备复制、归档传输 实现

❌ 挑战：

• 相对复杂的日志切换和归档机制，部署要求高

• 多 schema 操作下归档压力大

5️⃣ KingbaseES（金仓）

• 架构几乎照搬 PostgreSQL：使用 WAL、支持归档、时间点恢复、流复制等

• 同样以实例级别管理事务日志

• 支持 基于 LSN 的归档与恢复

✅ 优势：

• 支持完整的 PITR、HA 架构（主备热同步、级联备库）

• 工具链成熟（pg_basebackup、pg_receivewal）

❌ 挑战：

• 多租户不支持日志隔离

• 吞吐大时 WAL 压力大（需合理归档与清理）

🧭 三、日志架构对 PITR 的影响分析

1. SQL Server：数据库级 PITR (精细灵活)

• 还原流程：

  1. RESTORE DATABASE [DB] FROM FULL_BACKUP WITH NORECOVERY;

  2. RESTORE DATABASE [DB] FROM DIFF_BACKUP WITH NORECOVERY; (可选)

  3. RESTORE LOG [DB] FROM LOG_BACKUP WITH STOPAT = 'YYYY-MM-DD HH:MM:SS', RECOVERY;

• 核心优势：

  • 单库恢复： 可独立将特定数据库恢复到任意时间点，不影响其他数据库。

  • 并行恢复： 不同数据库的 PITR 操作可并行执行。

  • 资源隔离： 恢复过程仅锁定目标库，其他库可正常访问。

• 局限性：

  • 跨数据库事务无法保证一致性（需应用层配合）。

🧰 四、日志架构对高可用方案的影响分析

1. SQL Server：基于数据库的 HA (Always On AG/FCI)

• Always On Availability Groups (AG):

  • 粒度： 以数据库为单元组成可用性组。

  • 日志传输： 主副本将每个库的事务日志块实时发送到辅助副本。

  • 故障转移： 支持按数据库组转移，不同库组可属于不同副本。

  • 优势：

    • 精细化负载分配： 关键库与次要库可部署在不同副本。

    • 滚动升级/维护： 可逐个库组转移，最小化业务中断。

• Failover Cluster Instance (FCI):

  • 实例级故障转移（共享存储），但结合 AG 可实现混合 HA/DR。

2. MySQL/PostgreSQL/DM/KingbaseES：实例级 HA (全局复制)

• 常见方案：

  • MySQL: 主从复制 (Async/Semi-Sync), InnoDB Cluster (Group Replication), MHA.

  • PostgreSQL: 流复制 (Async/Sync), Patroni + etcd/zookeeper.

  • DM/Kingbase: 基于流复制的 HA 集群（类似 PG）。

• 核心限制：

  • 全实例复制： 复制流包含所有数据库的事务日志，无法选择复制部分库。

  • 故障转移粒度： 故障转移时整个实例切换到备机，所有库同时切换。

  • 资源耦合： 一个“慢查询”或大事务可能阻塞整个实例的复制流。

• 同步复制的影响：

• PG Sync Replication: synchronous_commit = on 需等待所有同步备机刷盘，所有库的事务提交延迟受最慢备机影响。

• MySQL Group Replication: 组内需多数节点确认事务，延迟由网络最慢节点决定。