基于 Kingbase FlySync 的实施项目生命周期 OverView

基于 Kingbase FlySync 的实施项目生命周
期 OverView
北京人大金仓信息技术股份有限公司
Mar 20, 2023

目 录
1 前言 7
1.1 版权声明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 免责声明 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3 技术支持 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 文档概述 9
3 总体流程介绍 11
4 需求及可行性评估 13
4.1 需求评估时的关注点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1 软硬件平台是否在支持列表内 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.2 网络及端口要求是否能够满足 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.3 源端数据库的版本及数据类型是否能够支持 . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3.2 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3.3 SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.3.4 KingbaseES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.4 目标端数据库的版本及数据类型是否能够支持 . . . . . . . . . . . . . . . . . . . . . . . 20
4.1.5 源端到目标的数据同步组合是否能够支持 . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.6 数据库参数设置符合要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.7 数据库账号权限符合要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.8 数据库主键或者唯一索引符合要求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.9 同步时效性是否能够满足需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.10 转换能力是否能够满足需求 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 需求评估手段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 业务需求调研表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.2 业务评估指南和数据评估工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 部署方案 25
3
5.1 Kingbase FlySync 组件介绍 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2 客户需求分析 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3 各组件的部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.1 同步服务部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.1.1 一对一 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.3.1.2 一对多 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.1.3 多对一 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.2 管控平台部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.3 比对服务部署方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.4 数据转换方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.1 支持的转换 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4.2 转换组合方式 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4.3 转换配置阶段 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6 存量数据迁移方案 33
6.1 迁移方案选择时的考虑因素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 数据库结构迁移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3 表数据迁移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.1 迁移方案选择 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.3.2 表结构不一致时的数据迁移 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3 数据迁移出错时的处理办法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3.1 备份还原工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3.3.2 数据库迁移工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.3.3.3 自带数据迁移工具 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.4 迁移结果确认 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7 增量数据同步方案 39
7.1 源端抽取方式选择 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.1.1 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.2 SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1.3 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.1.4 KingbaseES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
7.2 数据转换原理及配置 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.3 目标端入库方式选择 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
8 功能和性能验证及问题解决 43
8.1 验证目标 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2 验证方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2.1 功能验证 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2.2 性能验证 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8.3 验证效果评估 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.4 性能问题调整方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
8.4.1 源端解析瓶颈性能调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4
基于 Kingbase FlySync 的实施项目生命周期 OverView
8.4.2 网络传输瓶颈性能调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
8.4.3 目标端入库瓶颈性能调整 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
9 运维方案设计 51
9.1 日常运维的关注要素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
9.2 运维频次和产出物 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.3 数据一致性检验和差异修复 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.3.1 检验时的考虑因素 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.3.1.1 检验哪些业务表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
9.3.1.2 检验方式选择 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.3.1.3 检验的执行时间以及周期 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.3.1.4 数据不一致时的处理方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.3.2 数据检验配置举例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.4 故障和异常处理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
10 回切方案及系统重建 57
10.1 回切的含义 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
10.2 什么时候需要回切 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.3 回切的配置方式和回切方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.3.1 配置方法和注意事项 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
10.3.2 回切方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
10.4 回切后如何恢复同步环境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
11 常见问题 61
目 录 5
基于 Kingbase FlySync 的实施项目生命周期 OverView
6 目 录
第 1 章
前言
1.1 版权声明
人大金仓版权所有，并保留对本手册及本声明的一切权利。未得到人大金仓的书面许可，任何人不得以任何
方式或形式对本手册内的任何部分进行复制、摘录、备份、修改、传播、翻译成其他语言、将其全部或部分
用于商业用途。
1.2 免责声明
本手册内容依据现有信息制作，由于产品版本升级或其他原因，其内容有可能变更。人大金仓保留在没有任
何通知或者提示的情况下对手册内容进行修改的权利。本手册仅作为使用指导，人大金仓在编写本手册时已
尽力保证其内容准确可靠，但并不确保手册内容完全没有错误或遗漏，本手册中的所有信息也不构成任何
明示或暗示的担保。
7
基于 Kingbase FlySync 的实施项目生命周期 OverView
1.3 技术支持
• 人大金仓官方网站： http://www.kingbase.com.cn/ 您可以在官网中获得人大金仓所有产品的资讯信
息，销售联系方式
• 金仓数据同步工具子网站： http://kfs.kingbase.com.cn/ 您可以在产品子网站中获得最新的产品技术
资料、产品故障原因及问题分析、产品的应用解决方案、软件升级资料等等。
• 全国服务热线： 400-601-1188
• 人大金仓技术支持与反馈信箱： support@kingbase.com.cn
8 第 1 章 前言
第 2 章
文档概述
本文档用于指导 Kingbase FlySync 实施人员在项目实施阶段，对项目实施的全生命周期进行设计和管理，
覆盖项目从接手到交付客户的全部过程。
本文档从原理层面为实施人员给出一个 Kingbase FlySync 实施过程的全景地图，具体操作细节内容还需要
参考对应的参考手册或者最佳实践。
9
基于 Kingbase FlySync 的实施项目生命周期 OverView
10 第 2 章 文档概述
第 3 章
总体流程介绍
一个标准的 Kingbase FlySync 实施项目包含如下几个工作阶段
• 需求及可行性评估
针对具体项目，收集客户需求、系统软硬件环境、涉及同步的数据库版本、待同步表的数据
类型、主外键约束等信息，结合 Kingbase FlySync 的产品能力提前发现和规避部署过程中可
能出现的问题，减少后续不必要的返工投入和系统上线运行风险。
• 部署方案设计
规划 Kingbase FlySync 的物理和逻辑拓扑。包括每个组件需要运行的物理节点（管控平台、
比对服务、同步服务）、各组件之间的连接方式、系统运行时需要启用的服务数量、以及各个
服务之间的交互关系。
• 存量数据迁移
在进行增量数据同步之前，判断是否需要进行存量历史数据的迁移，并根据需要迁移的数据
量大小制定迁移策略并实施。
• 增量数据同步
根据实际的现场数据同步需求和部署方式限制，选择增量数据的抽取和加载方式。判断是否
需要进行数据转换、以及制定具体的转换策略。
• 功能和性能验证及问题解决
在正式上线前进行 1 比 1 的功能验证和性能压力测试；将实际产品运行过程中可能出现的
问题提前暴露出来，进行调试和优化，确保上线后系统运行稳定。
11
基于 Kingbase FlySync 的实施项目生命周期 OverView
• 运维方案设计
数据同步系统正式上线运行后，制定保障系统正常运行的运维策略和故障应急处理方案，包
括连续性、一致性和时效性的保障。
• 回切方案及系统重建
针对容灾场景，制定当主库发生故障，需要将业务切换至备库时的切换方案；以及主库恢复
后需要重新进行数据同步时的同步系统恢复方案。
12 第 3 章 总体流程介绍
第 4 章
需求及可行性评估
Kingbase FlySync 用于同构或者异构数据库之间的实时数据同步，能够正常运行的前提包括：
• 源端和目标端数据库品牌、版本、运行平台等进行过 Kingbase FlySync 兼容性测试，验证能够支持。
• 客户提供的物理或者虚拟机软硬件环境符合 Kingbase FlySync 的运行要求。
• Kingbase FlySync 将要部署的物理机器到源端和目标端数据库的网络物理可达，并且带宽限制符合
要求。
• 源端和目标端数据库正常运行，并且参数设置符合 Kingbase FlySync 的运行要求。
• 客户提供的数据库账号权限符合 Kingbase FlySync 的最低运行要求。
• 同步时涉及表包含的数据类型经过了 Kingbase FlySync 的兼容性测试。
• 同步时需要进行更新和删除操作的表上含有主键约束，或者可以唯一定位某行数据的列。
同时 Kingbase FlySync 的产品能力还应该能够满足客户的业务需求，包括：
• 产品运行的稳定性
• 数据同步的正确性和时效性
• 支持的数据转换能力可以覆盖业务诉求
本章的以下部分给出各项指标在评估时的关注点，并提供一些评估的手段
13
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1 需求评估时的关注点
4.1.1 软硬件平台是否在支持列表内
下面列出 Kingbase FlySync 已经测试过的软硬件平台，没有在列表中的软硬件平台不保证能够正常运行。

分类	数据类型
CPU	X86_64
飞腾 Phytium-FT1500A
龙芯 Loongson-3B3000
鲲鹏 920
兆芯
海光
操作系统	CentOS 6.X
CentOS 7.X
Kylin 4.0
普华 5.0
UOS 20
凝思 6.0
湖南麒麟 3.x
专用机	海光 CPU + 中科方德 OS
JRE	OpenJDK 1.8、 OracleJDK 1.8
浏览器	Google Chrome

4.1.2 网络及端口要求是否能够满足
Kingbase FlySync 正常运行时，需要的网络连通关系为：
• Kingbase FlySync 组件之间的网络
• Kingbase FlySync 与源端和目标端数据源之间的网络
Kingbase FlySync 运行本身需要的端口如下

端口	描述
11000/11001	Kingbase FlySync 远程管理/监控 RMI 端口
3112	KUFL 传输接口
8089	管控平台外部访问接口
8090	管控平台中心服务（比对服务需要独立部署时打开）
8091	比对服务监听接口（比对服务需要独立部署时打开）

14 第 4 章 需求及可行性评估
基于 Kingbase FlySync 的实施项目生命周期 OverView
此外， Kingbase FlySync 所在机器需要能够连通同步两端数据库，可以使用 ping 命令检查数据库所在机器
的连通性
ping xx.xx.xx.xx
使用 telnet 检查数据库端口是否开放
telnet xx.xx.xx.xx 端口
注意
• 隔离环境中，还需要确认客户提供的配置端口是否满足需求，具体检测方式以客户提供的方法为准
• 配置端口的数量需要和 KFS 部署的实例数保持一致；如果需要部署多个服务的 KingbaseFlySync 同步
多个不同的数据库数据，就需要提供多对隔离端口
4.1.3 源端数据库的版本及数据类型是否能够支持
Kingbase FlySync 目前支持的源端数据源如下

品牌	版本
KingbaseES	V7、 V8R2、 V8R3、 V8R6
Oracle	10g、 11g（ RAC）、 12c（ RAC）
SQL Server	2008、 2014、 2016、 2017
MySQL	5.7、 8.0

针对各个源端数据库，支持的数据类型如下（ Y 表示支持）。
4.1. 需求评估时的关注点 15
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1.3.1 Oracle

分类	数据类型	Logminer	REDO
数值类型	INT	Y	Y
INTEGER	Y	Y
SMALLINT	Y	Y
NUMBER	Y	Y
NUMERIC	Y	Y
FLOAT	Y	Y
REAL	Y	Y
DEC	Y	Y
DECIMAL	Y	Y
DOUBLE PRECISION	Y	Y
BINARY_DOUBLE	Y
BINARY_FLOAT	Y
字符类型	CHAR	Y	Y
NCHAR	Y	Y
VARCHAR2	Y	Y
NVARCHAR2	Y	Y
时间类型	DATE	Y	Y
INTERVAL	Y
TIMESTAMP	Y	Y
大对象类型	BFILE
CLOB	Y
NCLOB	Y
BLOB	Y
LONG	Y
其他类型	RAW	Y
ROWID	Y
UROWID	Y

4.1.3.2 MySQL

分类	数据类型	是否支持
数值类型	SMALLINT	Y
TINYINT	Y
MEDIUMINT	Y
INT	Y
INTEGER	Y

continues on next page
16 第 4 章 需求及可行性评估
基于 Kingbase FlySync 的实施项目生命周期 OverView
Table 1 – continued from previous page

分类	数据类型	是否支持
BIGINT	Y
DECIMAL	Y
DOUBLE	Y
FLOAT	Y
USMALLINT	Y
UINT	Y
UINTEGER	Y
数值类型	UBIGINT	Y
UTINYINT	Y
UMEDIUMINT	Y
UDECIMAL	Y
UDOUBLE	Y
UFLOAT	Y
字符类型	CHAR	Y
ENUM	Y
SET	Y
VARBINARY	Y
VARCHAR	Y
时间类型	DATE	Y
DATETIME	Y
TIMESTAMP	Y
YEAR	Y
TIME	Y
大对象类型	TINYBLOB
MEDIUMBLOB
BLOB
LONGBLOB
TINYTEXT	Y
MEDIUMTEXT
TEXT	Y
LONGTEXT
其他类型	BOOL	Y
BIT	Y
BINARY	Y

4.1. 需求评估时的关注点 17
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1.3.3 SQL Server

分类	数据类型	是否支持
数值类型	TINYINT	Y
SMALLINT	Y
INT	Y
BIGINT	Y
FLOAT	Y
SMALLMONEY	Y
MONEY	Y
DECIMAL	Y
REAL	Y
NUMERIC	Y
字符类型	CHAR	Y
VARCHAR	Y
VARCHAR(MAX)	Y
VARBINARY(MAX)	Y
NCHAR	Y
NVARCHAR	Y
NVARCHAR(MAX)	Y
时间类型	SMALLDATETIME	Y
DATETIME	Y
DATE	Y
TIMESTAMP	Y
TIME	Y
DATETIME2	Y
DATETIMEOFFSET	Y
大对象类型	IMAGE	Y
TEXT	Y
NTEXT	Y
其他类型	BIT	Y
BINARY	Y
VARBINARY	Y
UNIQUEIDENTIFIER	Y

18 第 4 章 需求及可行性评估
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1.3.4 KingbaseES

分类	数据类型	是否支持
数值类型	TINYINT	Y
SMALLINT	Y
INTEGER	Y
BIGINT	Y
NUMERIC	Y
REAL	Y
DOUBLE	Y
MONEY	Y
SMALLSERIAL	Y
SERIAL	Y
BIGSERIAL	Y
字符类型	CHAR	Y
NCHAR	Y
VARCHAR	Y
NVARCHAR	Y
BPCHAR	Y
BPCHARBYTE	Y
NAME	Y
TEXT	Y
时间类型	TIME	Y
TIME WITH TZ	Y
TIMESTAMP	Y
TIMESTAMP WITH TZ	Y
DATE	Y
INTERVAL	Y
大对象类型	BYTEA	Y
CLOB
BLOB
NCLOB
地理信息类型	POINT
CIRCLE
LSEG
POLYGON
BOX
PATH
其他类型	BIT	Y
BOOL	Y

continues on next page
4.1. 需求评估时的关注点 19
基于 Kingbase FlySync 的实施项目生命周期 OverView
Table 3 – continued from previous page

分类	数据类型	是否支持
XML	Y
VARBIT	Y
INET	Y
CIDR	Y
OID	Y
REGCLASS	Y
REGCONFIG	Y
REGDICTIONARY	Y
REGNAMESPACE	Y
REGOPER	Y
REGOPERATOR	Y
REGPROC	Y
REGPROCEDURE	Y
REGROLE	Y
REGTYPE	Y
JSON
JSONB
TSVECTOR
TSQUERY
UUID

4.1.4 目标端数据库的版本及数据类型是否能够支持
Kingbase FlySync 目前支持的目标端数据源种类和版本如下

品牌	版本
KingbaseES	V7、 V8R2、 V8R3、 V8R6
Oracle	10g、 11g（ RAC）、 12c（ RAC）
SQL Server	2008、 2014、 2016、 2017
MySQL	5.7、 8.0
KADB	V3
Kafka	2.1.0、 2.4.0
DM	V7、 V8

由于增量数据同步的难点主要在于是否能够获得源端的增量数据，故只要源端能够支持并解析出增量的数
据类型，在目标端都能够支持，本节不再重复列出。
20 第 4 章 需求及可行性评估
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1.5 源端到目标的数据同步组合是否能够支持
Kingbase FlySync 目前支持的源端和目标端组合如下

目标端
Ora cle	SQL Server	MySQL	Kingbase V7	Kingbase V8	KADB	Kafka	DM
源 端	Oracle	Y	Y	Y	Y	Y	Y
SQL Server	Y	Y	Y	Y	Y
MySQL	Y	Y	Y	Y	Y
Kingbase V7	Y	Y	Y	Y
Kingbase V8	Y	Y	Y	Y	Y	Y	Y

• 不在组合中的源端和目标端同步类型，原则上不支持。
• 不支持 MySQL 主从复制集群作为目标端。（ MySQL 主从数据不一致时，可能会导致 KFS 同步失败）
源端到目标端的数据类型映射关系，可以参考《Kingbase FlySync 数据类型映射参考手册》
4.1.6 数据库参数设置符合要求
数据库作为同步源端的时，通常需要开启归档和附加日志，或者配置一些额外的参数才可以捕获到增量
数据。
具体各种数据库的配置细节可以参考《Kingbase FlySync 部署前评估指南》
4.1.7 数据库账号权限符合要求
数据库作为同步源端时，通常需要有数据字典表和待同步表的查询权限；部分数据库还需要一些调用系统
包或者函数的权限；
数据库作为同步目标端时，通常需要待同步表上的写权限（ INSERT、 UPDATE、 DELETE）；对于配置了 DDL
同步的系统还需要在目标端的 DDL 执行权限；
具体针对各种数据库的权限配置细节可以参考《Kingbase FlySync 部署前评估指南》
4.1. 需求评估时的关注点 21
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.1.8 数据库主键或者唯一索引符合要求
Kingbase FlySync 同步过程中，数据在装载到目标端的过程中，会使用 SQL 语句的形式入库，针对 UPDATE、
DELETE 操作， SQL 语句中需要列出条件语句。比如
UPDATE table
SET col = value
WHERE key = value
Kingbase FlySync 构建 WHERE 语句的规则为：
• 如果存在主键，以主键作为条件
• 如果不存在主键，以所有列作为条件
当表上没有主键时，以所有列作为条件定位数据时，二进制、浮点数、大对象等类型，在异构数据库中存储
机制可能不一致（比如浮点数的精度），可能会导致定位失败，从而更新或者删除数据失败，故期望在部署
同步前在需要同步的表上加上主键约束。
具体针对各种数据库的主键约束检查方法可以参考《Kingbase FlySync 部署前评估指南》
4.1.9 同步时效性是否能够满足需求
除了功能之外，前期评估时，还需要关注性能指标。关于 Kingbase FlySync 的性能指标，可以参考最新的
《Kingbase FlySync 软件规格指标表.xlsx》。
4.1.10 转换能力是否能够满足需求
在一些复杂的业务场景中，同步两端的数据库品牌或者业务逻辑不一样，导致两端的表结构不一致。从而要
求 Kingbase FlySync 在数据同步过程中还要进行数据的转换。
关于 Kingbase FlySync 目前支持的转换能力，可以参考数据转换原理和配置 一节。需要在确保转换能力能
够支持的前提下，再进入到项目的实施阶段。
4.2 需求评估手段
针对需求评估， Kingbase FlySync 提供了如下几种辅助手段来加速评估过程。
22 第 4 章 需求及可行性评估
基于 Kingbase FlySync 的实施项目生命周期 OverView
4.2.1 业务需求调研表
在进行前期客户需求交流时，可以向客户发送《Kingbase FlySync 业务需求调研表.xlsx》，要求用户填写。
《Kingbase FlySync 业务需求调研表.xlsx》涵盖了客户业务诉求，数据同步两端的软硬件环境、数据库平台、
数据存量、增量、数据类型等信息。
填写的结果可以作为项目准入的参考，将非 Kingbase FlySync 业务场景，或者 Kingbase FlySync 当前能力
无法满足的项目排除掉。
4.2.2 业务评估指南和数据评估工具
实施人员在接触到实际的客户系统之后，还需要按照《Kingbase FlySync 业务评估指南》进行再次评估，防
止前期客户交流时填写的《Kingbase FlySync 业务需求调研表.xlsx》存在偏差。
具体的评估思路和具体的方法参见《Kingbase FlySync 业务评估指南》。
此外，为了简化评估工作量， Kingbase FlySync 还提供了数据评估工具，评估工具的主要设计参考了
《Kingbase FlySync 业务评估指南》。为了保证通用性，工具本身仅覆盖了和数据库相关的部分，关于软硬件
环境、数据转换等内容还需要按照《Kingbase FlySync 业务评估指南》中提供的方法进行人工确认。
4.2. 需求评估手段 23
基于 Kingbase FlySync 的实施项目生命周期 OverView
24 第 4 章 需求及可行性评估
第 5 章
部署方案
在进行部署方案的选择时，先介绍一下 Kingbase FlySync 产品中涉及到的组件，及其功能。
5.1 Kingbase FlySync 组件介绍
Kingbase FlySync 产品中包含四种组件，以独立进程的形式存在，可以部署在同一台机器，也可以部署在不
同机器，分别是
• 同步组件
以系统后台进程的形态常驻，用来进行增量数据的解析、传输、转换和入库；一般情况下一
台物理机器上仅存在一个实例（进程）；以多线程的形式支持配置为多个同步服务（比如一
对多数据汇集场景、或者多个一对一场景）；每个服务可以配置成不同的角色（源端和目标
端）；命令行工具、管控平台组件通过远程调用（ JMX）的方式与同步组件通信（查看运行状
态或者执行外部指令）。
• 管控平台
图形化监控和管理工具，主要功能包括同步组件的实时状态监控、存量数据迁移功能的图形
入口、数据比对功能的图形入口、用户和权限管理；通过远程调用（ JMX）的形式同多个后
台同步组件通信。
• 比对服务
数据一致性检验模块，比对服务出于资源占用的考虑，允许和管控平台部署在不同的物理机
器上（默认和管控平台部署在同一台机器上）；其界面集成在管控平台中；通过 SpringCloud
25
基于 Kingbase FlySync 的实施项目生命周期 OverView
的形式和管控平台通信。
• 元信息库
存储中间数据库的关系型数据库，主要为管控平台和比对服务服务。
下图是一个实际的一对多项目示例，用来展示各个组件的部署位置和交互关系。
• 黄色块是同步服务，其中源端采用了分离部署，部署在独立的服务器上；多个目标端采用
了集成部署，和数据库服务器部署在同一台机器上
• 绿色是管控平台服务，由于客户提供了独立的物理机器，进行了独立部署。
• 红色是比对服务，客户同样提供了独立的物理机器，也进行了独立部署。
• 管控平台和比对服务上，都安装了各自的元信息库。没有使用目标端生产数据库。
5.2 客户需求分析
部署方案的选择需要从客户诉求出发，典型的影响部署方案的考虑因素包括：
• 数据同步场景（容灾、分发、汇集）。
同步场景决定了数据同步服务的拓扑选择。
• 是否允许 Kingbase FlySync 和生产数据库部署在同一台物理服务器上。
如果用户出于资源占用影响的考虑，不允许 Kingbase FlySync 和生产数据库部署在同一台物
理服务器上，就需要考虑分离部署。
26 第 5 章 部署方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
• 是否提供独立的物理服务器。
如果客户提供了独立的物理服务器，就可以考虑将 Kingbase FlySync 的各个组件（特别是管
控平台和比对服务）部署在独立的物理服务器上，避免对生产数据库系统资源的占用。反
之，就只能和客户的生产数据库合并部署。
• 是否可以使用目标库作为管控平台的元信息库。
管控平台和比对服务运行时，需要后台元信息库支持。当客户允许将目标数据库同时用作元
信息库时，可以简化 Kingbase FlySync 的拓扑结构。
• 性能指标要求。
客户对同步的性能指标要求，决定了 Kingbase FlySync 源端数据的解析策略和目标端的数据
入库策略。
5.3 各组件的部署方案
5.3.1 同步服务部署方案
Kingbgase FlySync 支持多种拓扑方式，部署时根据实际情况进行选择，以下逐个介绍每种拓扑的使用场景。
5.3.1.1 一对一
最常用的拓扑类型，主要面向数据库容灾备份场景，用于单个数据源之间的数据同步
比如异构容灾时，从 Oracle 同步到 Kingbase 时就可以采用一对一的拓扑结构；另外，当出现多库需要同步
的场景时（比如 KES 同一个实例下的多个数据库），需要使用多个一对一的服务，单从物理架构上也表现为
一对一。
5.3. 各组件的部署方案 27
基于 Kingbase FlySync 的实施项目生命周期 OverView
5.3.1.2 一对多
主要面向数据分发场景，用于单个源端数据源向多个目标端数据源进行数据同步的场景
比如某些垂直性行业，需要共享总部数据到多个下级单位时，可以采用一对多的拓扑结构
5.3.1.3 多对一
面向数据集中场景，用于多个数据库的数据向一个数据库中汇集
28 第 5 章 部署方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
比如数据仓库建设场景中，需要将多个关系型数据库的数据汇集到同一个数据仓库中时，可以采用多对一
的拓扑结构
5.3.2 管控平台部署方案
Kingbase FlySync 管控平台是一个集中控制平台，包含的功能有：
• 同步服务的拓扑设计和部署
• 同步服务状态的图形化监控
• 初始数据迁移的图形入口
• 数据比对的图形入口
• 告警设置的图形入口
• 账号和权限管理
管控平台依赖元信息库，目前支持的元信息库包括：
• KingbaseES V8
• MySQL 5.7
对于比较大型的同步系统（比如一对多或者多个一对一），管控平台推荐部署在独立的物理机上，并且使用
独立的元信息库（同样，安装在独立服务器上）；
对于相对小型的同步系统（比如简单的一对一拓扑），管控平台可以考虑部署在目标端数据库所在机器上，
使用目标端数据库作为元信息库。（前提是目标端数据库是元信息库支持的类型，否则需要自行安装元信息
库）。
实际的方案选择时，还需要考虑客户是否会提供独立的物理服务器，如果资源无法满足，不能提供；则建
议部署在目标端数据库所在的服务器上。
5.3.3 比对服务部署方案
比对服务用来支撑数据一致性检验功能，由于做数据一致性检验时会耗费大量的 CPU 资源，如果和管控平
台部署在同一个物理节点，可能会导致监控界面反应变慢，出于性能考虑，将比对服务从管控平台中分离
出来，作为独立的进程存在。
如果同步系统中涉及的表数量相对较小，需要一致性检验的表较少或者检验频率低，建议将比对服务和管
控平台部署在同一台物理机器上，管理上相对简单。
如果同步系统中涉及的表数量比较多，数据检验的频率又要求比较高，可以考虑将比对服务部署在独立的
物理机器上。
需要注意：
• 比对服务同样需要元信息库的支持，元信息支持的数据库品牌和版本同管控平台一致。
• 比对服务的元信息库和管控平台的元信息库可以是不同的数据库实例。
5.3. 各组件的部署方案 29
基于 Kingbase FlySync 的实施项目生命周期 OverView
5.4 数据转换方案
除了涉及到 Kingbase FlySync 本身组件的部署之外，还有一点需要考虑的就是客户业务场景中是否需要进
行数据的转换。
关于是否需要转换，以及 Kingbase FlySync 是否能够满足客户的转换需求，已经在需求及可行性评估 一节
中进行了确认。
本节假设客户需要配置转换，并且 Kingbase FlySync 目前支持的转换规则能够满足客户需求。
5.4.1 支持的转换
Kingbase FlySync 目前支持如下几种数据转换能力
• 大小写转换（ casetransform）
– 当同步两端的数据库关键字大小写不一致时，可以进行关键字大小写转换。比如 Oracle 关键字默
认为大写， MySQL 默认为小写，当 Oracle 向 MySQL 同步时，配置 casetransform 可以将关键字
全部转为小写。
• 模式、表、列名称映射（ rename）
– 当同步两端表所在的模式名、表名、列名不同时，使用 rename 进行模式、表、列名称的转换。
• 表过滤（ replicate）
– 当仅需要同步部分表时，可以使用 replicate 进行表过滤，同步或者忽略部分表的数据。
• 列过滤（ dropcolumn）
– 当仅需要同步某些表上的某些列时，可以使用 dropcolumn 过滤掉多余的列
• DDL 过滤（ dropstatementdata）
– 在仅允许同步 DML 的情况时，可以使用 dropstatementdata 过滤掉 DDL 语句
• 同步类型过滤（ skipeventbytype）
– 针对不同表，可以设置仅允许不同的操作进行同步。比如针对 T1 表仅允许同步 INSERT，针对
T2 仅允许同步 INSERT 和 UPDATE
• 延迟同步（ delay）
– 允许源端和目标端的同步始终保持一个时间差，当源端发生误操作时，可以允许一定时间内在目
标端进行补救（数据找回）
30 第 5 章 部署方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
5.4.2 转换组合方式
在 KFS 中，允许不同的转换规则叠加使用，前一个转换规则的输出作为后一个转换规则的数据，比如配置
如下三个转换同时生效
casetransform,rename,dropcolumn
具体的逻辑是
1. 进行大小写转换
2. 按照大小写转换后的表名称，做模式名、表名、列名的映射
3. 按照映射后的结果，将不需要的列过滤掉
5.4.3 转换配置阶段
KFS 的转换目前可以配置在两个阶段
• 数据从源端抽取出来，存储为源端 KUFL 之前（部署在源端）
• KUFL 从源端传输到目标端，存储为目标端 KUFL 之前（部署在目标端）
建议的配置阶段为

转换名称	建议位置
dropstatementdata	源端
casetransform	目标端
rename	目标端
replicate	目标端
dropcolumn	目标端
skipeventbytype	源端
delay	目标端

以上出于可追溯和后期可自动化数据比对的考虑，将大部分的的过滤器都放在了目标端。如果某些场景对性
能要求较高，可以将数据过滤的过滤器配置在源端，比如
• replicate
• dropcolumn
• skipeventbytype
等运行过程中会删除待同步数据的转换规则，如果放置在源端，可以减少数据的存储和传输量，从而提高
同步效率。
5.4. 数据转换方案 31
基于 Kingbase FlySync 的实施项目生命周期 OverView
32 第 5 章 部署方案
第 6 章
存量数据迁移方案
使用 Kingbase FlySync 搭建异构数据同步环境时，源端数据库中往往存在着或多或少的存量数据。在部署数
据同步之前，首先应该保证同步两端数据库中的数据一致。
保持源端和目标端数据的方法包括使用数据库自带迁移工具和 Kingbase FlySync 初始迁移工具两种，具体
还需要根据实际情况进行选择。本节列出来存量数据迁移时需要考虑的因素，以及针对不同场景建议的
方案。
6.1 迁移方案选择时的考虑因素
选择存量数据迁移方案时需要考虑的因素包括：
1. 同步两端的数据库是同构数据库还是异构数据库
2. 同步两端的表结构信息是否一致
3. 迁移时是否允许停止数据库，以及可以停止数据库的时间长短
4. 迁移时目标数据库是否存在数据，是否允许清除。
需要迁移的内容包括：
1. 数据库表结构
2. 表数据
33
基于 Kingbase FlySync 的实施项目生命周期 OverView
6.2 数据库结构迁移
通常情况下，数据库结构信息是不会发生变化的，所以结构信息的迁移可以在任何时候进行，不会影响到
两端数据库的运行。
数据库结构迁移的方法包括：
• 使用备份还原
– 在同构数据库迁移时，推荐使用数据库自带的备份还原工具。此类工具能够保证在不产生任何损
失的情况下对数据库对象进行迁移。
• 使用金仓 KDMS 迁移工具
– 金仓 KDMS 迁移工具能够迁移的对象比较丰富，包括表、视图、索引、主外键、触发器、函数等；
支持多种异构数据库向 Kingbase 数据库的迁移。
• 使用 Kingbase FlySync 自带的表结构迁移工具
– 如果同步两端的数据库属于异构，并且迁移的对象只有表信息；或者迁移时两端的表结构不太一
致，需要做表或者列的名称映射、列过滤等转换时，此时可以选择 Kingbase FlySync 自带的表结
构迁移工具
以下对比三种方式的优缺点

方案	优点	缺点
数据库备份还原	无损的结构迁移（所有对象都 不会丢失）	仅支持同构数据库之间的迁 移
金仓 KDMS	基本覆盖了所有的数据库对 象	• 仅支持目标端 Kingbase 的场景 • 迁移时需要互联网环境
Kingbase FlySync	能 够 覆 盖 Kingbase FlySync 支持的所有异构组合系统自 带，不需要借助外部工具	仅支持表结构迁移，其他的 PLSQL 对象、以及外键信息 不支持

6.3 表数据迁移
6.3.1 迁移方案选择
完成表结构迁移后，就可以开始进行表数据的迁移。表数据迁移的方法包括：
• 使用数据库备份还原工具
34 第 6 章 存量数据迁移方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
– 在同构数据库迁移时，推荐使用数据库自带的备份还原工具。由于是数据库的配套工具，数据库
原生备份还原工具的可靠性和性能都有保证。
• 使用数据库自带的数据迁移工具
– 通常的商业数据库产品也会配备数据迁移工具，特别是金仓数据库自带的迁移工具，在数据迁移
的完备性和性能方面都表现很好。
– 目前金仓数据库自带的迁移工具只能够处理目标端为金仓数据库的情形。
– 数据库自带迁移工具在迁移数据时允许目标数据库存在数据。
• 使用 Kingbase FlySync 自带的表数据迁移工具
– 如果同步两端的数据库属于异构，或者迁移时两端的表结构不太一致，需要做表或者列的名称映
射，此时可以选择 Kingbase FlySync 自带的表数据迁移工具。
– 自带表数据迁移工具在迁移数据时允许目标数据库存在数据。
– 在存量数据小于 200GB 的情形下，可以考虑使用 Kingbase FlySync 自带的表数据迁移工具。
和表的结构信息不同，在生产系统中，表数据通常是不断变化的。并且经常需要在表数据迁移完成后，紧接
着进行『无缝』的数据同步。所以在选择表数据迁移方案时，还要考虑如下的因素：
• 源端系统的存量数据大小
– 针对较小的存量数据场景，通常一次性迁移所有的数据，方案选择也比较简单
– 针对较大的存量数据，通常需要分批，分次进行迁移，并且通常需要使用组合的数据迁移方案
• 迁移时源端生产系统是否可停机，以及可以允许停机的时长
– 如果数据迁移时源端系统可停机时长能够覆盖所有存量数据迁移时间，迁移方案的选择也会相对
简单，仅需要考虑两端数据库是同构还是异构，同构且表结构一致时选择数据库备份还原，异
构或者表结构有变化时根据情况选择数据库迁移工具或者 Kingbase FlySync 自带的表数据迁移
工具。
– 如果数据迁移时源端系统可停机时长无法覆盖所有存量数据的迁移时间，此时就要考虑将数据进
行拆分，分批、多次进行数据迁移。每批数据的迁移方案根据实际情况选择。
• 存量数据的变化范围
– 如果源端系统的存量数据变化范围比较小，对变化数据涉及表的迁移可以在停机时间内完成。就
可以分两批进行数据迁移：首先将不变化的数据使用备份还原或者其他工具进行分批、分次的迁
移；然后在系统停机时间内将变化数据涉及的表进行一次性迁移。
– 如果源端系统的存量数据变化范围比较大，并且对变化数据涉及表的迁移无法在停机时间内完
成。就需要结合数据同步的能力选择组合方案进行数据迁移，比如在第 1 个停机时间内，迁移某
些表，然后配置已迁移表到同步列表中。第 2 个停机时间内迁移另外一些表，再将新迁移的表增
加到同步列表中，以此类推，直到所有的表完成迁移。
综上，根据实际情况，迁移方案的选择可以使用如下表进行表示
6.3. 表数据迁移 35
基于 Kingbase FlySync 的实施项目生命周期 OverView

停机时长足够	停机时长不够
品牌和结构一致	备份还原工具	备份还原工具 + KFS 同 步
品牌一致，结构不一 致	KFS 工具	KFS 迁移 + KFS 同步
品牌不一致，结构一 致	目标端是 KingbaseES	数据库迁移工 具	数据库迁移 + KFS 同步
目 标 端 不 是 King baseES	KFS 工具	KFS 迁移 + KFS 同步
品牌和结构都不一致	KFS 工具	KFS 迁移 + KFS 同步

另外，对于某些数据量较小，并且不允许停机的场景（此类场景比较罕见，但也不排除），可以考虑使用
KFS 自带的无缝搬迁功能。详情参见《Kingbase FlySync 管理手册》
6.3.2 表结构不一致时的数据迁移
当同步两端的表结果不一致，数据迁移时需要转换时，数据库备份还原工具或者数据库自带的迁移工具往
往无法使用，此时只能使用 Kingbase FlySync 自带的数据迁移工具；
Kingbase FlySync 自带的数据迁移工具基于数据同步的原理进行实现，在部署数据同步时，会设置结构不一
致时两端数据转换的规则，（关于目前同步服务支持的转换规则，参见数据转换方案 章节中的描述。） KFS
数据迁移工具会识别配置规则，对数据进行转换后再迁移。 KFS 数据迁移工具的使用方法，参考《Kingbase
FlySync 管理手册》。
6.3.3 数据迁移出错时的处理办法
根据不同的数据迁移方案，需要选择不同的错误处理策略
6.3.3.1 备份还原工具
当数据库备份还原工具做数据迁移时，一般不会出现错误，如果出现错误时，可以分析具体的报错原因，
看是否存在数据恢复冲突，数据库版本不一致等问题。根据实际情况调整恢复参数后，重新还原。
36 第 6 章 存量数据迁移方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
6.3.3.2 数据库迁移工具
金仓数据库自带的数据迁移工具支持《二次迁移》功能，即当发生数据迁移错误时，允许对发生错误的表进
行再次迁移，不会影响到已经迁移成功的表数据。
6.3.3.3 自带数据迁移工具
Kingbase FlySync 自带的数据迁移工具目前还没有可靠的容错办法，当某个迁移任务发生错误时，需要重新
执行整个迁移任务。
所以当使用 Kingbase FlySync 进行数据迁移并且需要迁移的表比较多时，在建立迁移任务时建议采取少量
多次的策略。即将需要迁移的表拆分到多个迁移任务中（最多 50 个为一组），当某个任务中存在迁移出错
的表时，可以针对该任务单独分析，排除掉出错的表后，再次执行。
6.4 迁移结果确认
存量数据迁移完成后，在正式进行增量数据同步之前，还需要进行一次确认，确保两端的数据是一致的。
数据一致性的确认可以使用 KFS 自带的比对工具，目前比对工具支持精简和全量两种比对方式。
可以根据需要进行选择

方案选择
迁移前后两端数据无变化	精简比对
迁移前后两端数据发生 了变化	整体数据量 小	全量比对
整体数据量 大	先进行精简比对，然后对精简比对不一致的表进行 全量比对

6.4. 迁移结果确认 37
基于 Kingbase FlySync 的实施项目生命周期 OverView
38 第 6 章 存量数据迁移方案
第 7 章
增量数据同步方案
增量数据同步的配置分三个部分：
• 源端数据库抽取
• 数据转换
• 目标数据库加载
每个部分的配置方案需要根据实际场景需要进行选择，本节分阶段给出具体的指导原则。
7.1 源端抽取方式选择
源端抽取方式在配置时，需要考虑的因素包括：
• 源端的数据库品牌
• 是否允许 Kingbase FlySync 产品和源端数据库部署在同一台物理机器上
目前针对不同的源端数据库， KFS 提供的数据抽取方案如下
39
基于 Kingbase FlySync 的实施项目生命周期 OverView
7.1.1 Oracle
Oracle 作为源端时， Kingbase FlySync 提供两种增量数据抽取方式
• Logminer
• redo
分别的优缺点以及使用场景为参见下表

抽取方式	优点	缺点
logminer	• 允许和数据库部署在不 同机器上	• 不支持大对象 • 不支持 DDL • 性能比 REDO 慢
REDO	• 支持大对象 • 支持 DDL • 性能快	• 必须和数据库部署在同 一台机器上

7.1.2 SQL Server
针对源端为 SQL Server 的场景， KFS 目前仅支持一种抽取方式
• CDC
CDC 方式增量数据抽取的优缺点如下

抽取方式	优点	缺点
CDC	• 允许和数据库部署在不 同机器上	• 不支持 DDL

40 第 7 章 增量数据同步方案
基于 Kingbase FlySync 的实施项目生命周期 OverView
7.1.3 MySQL
针对源端为 MySQL 的场景， KFS 目前支持两种抽取方式
• 集成 REDO
• 分离 REDO
两种抽取方式从功能层面上是一致的，区别在于是否和数据库部署在同一台物理机器上，以及细微的性
能区别

抽取方式	优点	缺点
集成 REDO	• 性能稍好 • 无额外磁盘空间占用	• 必须和数据库部署在同 一台机器上
分离 REDO	• 允许和数据库部署在不 同机器上	• 性能稍弱 • 需要将数据库日志获取 到本地，占用磁盘空间

7.1.4 KingbaseES
针对源端为 KingbaseES 的场景， KFS 目前支持两种抽取方式
• xlogical (针对 KES V7)
• decoderbuf (针对 KES V8）
两种抽取方式针对不同的 KES 版本，各自优缺点如下

抽取方式	优点	缺点
xlogical (针对 KES V7)	• 原生 DDL 支持	• 必须和数据库部署在同 一台机器上
decoderbuf (针对 KES V8)	• 允许和数据库部署在不 同机器上	• 基于触发器的 DDL 支持

7.1. 源端抽取方式选择 41
基于 Kingbase FlySync 的实施项目生命周期 OverView
7.2 数据转换原理及配置
关于 Kingbase FlySync 目前支持的转换能力，可以参考数据转换方案 章节中的描述。包括
• 支持的转换
• 转换组合方式
• 转换配置阶段
7.3 目标端入库方式选择
当前版本的 KFS 入库方式是固定的，不支持单独配置。
针对关系型数据库， KFS 以数据库事务为单位使用 PBE 的形式入库；针对其他非关系型数据库， KFS 同样
以事务为单位采用数据源特有的方式入库

目标数据源	入库方式
Oracle	PBE
SQL Server	PBE
MySQL	PBE
KingbaseES	PBE
KADB	PBE
DM	PBE
Kafka	专用方式
SQL 文件	专用方式

针对某些特殊的场景，还可以配置并行入库特性来提高性能，比如针对数据采集的场景，所有的操作都
是 INSERT ，事务的先后顺序并不会影响正确性时，可以考虑配置多个入库通道。具体配置方式可以参考
《Kingbase FlySync 安装部署手册》
42 第 7 章 增量数据同步方案
第 8 章
功能和性能验证及问题解决
8.1 验证目标
数据同步项目部署好后，需要进行完善的上线前验证。作为数据库系统，开发商或者集成商在业务上线前通
常会进行全面的功能和性能覆盖，而同步项目通常是业务系统上线之后，作为容灾方案出现。同步项目通常
没有机会做单独的适配或者验证，所以正式上线之前的验证就变成同步软件生命周期中最重要，也是最容
易忽视和弱化的环节。
没有经过全方位验证的数据同步系统可能在线上运行过程过发生未预料的问题，导致同步失败，进一步导
致作为数据容灾方案的备份数据失效。
同步系统的验证包括功能和性能两个方面，需要保证上线前经过了 1:1 的验证。
8.2 验证方法
8.2.1 功能验证
功能测试时，只需要关注一点
测试过程是否覆盖了所有需要同步的表
具体的测试步骤为
1. 根据同步的需求部署好两端的同步服务，并正常运行
43
基于 Kingbase FlySync 的实施项目生命周期 OverView
2. 重置同步服务，使两端的 KUFL 存量数据为空
3. 在源端进行全面的系统功能测试（通常由应用厂商进行）
4. 观察生成的增量数据能否在目标端入库正成功；出现错误时需要具体分析
• 如果是配置错误，就需要调整配置（包括 Kingbase FlySync 和数据库）。
• 如果是数据本身错误（比如目标端存在唯一约束，源端却不存在；或者异构数据库对数据的约束
不一致，比如 KingbaseES 中允许主键列两端存在空格， MySQL 却不允许），可以选择忽略或者
协调应用厂商进行业务排查。
• 如果发现是因为出现了 Kingbase FlySync 无法支持的数据类型，可以考虑在用户同意的情形下过
滤列（此类问题一般会在实施前评估阶段暴露并告知用户，如果在测试阶段才发现问题，说明之
前的工作存在疏忽）。
• 如果存在更新或者删除数据失败（通常会打印 WARNNING 信息，不会停止同步），则可能存在无
主键或者主键类型不对的情况，具体可以等待测试完成后进行一轮数据比对，根据两端数据是否
一致进行判断（同样，针对主键的评估也应该在实施前评估阶段暴露并告知用户）
5. 测试完成后，还需要完成两个工作
• 使用 KFS 自带的命令行工具分析本次测试过程覆盖到的表数量和总体需要同步表数量之间的占比
– 理想情况下应该覆盖到 100%
– 覆盖 85% 以上说明测试比较充分，但是需要将未覆盖的表列出来，由用户或者开发商进行
确认，确保未覆盖到的表在实际生产过程中不会用到。
– 覆盖 50% 以下说明测试不够，需要重新设计测试用例
• 使用数据比对工具对两端的数据进行全量比对，确认数据同步的正确性
– 只有同步后两端的数据完全一致，才能说明测试的正确性
– 比对方法参见 数据一致性校验
8.2.2 性能验证
完成功能测试并确认符合要求后，还需要进行性能测试。性能测试需要关注
1. 测试过程应该覆盖大部分频繁使用的业务场景
2. 测试的业务压力需要大于实际生产环境（生产负载的 1.5 倍为宜）
具体的测试步骤为
1. 根据同步的需求部署好两端的同步服务，并正常运行
2. 重置同步服务，使两端的 KUFL 文件为空（重置方法，参考《Kingbase FlySync 命令行工具参考手册》）
3. 在源端运行性能测试用例
4. 观察源端的 KUFL 生成情况
44 第 8 章 功能和性能验证及问题解决
基于 Kingbase FlySync 的实施项目生命周期 OverView
• 最新 KUFL 中的时间和当前系统的时间差（表示数据的解析延迟）
• 如果延迟较大，说明数据解析存在性能瓶颈，就需要考虑调整整体的配置（如果存在瓶颈可以考
虑配置多个解析服务，各自解析不同的表）
5. 观察目标端的 KUFL 生成情况
• 最新 KUFL 中的时间和当前系统的时间差（表示数据的传输延迟）
• 如果延迟较大，说明数据传输存在性能瓶颈（可以考虑配置多个解析服务和入库服务，各自同步
不同的表，多条通道进行数据传输）
6. 观察目标端的数据入库情况
• 目标端 appliedLastSeqno 和最新 KUFL 差值（表示数据的入库延迟）
• 如果延迟较大，说明数据入库存在瓶颈（可以考虑目标端配置多写，或者开启源端的小事务合并
特性）
7. 测试完成后，还需要使用数据比对工具对两端的数据进行全量比对，确认数据同步的正确性
• 只有同步后两端的数据完全一致，才能说明测试的正确性
• 比对方法参见 数据一致性校验
8.3 验证效果评估
完成功能和性能测试后，还需要输出测试评估报告，具体内容已经在上述的功能测试和性能测试章节中进
行了描述，总结如下

测试类型	关注点
功能测试	• 表的覆盖情况（已覆盖和未覆盖表列表） • 测试过程中的错误和警告，以及具体的 处理方案（需要和用户达成一致） • 测试完成后，进行数据比对的结果
性能测试	• 表的覆盖情况（已覆盖和未覆盖表列表） • 各个阶段的数据同步延迟，以及是用到 的性能调整方案 • 测试完成后，进行数据比对的结果

无论是功能测试还是性能测试，在测试完成后都需要进行全面的数据比对，当数据不一致时，需要进行深
入分析，定位是哪个阶段丢失了数据，并进行处理。（参见功能测试部分给出的处理思路）
8.3. 验证效果评估 45
基于 Kingbase FlySync 的实施项目生命周期 OverView
测试报告可以参考《KFS 上线前测试报告.xlsx》
8.4 性能问题调整方法
在性能测试中，如果发现某个阶段的同步延迟比较大，就需要进行性能调整（参见性能测试部分给出的调整
思路）
以下根据延迟的位置，给出具体的调整思路和方法
8.4.1 源端解析瓶颈性能调整
解析瓶颈需要具体分析引发原因，根据原因进行调整，具体包括
• 超大事务导致的解析慢
此类问题的识别方法为：源端的业务压力很大， Kingbase FlySync 也一直处于 ONLINE 状态, 执行如
下命令
kufl [-service 服务名] -list last
发现最后的一条解析数据总是不变。此时可以判定有大事务一直解析不出来，处于阻塞状态。解决办
法为，在源端配置种增加如下大事务拆分配置
property=replicator.extractor.dbms.minRowsPerBlock=1000 -- 表示最大 1000 条数据拆分为一个
事务
• 源端数据库业务量大，导致的解析性能跟不上
如果发现源端的解析性能跟不上，可以考虑在源端部署多个服务，每个服务解析不同的表
[服务 1]
...
svc-extractor-filters=replicate
property=replicator.filter.replicate.do=PUBLIC.TABLE1,PUBLIC.TABLE2
...
[服务 2]
...
svc-extractor-filters=replicate
property=replicator.filter.replicate.do=PUBLIC.TABLE3,PUBLIC.TABLE4
...
[服务 3]
...
svc-extractor-filters=replicate
(continues on next page)
46 第 8 章 功能和性能验证及问题解决
基于 Kingbase FlySync 的实施项目生命周期 OverView
(continued from previous page)
property=replicator.filter.replicate.ignore=PUBLIC.TABLE1,PUBLIC.TABLE2,\
PUBLIC.TABLE3,PUBLIC.TABLE4
前两个服务仅同步特定表，最后一个服务同步前两个服务未同步的所有表（将前面两个服务已经同步
的表过滤掉）
实际部署时，可以根据现场环境调整服务数量，和每个服务需要同步的表。
注意:
源端部署了多个服务后，目标端也需要一一对应的部署多个服务。
• 源端数据库访问慢，导致的解析性能跟不上
Kingbase FlySync 源端每解析出一个事务，在事务存储为 KUFL 的同时，还需要更新数据库中的断点
信息表。如果数据库访问特别慢（具体需要进行 profile 才能定位），可以考虑不在数据库中记录断点
信息。
– 方案 1，在文件中记录断点信息
[服务 1]
...
property=replicator.store.kufl.dataSource=file_metadata
...
– 方案 2，不记录断点信息（使用源端 KUFL 作为断点信息，弊端是无法手动调整断点）
[服务 1]
...
property=replicator.store.kufl.dataSource=
...
• 源端数据库访问慢、数据变化涉及的表数量多，导致的解析性能跟不上
Kingbase FlySync 源端在解析增量时，需要从数据库查询表的元信息，如果数据库访问特别慢（具体
需要进行 profile 才能定位），需要查询元信息的表又特别多，可以考虑启动时一次性缓存大量元信息。
[服务 1]
...
property=replicator.extractor.dbms.cacheMeta=true
proterty=replicator.extractor.dbms.cacheSize=1000
...
备注：
此参数仅支持源端为 Oracle Redo 时
8.4. 性能问题调整方法 47
基于 Kingbase FlySync 的实施项目生命周期 OverView
8.4.2 网络传输瓶颈性能调整
Kingbase FlySync 在传输过程中需要进行对象的序列化和反序列化，所以在有些场景下，并不能将网络带宽
全部占用，可以使用增加传输通道的形式优化传输性能。
增加传输通道的配置方式参见目标端入库瓶颈性能调整 中的描述。
如果网络带宽本身变成瓶颈，则需要考虑升级硬件设备
8.4.3 目标端入库瓶颈性能调整
目标端入库瓶颈是比较常见的性能瓶颈，调整方法也比较多，具体的解决方法可以根据瓶颈大小进行选择，
指导方向包括
• 调整每次提交数据量大小
调整目标端参数 replicator.global.buffer.size ，提高 10 倍或者更高 (减少目标数据库 commit
次数)
property=replicator.global.buffer.size=100 -- 默认为 10
• 增加入库通道数量（ 1 读 N 写）
用在业务比较简单的场景，比如全部为 INSERT 操作；或者针对某些表的 UPDATE、 DELETE 操作，不
存在事务之间的先后顺序依赖
配置方法为，在目标端增加如下参数
svc_parallelization_type=memory
channels=4 -- 根据实际需要调整
property=replicator.store.parallel-queue.partitionerClass=\
com.continuent.tungsten.replicator.storage.parallel.RoundRobinPartitioner
• 增加传输通道数量（ N 个 1 读 1 写）
目标端增加多个服务，每个服务同步特定的表，比如
[服务 1]
...
svc-remote-filters=replicate
property=replicator.filter.replicate.do=PUBLIC.TABLE1,PUBLIC.TABLE2
...
[服务 2]
...
svc-remote-filters=replicate
property=replicator.filter.replicate.do=PUBLIC.TABLE3,PUBLIC.TABLE4
(continues on next page)
48 第 8 章 功能和性能验证及问题解决
基于 Kingbase FlySync 的实施项目生命周期 OverView
(continued from previous page)
...
[服务 3]
...
svc-remote-filters=replicate
property=replicator.filter.replicate.ignore=PUBLIC.TABLE1,PUBLIC.TABLE2,\
PUBLIC.TABLE3,PUBLIC.TABLE4
...
前两个服务仅同步特定表，最后一个服务同步前两个服务未同步的所有表（将前面两个服务已经同步
的表过滤掉）
实际部署时，可以根据现场环境调整服务数量，和每个服务需要同步的表。
分服务部署方案的好处不仅是增加了传输通道，更重要的特点在于：将某些操作频繁的表分出来单独
入库，最大限度的利用 Kingbase FlySync 的 PBE 特性，提高了单通道的入库性能。
注意： 采用目标端配置多个传输通道的方案，会改变原有的部署架构，对初始数据搬迁产生影响。建
议初始搬迁在没有进行通道拆分之前完成，如果运行过程中需要进行初始搬迁，则需要针对目标
端的每个服务，分别进行初始搬迁。
• 同时增加传输通道数量和入库通道数量（ M 个 1 读 N 写）
如果经过前面三个调整方式，性能还无法满足需求，可以考虑将第 2 种方式和第 3 种方式结合起来
– 部署多个服务
– 每个服务本身再使用多通道入库
8.4. 性能问题调整方法 49
基于 Kingbase FlySync 的实施项目生命周期 OverView
50 第 8 章 功能和性能验证及问题解决
第 9 章
运维方案设计
同步系统上线运行后，需要做定期巡检和维护，以保证系统正常、平稳的运行。
9.1 日常运维的关注要素
同步系统运行过程中，巡检需要关注的内容包括
• 持续性
– Kingbase FlySsync 程序本身是否运行正常
– 操作系统的资源占用率是否正常
– 网络资源占用及硬件状态是否正常
• 正确性
– 同步两端的数据是否一致
• 时效性
– 同步性能是否满足要求
51
基于 Kingbase FlySync 的实施项目生命周期 OverView
9.2 运维频次和产出物
运维的频次分为
• 日常巡检
• 月度巡检
• 季度巡检
• 年度巡检
需要关注的具体内容可以参考《Kingbase FlySync 巡检报告.xls》。
同时， Kingbase FlySync 还提供了《巡检工具》，用来缩短每次巡检时花费的时间，同时提高巡检结果的准
确性。
9.3 数据一致性检验和差异修复
9.3.1 检验时的考虑因素
针对数据一致性检验的方案设计，主要围绕以下几个维度进行考虑：
• 哪些业务表需要进行检验？（比什么）
• 采用什么检验方式？（怎么比）
• 检验的执行时间以及周期？（什么时候比）
• 如何处置检验结果？（发现不一致时怎么办）
9.3.1.1 检验哪些业务表
数据检验的目的是为了检验源和目标端的数据一致性，对同步中可能存在的异常进行查漏补缺。首先需要符
合以下条件：
• 需要进行数据同步的表
• 频繁变更且在业务中较为重要的表
同时考虑到数据检验功能自身的限制, 对需要进行数据检验的表做如下约束：
• 数据量在千万记录数以下（考虑到比对的时效性，如果比对时间充足，可以放开此要求）
• 含有主键或者唯一索引标识（全量比对时，如果没有主键参照，性能会很慢）
52 第 9 章 运维方案设计
基于 Kingbase FlySync 的实施项目生命周期 OverView
9.3.1.2 检验方式选择
KFS 目前提供两种检验模式，分别为精简检验和详细检验。
• 记录数检验
– 仅对源和目标端中每张表的数据记录数进行检验。
– 优点是检验速度较快，对数据库资源占用较小；
– 缺点是仅检验记录数，无法识别具体字段的数据差异。
• 详细检验
– 逐行逐列的检验每张表的数据差异，并对差异结果进行标识展示。
– 优点是检验结果较为详细，并可对有差异的数据进行手动推平处理；
– 缺点是检验速度慢，算法复杂检验时会占用部分数据库资源。
根据以上两种检验的模式的特性，对于：
• 数据量较小
• 业务中地位较为重要
的表，推荐使用详细检验；反之，推荐使用记录数检验。
9.3.1.3 检验的执行时间以及周期
数据检验功能的工作机制如下：
1. 分别从源端和目标端对要进行检验的表数据进行排序
2. 查询排序后的数据
3. 对查询出的数据逐行逐列进行比较。
因此在此过程中主要使用的资源为：
1. 源端数据库节点的 cpu 资源、网络 IO 资源
2. 目标端数据库节点的 cpu 资源、网络 IO 资源
3. 检验部署节点的 cpu 资源
从上述三个方面来看，检验时会对源端和目标的数据库资源有部分占用，因此推荐在业务低峰期进行数据
检验。
同时由于用户的业务具有周期性，比如
• 采集类系统，每周为一个业务周期；
• 交易系统，每天为一个周期；
9.3. 数据一致性检验和差异修复 53
基于 Kingbase FlySync 的实施项目生命周期 OverView
我们可以根据业务周期进行周期性的数据检验。
综上，推荐的检验策略为：
• 业务低峰期进行数据检验
• 根据业务特点进行周期性检验。
9.3.1.4 数据不一致时的处理方案
记录数模式检验结果
• 精简检验结果只有数据条数的显示，对于数据条数一致的数据，原则上可以不关注。
• 对于数据条数不一致的数据，需对其单独创建详细检验进行进一步的检验。
详细模式检验结果
差异产生的原因有以下几种：
• 问题 1，网络延时导致源端同步的数据还在途中，导致数据暂时不一致（比对时业务繁忙或者网络带
宽较低导致）
• 问题 2，用户异常操作目标端业务库的数据
• 问题 3，数据同步过程中由于网络或其他故障导致的数据不一致（极小概率）
上述原因对应不同的处理方式：
• 问题 1，需要先和用户沟通网络带宽是否充足在确认带宽正常后，在业务低峰期或者无业务情况下再
次进行检验，确认检验结果 (结果无差异或转为问题 2 或问题 3)
• 问题 2，需和用户沟通并确认是否对目标端数据进行过手动操作，从而确定接下来对于异常数据的处
理方式。
• 问题 3，首先手动将差异数据推平，其次检查实时同步中的日志信息，定位异常发生的原因，并对异
常进行解决。
9.3.2 数据检验配置举例
此处以实际中遇到的某项目作为案例对上述设计进行示例。
用户的业务信息情况大致如下：

参考项	典型值
要进行同步的表数量	23 张
最大的表记录数	300W
业务高峰期	早上 9 点至下午 15 点
业务类型	交易系统，每天为一个业务周期
表中数据是否重要	交易数据，需保证完全一致

54 第 9 章 运维方案设计
基于 Kingbase FlySync 的实施项目生命周期 OverView
根据上述信息，我们最终决定使用的检验方案如下：
1. 要检验哪些表？
• 同步中涉及的 23 张业务表
2. 采用什么检验方式？
• 由于数据量相对较小，并且业务数据准确性要求高，因此采用详细检验。
3. 检验的执行时间以及执行周期？
• 每天高峰期为早 9 点至下午 15 点，并且每天如此，因此检验周期设计为每天凌晨 3 点进行检
验，执行频率为每天一次。
4. 数据不一致时的处理方式
• 数据重要，因此对差异结果全部推平。
9.4 故障和异常处理
在巡检过程中，如果发现了异常情况，就需要进行及时处理，并同时制定针对异常情况的规避措施，保证
异常不会再次出现。包括
• KFS 服务异常
– 发现 Kingbase FlySync 没有正常运行时，需要深入分析进程的异常原因；并做好恢复工作
* 内存溢出：调整内存大小，设置自动恢复或者分析自动恢复未生效的原因
* 如果是短期内没有正常运行，仅需要启动 KFS，使其继续工作
* 如果长时间没有正常运行，导致的断点无法续传，就需要重新部署或者使用数据检验工具检
验并推平数据后重置 KFS，使其继续工作
• 数据同步异常
– 两端数据不一致时，需要分析导致数据不一致的原因，并制定避免不一致再次发生的策略
* 如果是因为目标端进行了人为写入操作，导致数据冲突而产生的数据不一致，需要及时联系
客户进行确认，必要时还要调整同步策略
* 如果是因为同步工具本身丢失数据，就需要进一步查看系统日志，定位数据丢失的环节，并
针对性的制定处理方案
– 存在数据延迟时，需要分析延迟的原因并制定改进措施
* 确定数据延迟发生的环节，根据功能和性能测试 中给出的方法进行调整
• 授权文件是否在有效期内
– 部分前期项目使用了试用期授权，在巡检时需要注意授权是否将要过期，提前规避风险。
故障和异常的具体处理策略，可以参考《Kingbase FlySync 故障处理手册》
9.4. 故障和异常处理 55
基于 Kingbase FlySync 的实施项目生命周期 OverView
56 第 9 章 运维方案设计
第 10 章
回切方案及系统重建
Kingbase FlySync 的主要使用场景为数据容灾和数据集中与分发。在配合 KingbaseES 做数据库国产化替代
时，有时也会被用作回切方案，本节描述回切方案的含义、使用场景、和配置方法。
10.1 回切的含义
国产数据库替代过程中，因用户对国产数据库的稳定性、处理能力有顾虑，需要提供平滑替代的解决方案，
帮助用户逐步从国外数据库切换到国产数据库，在此过程中应尽可能保证切换的平滑进行，尽可能对减小
对上层业务的影响。
利用异构数据同步软件，实现国外数据库与国产数据库之间的数据实时同步，保证国外数据库与国产数据
库之间的数据时刻保持一致，一个数据库作为主库对外承载业务，另一个作为备库，随时应对所需的业务
切换，当因业务驱动需要对数据库进行切换时，原作为备份的数据库，可以迅速接管。
通常，国产替代过程可分为 3 个阶段：
1. 国外数据库作为主业务库，国产数据库作为备份库，数据实时保持一致，备库可以对外分担查询的业
务压力。
57
基于 Kingbase FlySync 的实施项目生命周期 OverView
2. 第一阶段稳定运行一段时间后，可将国产数据库切换为主业务库，国外数据库作为备份库，数据实时
保持一致。
3. 国产数据库的各项能力得到充分验证后，用户可根据实际情况将国外数据库彻底下线停止使用。
58 第 10 章 回切方案及系统重建
基于 Kingbase FlySync 的实施项目生命周期 OverView
10.2 什么时候需要回切
回切一般发生在第二阶段中，当发现国产数据库无法满足应用的稳定性或者性能需求，需要紧急撤回到国
外库时，就需要进行回切。
回切的过程需要速度快，数据不丢失或者少丢失。
10.3 回切的配置方式和回切方法
10.3.1 配置方法和注意事项
配置双轨并行时，需注意两端节点都需配置为主节点（即： role=master），即两端节点都按照其为 master
时所配置的 ini 信息进行配置。
由于双轨并行时会切换源端及目标端，所以如需配置过滤器时还需要注意
svc-extractor-filters
svc-remote-filters
配置时最好不存在重复的转换规则。如果业务需要必须配置转换同名的转换规则就需要进行反复的验证和测
试，保证业务逻辑的正确性。比如
• 配置了名称映射转换时，要保证两个方向的映射规则相互对应。
• 配置了大小写转换时，要保证两个方向的转换正好相反。
• 其他转换，也需要根据需要进行调整和测试
10.2. 什么时候需要回切 59
基于 Kingbase FlySync 的实施项目生命周期 OverView
其他配置项和正常的单向同步一致，具体参见《双轨并行部署说明.docx》和《双轨并行最佳实践.docx》
10.3.2 回切方法
当出现异常需要回切时，分一下几个步骤
1. 停止源端的业务系统
2. 使用回切命令进行同步方向的转换
3. 使用预先准备的数据检验方案，验证两端的数据一致性
4. 启动目标端的备用业务系统
5. 验证并确认反向同步正常
当发生异常需要回切时，使用如下命令进行回切
repswitch -conf switch.conf switch
10.4 回切后如何恢复同步环境
国产系统因为各种因素，引发系统回切时，一般会进行国产系统的再次改造、测试，待消除引发回切的因素
后，还需要再次进行一次国产化 TD 的切换方案。
二次方案和第一次一致
1. 将国外系统的数据迁移至国产系统，参见存量数据迁移
2. 部署和启动从国外系统向国产系统的同步方案（使用支持回切的双主形式部署）
3. 验证同步正常，且两端数据一致后，择机进行切换
切换完成后，国产系统作为主系统，国外系统作为备用系统同步运行。如果国产系统能够稳定的运行 1 至 2
个业务周期，可以考虑拆到国外系统。
60 第 10 章 回切方案及系统重建
第 11 章
常见问题
本节列出 Kingbase FlySync 使用中的常见问题
61