数据守护分类介绍

1 数据守护原理介绍

达梦数据守护是一种基于数据库日志（REDO）的物理级高可用解决方案。其核心思想是：主库将其产生的所有物理日志同步到备库，备库通过重演（Apply）这些日志，使其数据状态与主库保持一致，从而实现数据的冗余和高可用。

1.1 核心架构与组件

• 主库 (Primary)​​：承担主要的读写业务负载。所有数据变更都会生成REDO日志，并通过MAL系统发送给备库。
• 备库 (Standby)​​：提供只读服务，保障数据安全。其核心任务是接收主库发来的REDO日志，并重演（Apply）​​ 这些日志，使自身数据与主库保持一致。
• 守护进程 (dmwatcher)​​：每个数据库实例都有一个配套的守护进程。它是集群的“神经中枢”，负责：
  • 监控​：持续检测其守护的数据库实例状态。
  • 消息中转​：作为数据库与监视器之间的通信代理，转发状态信息。
  • 故障处理​：在满足条件时，自动执行故障切换（Failover）等流程。
• 监视器 (dmmonitor)​​：提供全局集群视图。管理员通过监视器执行监控和管理命令（如switchover）。它整合所有守护进程上报的信息，是集群管理的控制台。

1.2 核心机制

1.2.1 REDO日志与LSN（日志序列号）

• REDO日志​：记录了所有对数据页的物理修改​（如INSERT、UPDATE、DELETE、DDL等操作的最终物理结果）。它是数据同步的“数据源”。
• LSN (Log Sequence Number)​​：这是保证一切有序和一致性的核心机制。它是一个单调递增的序列号，唯一标识每一条REDO日志。
  • FILE_LSN：已持久化到磁盘的日志的最大LSN，是数据持久化的关键标志。
  • APPLY_LSN（备库）：备库已重演完成的最大LSN。通过对比主库的FILE_LSN和备库的APPLY_LSN，可以精确监控数据同步的进度和一致性。

1.2.2 日志包 (RLOG_PKG)

主库并非一条条地发送日志，而是将多条REDO日志打包成一个日志包（RLOG_PKG）​，以包为单位发送给备库，以此减少网络开销和提高效率。

1.3 归档模式和数据流

数据守护支持多种归档模式，决定了日志的同步时机和数据一致性级别。

特性	REALTIME (实时)	TIMELY (及时)	SYNC (同步)
核心机制​	日志包​先发往备库，再写入主库本地日志	先写入主库本地日志，再发往备库	日志在主库归档后，​异步批量发送至备库
数据一致性​	高​	高​	最终一致​
性能影响​	对主库性能有一定影响	对主库性能影响相对较小	对主库性能影响最小​
故障处理​	复杂，需KEEP_PKG机制防止数据分歧	较复杂	简单，失败后自动异步重试
适用场景​	要求高可用和强一致性的核心业务	要求高可用和强一致性的核心业务	异地容灾、读写分离、非核心业务

1.3.1 REALTIME模式

• 特点​：优先保证备库数据同步，数据安全性极高。
• KEEP_PKG机制​：为防止主库在发送成功但未本地落盘时故障，导致主备数据分歧，备库会缓存一个日志包，待收到下一个包确认主库正常后，才重演前一个包。​这是实现事务一致性模式的基础**。
• 限制​：此模式下的事务一致性模式仅支持自动切换，且DSC环境（多主集群）不支持。

1.3.2 TIMELY模式

• 特点​：优先保证主库本地持久化，兼顾备库同步。
• 流程​：日志先写入主库本地联机日志文件，再发送给备库。没有KEEP_PKG机制。
• 优势​：避免了REALTIME模式的复杂性和部分限制，同时仍能保证很高的数据一致性。

1.3.3 SYNC模式

• 特点​：​异步、高性能的同步方式。主库不会因备库故障或网络延迟而阻塞。
• 流程​：日志在主库归档到本地后，由后台线程批量、异步地发送给备库。同步失败不会挂起主库，而会自动按配置间隔重试。
• 限制​：​不支持故障自动切换（Switchover/Takeover）​，且不支持DSC环境。主要用于数据备份和读写分离。

1.4 故障处理与监控

• 故障检测​：通过守护进程之间、守护进程与数据库之间、以及监视器层面的多重心跳消息​（每秒一次）快速发现故障。
• 状态切换 (Suspend)​​：当同步失败时，主库会进入Suspend状态，​暂停数据同步流，并等待守护进程发起故障处理流程。
• 故障处理 (Failover)​​：守护进程和监视器会根据配置的归档模式和处理策略，自动或手动执行故障切换，将备库提升为主库，恢复服务。

2 各种主备架构的概念

有两个核心作为权衡的维度，从而决定了所选用的主备模式不同：

• 一致性 (Consistency) vs. 性能 (Performance)​​：是否需要备库和主库数据完全一致（强一致），还是可以接受瞬间不一致（最终一致）以换取更高性能。
• 可用性 (Availability) vs. 复杂性 (Complexity)​​：是否需要自动故障切换（高可用），还是可以接受手动干预以降低系统复杂度。

总览表：

对比维度	异步主备	同步主备	实时主备 (达梦)	实时高性能主备	Raft主备
核心机制​	主库事务提交后，异步发送日志到备库。不等待备库确认。	主库事务提交前，同步发送日志到备库并等待其写入磁盘。	指日志持续流式地从主库发送到备库。通常配置为异步或近似同步。	优化方向：在实时同步的基础上，通过硬件（RDMA/SSD）、网络（高速网卡）、软件算法极致优化同步效率。	基于共识算法。主库(Leader)需将日志复制到多数派节点后才能提交，自动选主。
数据一致性​	最终一致 (RPO > 0, 有数据丢失风险)	强一致 (RPO = 0, 理论上无数据丢失)	最终一致 ~ 强一致 (取决于配置是ASYNC还是SYNC)	强一致 (目标是让强一致的代价降到最低)	强一致 (基于多数派决议，RPO = 0)
性能 (吞吐量 & 延迟)​​	最高 (主库性能无任何等待开销)	最低 (延迟取决于最慢的备库IO和网络)	高 ~ 中 (ASYNC模式性能接近异步，SYNC模式性能接近同步)	非常高 (在强一致的前提下，追求极致的低延迟和高吞吐)	中 (延迟取决于多数派节点的响应速度)
可用性 (故障切换)​​	自动或手动，但切换会丢失数据	通常依赖外部工具，切换逻辑复杂	高可用 (HA) 由dmwatcher守护进程自动切换	高可用 (HA)	高可用 (HA) 内置自动选主，是架构一部分
优点​	性能极高，对主库影响最小，网络距离影响小	数据安全性最高，强一致性	兼顾性能和数据实时性，支持自动故障转移	提供了强一致性和高性能的融合方案	内置高可用，自动容错，无单点故障，协议标准
缺点​	数据不一致风险最高	性能开销大，备库/网络故障会阻塞主库	配置和管理比纯异步或同步复杂	成本和实现复杂度最高，严重依赖底层基础设施	资源开销大(至少3节点)，写性能受限于多数派
典型场景​	日志归档、非核心业务、读写分离的读库、异地容灾	核心交易系统（如银行转账）、对数据一致性要求极严的场景	通用OLTP系统、企业核心应用、追求高可用的业务	高频交易、实时数据分析、金融核心系统等土豪场景	分布式系统组件（Etcd, Consul）、NewSQL数据库（TiDB）、微服务治理

2.1 同步主备

同步主备是一种非常保守且安全的数据冗余策略，其核心在于通过等待来保证数据的强一致性。

1. 核心机制​：
   • 客户端向主库提交一个写事务。
   • 主库在提交该事务之前，会先将事务产生的重做日志（Redo Log）发送给一个或多个备库。
   • 主库阻塞当前事务，等待备库将日志加载到本地后不等备库进行重演前返回一个“确认”消息。
   • 主库收到备库的确认后，才在本地提交事务，并向客户端返回成功。
   • 如果备库无响应或返回错误，主库可能会等待超时后中断事务。
2. 数据一致性​：
   • 强一致性。一旦主库告知客户端提交成功，则意味着数据一定已经存在于主库和至少一个备库的磁盘上。
   • RPO (恢复点目标) = 0。理论上故障切换时不会丢失任何已确认的数据。
3. 性能特点​：
   • 高延迟​：事务的响应时间 = 主库处理时间 + 传输到备库时间 + 备库磁盘IO时间 + 网络回传时间。这受限于传输和备库IO中最慢的环节。
   • 低吞吐量​：由于每个事务都要等待远程IO，整体处理能力受限。
4. 高可用性 (HA)​​：
   • 需要额外的守护进程​（dmwatcher）来监控主备状态和执行故障切换。
   • 备库故障或网络中断会直接阻塞主库的写操作，可能引发全局不可用，除非有超时机制降级。
5. 优点​：数据安全性最高，保证零数据丢失。
6. 缺点​：性能开销最大，可用性风险高（备库故障会影响主库）。
7. 典型场景​：对数据一致性要求极严的核心业务，如银行转账、证券交易、支付系统。

2.2 异步主备

异步主备是一种追求极致性能的策略，其核心是主库优先处理本地事务，数据同步是后台任务。

1. 核心机制​：
   • 客户端向主库提交写事务。
   • 主库在本地提交事务后立即向客户端返回成功。
   • 随后，主库通过一个后台进程，将事务产生的重做日志异步地发送给备库。
   • 主库不等待备库的任何确认。
2. 数据一致性​：
   • 最终一致性。主备数据之间存在延迟，从几毫秒到几分钟不等。
   • RPO > 0。如果主库在日志发送前发生宕机，​所有未发送的已提交事务都会丢失。
3. 性能特点​：
   • 低延迟​：客户端的响应时间仅取决于主库的本地操作，非常快。
   • 高吞吐量​：没有远程等待开销，主库可以全力处理业务请求。
4. 高可用性 (HA)​​：
   • 同样需要外部守护进程。
   • 备库故障或网络中断对主库完全无影响，主库可继续正常运行。
5. 优点​：性能最高，对主库影响最小，备库延迟不影响主库。
6. 缺点​：数据丢失风险最高。
7. 典型场景​：非核心业务、读写分离的只读备库、日志审计、异地容灾（允许一定数据丢失）。

2.3 实时主备

“实时”是指日志传输方式是持续流式的

1. 核心机制​：
   • 主库生成的重做日志会以数据流的形式持续不断地、几乎无延迟地发送给备库。
   • 这与异步主备的批量发送有本质区别，延迟更低。
   • 关键​：这种“实时传输”可以配置为两种模式，决定了其最终行为：
   • SYNC(近似同步) ：主库需要等待备库确认收到日志​（但不一定持久化到磁盘）后才提交。​性能较低，数据更安全。
   • ASYNC(异步) ：主库不等待备库确认。​性能更高，数据有风险。
2. 数据一致性​：
   • 取决于配置。配置为SYNC时，一致性接近同步；配置为ASYNC时，一致性为最终一致。
3. 性能特点​：
   • 流式传输效率高于批量传输。
   • 性能介于同步和异步之间，具体取决于上述配置。
4. 高可用性 (HA)​​：
   • 通常与达梦的守护进程 (dmwatcher)​​ 紧密集成，提供自动故障检测和切换能力，是实现高可用的核心方案。
5. 优点​：兼顾了性能和数据实时性，灵活性高（可配置），支持自动故障转移。
6. 缺点​：配置和管理比纯异步或同步模式复杂。
7. 典型场景​：通用的企业级应用、ERP系统、需要高可用的OLTP数据库。

2.4 实时高性能主备

目标是打造低延迟、高吞吐的强一致性系统。

1. 核心机制​：
   • 它通常以同步主备或实时主备（配置为SYNC）​​ 的强一致性模型为基础。
   • 通过一系列硬件和软件优化来极大降低同步等待带来的开销：
2. 数据一致性​：
   • 强一致性。目标是在极短时间内完成同步等待，从而实现既强一致又高性能。
3. 性能特点​：
   • 在保证强一致的前提下，​吞吐量和延迟指标接近甚至媲美异步模式。
4. 高可用性 (HA)​​：
   • 具备所选基础模式（同步/实时）的高可用特性。
5. 优点​：提供了强一致性和高性能的完美融合，鱼和熊掌兼得。
6. 缺点​：​成本和实现复杂度最高，严重依赖底层基础设施。
7. 典型场景​：金融高频交易、实时风控、大型电商秒杀、运营商计费系统等土豪场景。

2.5 Raft 主备

Raft是一种分布式共识算法，它重新定义了主备模式，通过算法内置的民主机制实现强一致和高可用。

1. 核心机制​：
   • 集群​：由多个节点（通常为奇数，如3、5个）组成一个对等集群。
   • 选举​：集群自动选举出一个Leader​（主库），其他节点为Follower​（备库）。Leader负责处理所有客户端请求。
   • 日志复制​：
     1. Leader将写操作追加到本地日志。
     2. Leader将日志并行发送给所有Follower。
     3. Leader等待超过半数的节点（包括自己）将日志持久化后，即认为该日志已提交（Committed）。
     4. Leader应用日志到状态机，并回复客户端。
     5. Leader通知所有Follower提交日志。
   • 自动容错​：如果Leader故障，剩余节点会自动发起新一轮选举，选出新的Leader。
2. 数据一致性​：
   • 强一致性。基于“多数派”原则，一旦成功返回，数据必定在多数派节点上持久化，故障后新Leader一定拥有全部已提交数据。
3. 性能特点​：
   • 延迟取决于多数派节点中最慢的那个，而不是所有节点。性能和扩展性优于传统同步到所有节点的模式。
4. 高可用性 (HA)​​：
   • 内置高可用。故障切换是算法内部流程，​无需外部守护进程干预，真正实现了去中心化的自动容错。
5. 优点​：强一致、内置高可用、自动故障转移、无单点故障、协议标准化。
6. 缺点​：资源开销大（至少3节点才能容忍1个故障），写性能受集群规模影响。
7. 典型场景​：分布式系统核心组件（如Etcd、Consul）、NewSQL数据库（如TiDB）、微服务配置中心、服务发现。

3 不同主备模式的资源消耗

不同主备同步机制在资源消耗、RPO、RTO上表现各异，也就决定了它们的适用场景。

3.1 资源消耗

• 同步/实时 (SYNC)​​：消耗最大。因为它需要占用关键路径上的网络和磁盘资源，并等待其完成，直接限制了系统的吞吐量。
• 异步 (ASYNC)​​：消耗最小。因为它利用空闲资源进行后台同步，对主业务流影响极小。
• Raft​：消耗高，但角度不同。它的消耗来自于多个节点的对等开销和协议本身的通信成本，是一种为换取高可用和强一致而付出的“集群税”。

3.2 RPO-恢复点目标

• 定义​：灾难发生后，系统能恢复到的最新数据时间点与灾难发生时的时间差。​RPO = 0​ 意味着像没事发生一样，没有任何数据丢失。
• 同步模式​：通过等待确保数据落盘，从而实现 RPO=0。
• 异步模式​：数据同步是滞后的，所以 RPO > 0。
• Raft​：通过多数派确认来保证数据已持久化，从而实现 RPO=0。

3.3 RTO-恢复时间目标

• 定义​：从灾难发生到系统恢复服务所花费的时间。RTO越短，业务中断时间越短。
• 影响因素​：
  • 数据追平时间​：备库数据是否最新？异步模式下可能需要很久来追日志。
  • 切换自动化程度​：是手动切换还是自动切换？自动化能极大降低RTO。
  • 故障检测时间​：多快能发现故障？
• 实时主备 + HA工具​ 和 ​Raft​ 都能提供极低的 RTO，因为它们自动化程度高且数据几乎就绪。

3.4 选型

业务需求	推荐模式	理由
绝对数据安全，不惜性能代价​	同步主备​	RPO=0 是唯一目标
极致性能，可接受数据丢失​	异步主备​	资源消耗最低，对主库无影响
业务高可用，兼顾性能与数据安全​	实时主备​ (配置 SYNC)	在 RPO≈0 和 RTO很低 之间取得了最佳平衡
构建分布式系统，需要天然高可用​	Raft主备​	内置强一致、自动容错和无中心化，是分布式系统的基石