随着居民健康需求的持续升级，医疗行业正面临着日益严峻的数据管理挑战。各医疗机构信息系统之间缺乏互联互通、患者就医流程断点多等问题在各级卫生健康部门中日益凸显。

以永康市为例，全市医疗体系承载着数百万居民的门诊、住院、体检、公共卫生等核心业务数据，这些数据的实时性、准确性和安全性直接关系到医疗服务质量和居民就医体验。然而，随着业务量持续增长，既有数据库架构逐渐难以支撑业务需求：业务高峰期间，数据库集群计算资源使用率接近 50%，读写请求比例高达 7:2，部分报表查询直接拉高整体系统负载，影响患者就诊等实时交互场景的响应速度。

永康云全民健康平台：基于物理复制的架构改造

永康市卫生健康局依托平凯数据库（TiDB 企业版）构建新一代全民健康平台，围绕“便民、助医、辅政、促研”四大目标，推动全市医疗信息化能力综合提升。平台承载着全市数百万居民的核心健康数据，作为全市医疗健康数据的核心枢纽，一旦生产系统发生故障，影响的是全市居民的就医服务。

基于对高可用和集群灾备保障的迫切需求，2026 年 5 月开始，永康云项目组联合平凯数据库工程师，采用平凯数据库 v7.1.9-0.1 版本的物理复制能力进行架构改造。

项目成功实现了门诊病历和体检数据等核心业务的查询分流——通过物理复制建立备集群承担报表查询等读操作，主集群专注于核心业务的实时响应。同时，备集群作为容灾备份，确保在生产系统发生故障时能够快速接管服务。相关业务目前已正式上线运行，架构改造带来了多方面的显著提升：

高可用保障：故障切换用时低于15s，数据零丢失，确保全市居民就医业务连续顺畅。

性能提升：读写分离后系统整体性能显著提升，患者端的实时交互体验得到有效保障。

运维效率：日常运维操作（保护模式切换、复制链路管理等）均可秒级完成。

数据安全：可根据业务需要灵活选择保护模式，在高可用与数据安全之间取得平衡。

什么是物理复制

物理复制是在两个数据库集群之间建立的底层数据同步机制。它将主集群的每一次数据变更以日志形式实时复制到备集群，备集群完整保留主集群的全部数据——不仅是业务数据，还包括用户账号、权限配置、序列等所有数据库对象。这意味着，备集群在任何时刻都与主集群保持高度一致，随时可以接替主集群对外提供服务。

核心指标参考（实际以网络、拓扑和负载为准）：

故障自动切换时间 (RTO)：< 15 秒

演练切换时间 (RTO)：< 30 秒

同步复制数据丢失量 (RPO)：0

异步复制数据丢失量 (RPO)：< 5 秒

写入延迟：同步复制会增加集群的写入延迟，延迟的估计值为“本地落盘时间 + 跨集群网络一次 RTT + 远端落盘时间”。异步复制不会增加写入延迟。

基本概念

primary / standby：表示集群当前的服务角色。

primary：主集群，可读可写。

standby：备集群，只读，不接受普通业务写入。

source / replica：表示一对物理复制集群之间的数据流向。

source：上游，负责向下游提供日志和快照。

replica：下游，负责接收并应用复制数据。

特别说明：一套物理复制主备环境中只能存在 1 个 primary 集群和 N 个 standby 集群。同时 1 个 standby 集群也可以作为其他 standby 集群的 source。

物理复制如何保障高可用与容灾

数据库容灾的核心目标是“快速恢复”与“数据安全”。物理复制在这两个维度上提供了可靠的保障：当主集群发生故障时，备集群能够在 15 秒内自动接管服务，让业务基本无感知地连续运行；同时通过灵活的保护模式机制，用户可以根据自身业务的重要程度，在数据安全与写入性能之间选择最适合的平衡点。

物理复制支持三种保护模式：

模式

名称

含义

说明

MAXIMUM_PERFORMANCE

最大性能

异步复制

提交不等待 standby ACK，优先保证吞吐。

MAXIMUM_PROTECTION

最大保护

同步复制

提交等待 standby ACK，不自动降级。若 standby 故障，primary 会阻塞写入。

MAXIMUM_AVAILABILITY

最大可用

同步复制，可自动降级

提交等待 standby ACK；若阻塞超过 DEGRADE_TIMEOUT，自动降级到 MAXIMUM_PERFORMANCE。

了解物理复制的核心能力和保护机制之后，如何在平凯数据库（TiDB 企业版）中实际部署和使用？下文将进一步介绍物理复制的实践操作，包括参数配置、复制链路创建、日常维护管理以及容灾切换流程。

物理复制链路初始化

1. 相关参数配置

构建物理复制需要额外开启 tikv replicator 服务以及日志归档，涉及参数如下：

配置项

作用

备注

replicator.enable

启动 TiKV 上的 replicator 服务

必须开启

raft-engine.enable

启用 raft-engine

必须开启

raft-engine.enable-log-archive

开启 raft-engine 日志归档

必须开启

raft-engine.archive-retention-time

设置日志归档保留时间

必须配置，且大于预期的网络中断时长；建议配置为 48h，但需综合评估磁盘容量是否能承载该时长的日志写入量

resolved-ts.enable

启用 resolved-ts

必须开启（standby 集群快照读和 FLASHBACK 依赖此项）

resolved-ts.advance-ts-interval

resolved-ts 推进间隔

必须配置；物理复制场景建议设置为 1s，间隔越短快照读延迟越低

可通过 information_schema.cluster_config 确认物理复制相关配置：

JavaScriptSELECT `instance`, `key`, `value`FROM information_schema.cluster_configWHERE `type` = 'tikv' AND `key` IN ( 'replicator.enable', 'raft-engine.enable', 'raft-engine.enable-log-archive', 'raft-engine.archive-retention-time', 'resolved-ts.enable', 'resolved-ts.advance-ts-interval' )ORDER BY `instance`, `key`;

2. 创建复制链路

在 standby 集群执行如下命令创建复制链路，操作简单，一键完成 standby 集群初始化。

Plain TextADMIN CREATE LOG REPLICATION dr_link SOURCE_HOST = '192.168.50.200' SOURCE_PORT = 4000 SOURCE_USER = 'root' SOURCE_PASSWORD = '1234' PROTECTION_MODE = MAXIMUM_PROTECTION DEGRADE_TIMEOUT = '15s' DETACHED;

参数说明

Plain Textdr_link：复制链路名称SOURCE_HOST：上游集群tidb ipSOURCE_PORT：上游集群tidb portSOURCE_USER：上游具备super权限的的复制用户 SOURCE_PASSWORD：复制用户密码PROTECTION_MODE：保护模式，支持：MAXIMUM_PERFORMANCE（最大性能）/MAXIMUM_PROTECTION（最大保护）/MAXIMUM_AVAILABILITY（最大可用）DEGRADE_TIMEOUT：复制降级超时时间，只在MAXIMUM_AVAILABILITY生效。DETACHED：异步创建模式。使用此选项时，语句立即返回一个 WORKFLOW_ID，不会阻塞等待初始化完成。可通过 INFORMATION_SCHEMA.LR_WORKFLOW_HISTORY_GLOBAL 查询工作流状

复制链路创建后，standby 集群从上游集群拉取 raft log 构建完整的 learner 副本。如下通过 WORKFLOW_STATE 核实复制链路的状态：COMPLETED standby 集群已经就绪，RUNNING standby 集群初始化中。

SQLMySQL [information_schema]> select * from INFORMATION_SCHEMA.LR_WORKFLOW_HISTORY_GLOBAL \G*************************** 1. row *************************** WORKFLOW_ID: 1 REPLICATION_NAME: dr_link REPLICA_CLUSTER_ID: 7653480571660089844 SOURCE_CLUSTER_ID: 7653479618362682413 WORKFLOW_TYPE: CREATE WORKFLOW_INFO: {"name":"dr_link","source_pd_addrs":["http://192.168.50.200:2379","http://192.168.50.201:2379","http://192.168.50.202:2379"],"initiator_cluster_id":7653480571660089844,"affected_source_cluster_id":7653479618362682413,"affected_replica_cluster_id":7653480571660089844,"start_timestamp":1781966442,"end_timestamp":1781966448} START_TIME: 2026-06-20 10:40:42 END_TIME: 2026-06-20 10:40:48 WORKFLOW_STATE: COMPLETED WORKFLOW_STATE_INFO: NULLINITIATOR_CLUSTER_ID: 76534805716600898441 row in set (0.011 sec)

下游集群就绪后对外提供数据一致性查能力，当前的数据同步点位可查询information_schema.LR_STATUS_LOCAL 视图的 CHECKPOINT_TS 字段获取。

Plain TextMySQL [(none)]> select * from information_schema.LR_STATUS_LOCAL;+---------------------+---------+-------------+---------------------+------------------+---------------------+-------------------------------------------------------------------------+---------------------+-----------------+-------------------+------------------+--------------------+---------------------+----------------+------------------+----------------+-----------------------+| CLUSTER_ID | ROLE | HAS_REPLICA | LAST_GLOBAL_UPDATE | REPLICATION_NAME | SOURCE_CLUSTER_ID | SOURCE_PD_ADDRS | PROTECTION_MODE | DEGRADE_TIMEOUT | REPLICATION_STATE | REPLICATION_MODE | CHECKPOINT_TS | CHECKPOINT_TIME | CHECKPOINT_LAG | SWITCHOVER_READY | FAILOVER_READY | INITIALIZING_PROGRESS |+---------------------+---------+-------------+---------------------+------------------+---------------------+-------------------------------------------------------------------------+---------------------+-----------------+-------------------+------------------+--------------------+---------------------+----------------+------------------+----------------+-----------------------+| 7652691118778624075 | STANDBY | 0 | 2026-06-29 19:38:04 | tidb_prod_eplica | 7450311999727826862 | http://79.79.8.106:2379,http://79.xx.8.xx:2379,http://79.xx.8.xx:2379 | MAXIMUM_PERFORMANCE | NULL | REPLICATING | ASYNC | 467332781959807027 | 2026-06-29 19:38:05 | 6 | YES | NO | 100 |+---------------------+---------+-------------+---------------------+------------------+---------------------+-------------------------------------------------------------------------+---------------------+-----------------+-------------------+------------------+--------------------+---------------------+----------------+------------------+----------------+-----------------------+1 row in set (0.011 sec)

3. 日常维护

物理复制日常维护主要涉及保护模式切换，复制链路创建、启停等，所有操作均可秒级完成。

切换集群保护模式

物理复制可自由在三种保护模式间切换。需要注意的是，切换成 MAXIMUM_PROTECTION 时，TiDB会自动检测当前 checkpoint lag，如大于 10s，切换将被拒绝（防止角色转换导致的主库卡顿）。

Plain TextADMIN ALTER LOG REPLICATIONPROTECTION_MODE = MAXIMUM_PERFORMANCE | MAXIMUM_PROTECTION | MAXIMUM_AVAILABILITY [DEGRADE_TIMEOUT = ''];

维护物理复制链路

Plain Text#暂停物理复制ADMIN PAUSE LOG REPLICATION;#恢复物理复制ADMIN RESUME LOG REPLICATION;删除物理复制ADMIN DROP LOG REPLICATION;

容灾切换

1. 计划内切换

只需一条指令就能完成 primary/standby 角色互换，耗时低于 30s。切换过程中，系统会自动完成 primary 禁止写入、追平数据和 primary/standby 角色切换，期间 TiDB 节点会自动重启。

Plain Text#指定当前standby集群为priamryADMIN SWITCHOVER AS PRIMARY;#指定具体某个standby集群为priamryADMIN SWITCHOVER PRIMARY TO;

2. 计划外切换

当确认 primary 集群已故障时，可主动激活 standby 集群对外提供读写服务。目前提供两种计划外切换模式：

FLASHBACK 模式

将 standby 的数据回退到一个一致性快照点后激活为 primary。适用于异步复制场景，同步复制场景但无法确认原 primary 状态,已在原 primary 上执行过 ADMIN DROP LOG REPLICATION（RPO>0）。

FORCE_COMMIT 模式

强制提交 standby 已接收的所有数据后激活为 primary。已确认原 primary 已彻底停机或网络隔离。并且当前复制为同步复制（MAXIMUM_PROTECTION 或 MAXIMUM_AVAILABILITY）。原 primary 尚未执行 ADMIN DROP LOG REPLICATION。

Plain Text#模式一：回退到一致性快照点ADMIN ACTIVATE STANDBY MODE = FLASHBACK;#模式二：强制提交已接收数据（仅限同步复制，可确保 RPO = 0）ADMIN ACTIVATE STANDBY MODE = FORCE_COMMIT;

物理复制与逻辑复制如何选择

除物理复制技术外，平凯数据库还提供 TiCDC 逻辑复制能力，两者实现技术原理存在差异，各有特点。

1. 平凯数据库物理复制的适用场景

中心级容灾建设：RPO 等于 0，集群级快速故障恢复（故障切换低于 15s）。

应用读写分离：物理复制备库，数据延迟低于 1s，具备实时一致性查询能力，可作为只读库为业务提供实时报表分析的能力。

流量回放及集群升级测试：物理复制备库可快速剥离成为镜像库，作为业务压测以及集群升级测试环境展开相关测试验证工作。

优点：

高吞吐低延迟：基于 Raft 日志的跨集群数据复制，同步效率远高于逻辑复制。

standby 集群具备一致性读能力：standby 集群实时数据一致性，无需依赖外部 synpoint 检查点。

支持所有数据库对象：支持用户，权限，序列等所有数据库对象复制。

集群切换前后执行计划稳定：primary/standby 集群统计信息保持一致，切换后执行计划不出现突变。

容灾切换 RPO=0：最大保护/最大可用模式下，计划外切换 RPO=0，故障切换耗时低于 30s。

当前限制：

tiflash 支持有待提高：目前 v7.1.9-0.1 standby 集群不支持 tifash，主备切换前需要先删除主集群tiflash 实例。（预计 v7.1.9-0.2 支持 standby 集群使用 tiflash）。

不支持异构容灾：基于 Raft 日志的跨集群数据复制，只支持在平凯数据库之间创建复制链路（集群版本大于等 v7.1.9-0.0）。

不支持个性化数据投递：基于 Raft 日志的跨集群数据复制，不支持过滤复制对象。

2. TiCDC 逻辑复制的适用场景

异构数据库的增量同步与灾备：将数据实时同步到另一个 TiDB 集群或其他兼容 MySQL 的数据库。

实时数据管道与消息队列：将数据变更实时同步到 Kafka 等消息中间件，为下游的实时计算、监控、缓存更新、全局索引等场景提供数据源。

需要数据过滤或转换的场景：在同步过程中，可以对数据库、表、DML 和 DDL 操作进行过滤，灵活度高。

TiCDC 逻辑复制通过拉取上游 TiKV 的变更日志（Change Log），将其解析、排序并重构成行级别的有序变更数据，最终应用到下游系统：

优点：

丰富下游生态：原生支持同步到 Kafka、MySQL 协议兼容的数据库、Elasticsearch 及 S3/GCS 等对象存储。

配置灵活：可以通过 filter 表达式进行表，库以及行级数据过滤，实现个性化的数据同步需求。

分布式高可用：支持多节点部署，具备自动故障转移能力。同步任务支持断点续传，重启后从断点继续，保证数据不丢不重。

当前限制：

同步对象不完整：不同步用户账号、权限、密码、Sequence 对象、SQL Binding 等元数据，需要手动维护。

存在同步限制：部分表（如无主键或者非空唯一索引的表）可能不满足同步要求。

总结

平凯数据库 v7.1.9-x 的物理复制特性，为关键业务系统提供了一套真正“开箱即用”的集群级容灾方案。在永康云全民健康平台的实践中，该方案已经成功承担起全市医疗健康数据核心枢纽的读写分离与容灾备份双重职责，门诊病历、体检数据等核心业务均实现了稳定的查询分流和秒级切换能力。

随着 v7.1.9-x 后续版本对 TiFlash 等能力的进一步完善，物理复制的适用范围还将继续扩大。对于正在规划核心系统容灾架构的用户而言，平凯数据库物理复制已经是一个成熟、可靠且值得优先评估的方案。