共计 7177 个字符，预计需要花费 18 分钟才能阅读完成。
摘要： 本文次要是探讨 OLAP 关系型数据库框架的数据仓库平台如何设计双集群零碎，即加强零碎高可用的保障水准，而后讨论一下 GaussDB(DWS) 的容灾应该如何设计。
以后社会、企业运行当中，大数据分析、数据仓库平台已逐步成为生产、生存的重要位置，不再是一个从属的可有可无的剖析零碎，内部监控要求、企业外部服务，涌现少量要求 7 *24 小时在线的利用，逐渐呈现不同等级要求的双集群零碎。
数据仓库支流数据库平台均已存在多重高牢靠保障措施设计，如硬盘冗余的 raid 设计、数据表冗余、节点备用冗余、机柜备用数据穿插等，以及加上服务过程高可用冗余设计，其最大化水平满足数据仓库服务继续在线。
但事实场景，如数据库软件缺陷、定期加固补丁、产品迭代、硬件降级这些产品事实因素，以及来自机房、数据中心、地区、网络的内部劫难故障因素，均在升高数据仓库可用性服务水平。
鉴于数据仓库存在大量数据吞吐，针对不同数据库、不同可用性要求，若须要设计双集群冗余设计，可选技术手段别离有数据同步模式、双 ETL 模式、双活模式，具体探讨如下：
1. 数据同步模式
a) 架构
因为数据库 IO 能力无限、且两个数据库间带宽无限，除了首次全量同步之后，后续通常思考增量同步技术，即如何精确、高效获取“变动数据”，个别存在日志同步技术、备份增量同步技术、逻辑数据同步；
b) 日志同步技术
日志同步技术，有业内最驰名 Oracle Golden Gate，大部分厂家也有本人的实现形式，像 Teradata 近年来推出 Unity CDM（变动数据播送）技术，而我司 GaussDB for DWS 可采纳 xlog 及 page 进行变动数据同步。
劣势：间接同步变动数据增量，数据量少，要求带宽低，但目前市面技术大都只适宜数据每日变动量较少的数据仓库环境；
劣势：事实的技术门槛高，应答各类异样场景适应能力差，对主数据库侵入性能要求高，一旦主库忙碌，同步时效低；面对全删全插等变动数据量大场景，同步吃力；
c) 备份增量同步技术
次要利用各数据库平台备份恢复能力，进行数据增、全量备份、复原；通常源库备份数据压缩之后，经网络传输后，解压复原到指标库；对应 GaussDB for DWS 可采纳 roach 备份复原工具实现；
劣势： 利用同一技术实现增、全量数据同步，逻辑清晰，各场景容错能力强；
劣势： 要求数据库反对增备能力，且往往锁期待重大；
d) 逻辑数据同步
该项次要波及较高的业务侵入性，即充沛获取 ETL 调度数据流元数据，对应数据库当日数据稳固之后，发动数据表导出 - 导入操作，针对数据表加工个性，抉择增全量同步规定，进行数据准实时同步。
劣势： 较上述同步技术，能够实现多样选择性同步，同步过程由施行我的项目自身管制，做到表级数据同步，不须要全零碎同步，即可实现局部业务双集群；
劣势： 客户化同步逻辑，操作前置依赖多，施行投入人力多，较难推广；
2. 双 ETL 模式
a) 架构
即采纳两套独立调度平台进行数据加工，抽取同一个数据源（往往是落地稳固的数据交换平台），采纳同一套 ETL 代码依赖逻辑调度，各自生成指标数据，往往批量过程中，采取主库对外继续服务，待主备库数据准实时或批后校验统一后，再凋谢备库对外服务。
若双集群数据产生不统一场景，次要以主库数据为准，笼罩备库。该同步过程，须要应用到“数据同步模式”相干同步技术。
b) 参照落地架构
c) 加载源数据思考
为保障两套 ETL 调度加载数据源统一及数据复用，往往要求搭建一个数据交换平台。因为至多存在一个文件被两套调度读取，要求数据交换平台两倍过往吞吐能力；且禁止加载的数据文件被二次笼罩，导致两套零碎加载不统一；
d) 调度依赖程序思考
因为 ETL 作业调度关系没有配置齐备，即存在 A 作业应用 B 作业的数据，但不配置依赖关系（绝大部分的状况是 A 作业可容忍 B 数据的时效，是否最新数据均能够应用，故为时效，业务上不配置依赖关系；当然也存在物理工夫上，通常 B 远远早于 A 执行），导致两套零碎 A 作业生成数据不统一。
该场景下，在一套调度平台无奈发现此问题，但存在两套零碎的校验比对，即发现数据不统一；
该问题倡议用户补全依赖关系，确认执行程序一致性；
当然若心愿灵便应用依赖关系，则需二次开发，管制两套调度当日时序一致性；
e) ETL 代码服务器思考
为了防止两套 ETL 调度代码保护不统一，需思考对立保护渠道，蕴含不限于同一个代码存储源、版本服务器，以及代码变更机会
f) 存在不确定值的 SQL 函数返回
ETL 代码中往往存在 sample、random、row_number 排序这种同一份数据产生不同后果集的函数，造成两套零碎数据不统一；
该问题倡议用户应用代替函数、明确取值、惟一排序，确保最终数据一致性；
同时，该设计逻辑正确状况下，哪份数据均可被业务采信，若该数据对上游影响少，可每日批后从主库同步备库，拉平数据；
g) 报错修数逻辑思考
其中一套零碎的数据产生报错、修数行为，会波及到另一套零碎的保护行为；
可选作法是保留操作逻辑，待另一套零碎产生报错时反复执行一次；
其它交给数据品质校验（DQC）、数据校验去复查；
h) 干涉重跑修数逻辑思考
若批后重跑，两套零碎重跑逻辑统一，波及重复劳动（或撑持平台优化），绝对简略；
但波及批量过程中发现局部数据须要重跑，因为两套调度进度不统一，会导致
i) 数据校验
i. 校验机会
批后校验，逻辑清晰，对调度依赖少，即依据整体调度进度，做到分层、分库或整体数据校验；
准实时校验，即侵入调度环节，在每个作业实现时，均发动日志解析，提取每个 SQL 影响记录数，若相应作业 SQL 存在影响记录数不统一场景，即停止较晚实现的调度平台调度后续作业；
ii. 校验伎俩
增全量校验，即针对不同加工逻辑的数据表，辨别增、全量数据值，以最小代价笼罩所有业务表
iii. 校验办法
通常作法有记录数、汇总值、checksum 校验；
汇总值校验，通过是数值型字段间接 sum、字符型计算字符长度的 sum、工夫类型则转换成数值相加的比对；
Checksum 校验，针对全表或局部字段，进行 md5 或 hash 运算，实现两套零碎一致性比对；
对于关系型数据库，校验开销代价逐渐递增（记录数 < 汇总值 < checksum 校验）；往往是联合增量校验、联合重要指标，辨别维度校验，日常增量逻辑校验，定期全量校验，在校验数据一致性和零碎性能之间获得平衡点。
j) 优化考量
i. 校验改良
即嵌入调度平台，提取 ETL 代码运行日志，通过执行 SQL 影响的记录值，实时进行两套零碎实现作业日志比对，发现记录值影响，立刻进行备库调度，采纳人工或主动形式修复数据，持续后续批量。
该作法最大益处是，即时发现数据异样，防止问题放大，保障备库更高可用性；
ii. 引入对立保护平台
即缩小人为双系统维护操作，代码变更平台化，修数逻辑平台化，由平台别离下发两套调度平台、两套数据库。
3. 双活模式
以下基于 Teradata Unity 产品理念的延长构想
a) 架构
b) 双活性能点
i. 拜访路由能力
客户端间接将中间件作为数据库登陆，放弃原来登陆逻辑不变；
中间件依据登陆用户及附加参数实现回绝登陆、双系统登陆、或单零碎登陆，实现写登陆、读登陆，实现受控形式登陆、或非受控形式登陆；即实现受控和非受控形式的零碎读写；
同时兼顾思考异样路由抉择或同步路由抉择，满足最大化异样执行及少部分同步需要场景；
ii. SQL 散发能力
经中间件发送的 SQL 指令，失常发送到相应数据库，并承受数据库响应信息；
iii. 批量导入、导出能力
针对数据大批量的导入，须要思考采纳更加高效的加载协定进行数据加载，并思考经中间件复制数据块，异步散发两个数据库；
数据导出，须要思考高效数据导出协定，从其中一套数据库正确导出数据；
iv. 更新类 SQL 校验能力
Delete、Update、Insert、Merge 等更新类 DML SQL 进行 SQL 影响记录数校验；
DDL/DCL 执行返回码验证一致性能力；
v. 对象注册性能
通过路由及创建对象的 DDL 语句，实现对象动静注册；
通过命令行指令实现对象注册；
适当减少对象索引、束缚索引的注册信息，用于扩大细粒度对象锁能力，进步数据仓库 ETL SQL 并发能力；
* 数据仓库环境下，只须要思考到表级双活的能力，不倡议施行字段级、记录级双活；
vi. 对象锁能力
依据 SQL 指令给相应对象动静加锁、开释锁；
同时依据数据库自带的锁特色，至多辨别读、写锁管制，以及局部数据库的脏读性能锁；
vii. 对象状态控制能力
进行治理的多套数据库在线状态管制；
进行对象状态管制性能，蕴含不限于在线、离线、只读、只写、被动中断缓存中、被动中断缓存中、不可用等状态；
viii. 缓存能力
进行 SQL 指令流缓存能力，以及缓存复原执行的能力；
进行 SQL 与加载数据联合缓存、以及缓存复原执行的能力；
ix. SQL 异样控制能力
思考用户体验，始终由返回响应正确的 SQL 指令返回客户端；
两个数据库返回均胜利，但返回的影响记录数不统一，则响应慢的数据库对应 SQL 及波及对象被设置成不可用状态；
若两套数据库其中一套执行胜利，另一套执行失败，则执行失败的数据库 SQL 和波及对象被设置为被动中断缓存中，同时缓存 SQL，定时重试 SQL；
若两套数据库返回均报错，才告诉客户端报错；
若 SQL 波及对象已解决非在线状态，则新提交的 SQL 被缓存，新提交 SQL 相应对象被设置为被动中断缓存中。
针对中间件和数据库之间，存在数据库已执行完、但中间件未收到信号场景，需思考闪环该场景（如减少事务锁等）；
c) Teradata Unity 参照落地架构
ü 次要通过 Unity 实现多集群 SQL、数据散发与治理；
ü Data Mover 实现集群间数据同步；
ü Eocsystem Manager 实现数据批后主动校验及不统一重同步事件触发；
ü Viewpoint 实现零碎平台透视图展示与保护，并对接用户告警平台；
d) 中间件高可用思考
因为引入了中间件（前置）服务，即该服务的稳固、牢靠对双活模式至关重要。
数据库单套零碎自身曾经具备极高的可用性，引入中间件后，因为所有数据库拜访行为均通过该中间件，中间件任何异样均同时影响两套数据库拜访能力。
除了中间件自身所有相干服务须要满足高可用之外，还需思考极其场景下 bypass 能力，此项能力在于极其异样条件下，能够保障系统继续服务的能力。
高可用场景中，存在管制节点脑裂与主动升主场景，需借鉴仲裁机制缩小脑残裂产生；
e) 数据重同步思考
即利用“数据同步模式”相干同步技术，实现两套数据库数据重同步能力；
f) 不确定值的 SQL 函数思考
最佳计划，是采纳“数据同步模式”的数据日志重同步技术，间接将第一套数据库 SQL 执行后果的日志信息同步到第二套数据库中，打消返回后果不统一；
局部简略的零碎工夫函数，间接通过中间件改写，保障 SQL 执行后果一致性；
另外，则通过 SQL 改写，保障 row_number 函数进行主键或全字段排序，保障 SQL 执行后果一致性；
g) 异样会话重放能力
针对异样会话过程的 SQL，可能须要从会话建设后，可视化抉择，倒回前几个 SQL 从新执行，并指定过程 SQL 是否参加后果集校验，以及 SQL 回放完结的确认动作，让异样场景解决伎俩更加丰盛。
4. 实用场景
a)“数据同步模式”– 日志同步技术
实用数据变动量小、数据传输压力小的数据场景，通常只实用于小型数据仓库平台；
对于规模小的平台，RPO、RTO 能够靠近 0；
b)“数据同步模式”– 备份增量同步技术
适宜大数据量同步场景，实现形式容易被用户了解；
往往须要数据库备份工具具备增量备份恢复能力；同时考验备份工具打消相干硬件限度条件，让该技术计划更加灵便；
双集群的初始化同步往往采纳全备全恢的逻辑实现，能够最大化、最快拉平存量数据；
对于规模大的平台，RPO 往往须要小时级别，RTO 最好水准也在分钟、10 分钟以上；同时主集群须要保障肯定资源量供数据同步应用，对主集群开销大；
c)“数据同步模式”– 逻辑数据同步技术
实用灵便同步场景，往往数据同步量不会太大，或同步工夫可容忍场景；
此场景往往适宜于用户对其数据仓库 ETL 过程元数据信息清晰、残缺，依赖客户开发能力，相干同步数据存在清晰 ETL 算法，联合调度作业运行进度，动静发动相干数据表增、全量同步；
对于中等规模的平台，RPO 能够做到分钟、半小时，RTO 能够维持在分钟级；
d)“双 ETL 模式”
须要两套 ETL 调度环境，整体老本翻倍，但调度逻辑清晰、易于了解和保护；
较容易匹配不同规模的数据仓库平台驳回；
较难实现数据实时比对，以及数据产生不统一之后的管制逻辑（若须要实现，对于调度逻辑侵入性大）；
ETL 调度批量中途，较难实现两套调度链路协调重跑；
同时数据不统一，依赖于”数据同步模式”技术辅助施行；
因为主备调度进行不统一，无奈做到主备对立视图展示；
若双集群硬件相当，RPO、RTO 均能够维持在分钟级别；
e)“双活模式”
须要独立中间件、且重大依赖数据库本身厂商，中间件实现难度大；
中间件的高可用（稳定性）成为它落地的最大阻碍；
“双 ETL 模式”的升级版，能适应各类数据仓库双集群场景；
绝大部分场景下，RPO、RTO 均能够靠近 0，特地是双活同时在线能力，不存在双集群的主备切换，RTO 能够做到 0；同时存在对立视图，不会因为其中一个集群故障，造成前后同一个查问返回后果不统一场景；
5. 总结比对
接下来，咱们展开讨论一下 GaussDB(DWS) 的容灾应该如何设计。
对于计划探讨中波及到几种状态，从数仓内核的角度去剖析一下各个计划的问题：
- 日志同步技术：
- 列存数据不记日志无奈通过日志来同步
- 反对列存 xlog 后会导致导入性能劣化，xlog 数据量大，同时会影响日志同步效率
- 备份增量同步技术：
- 无奈达到 RPO = 0
- 备集群只能读，无奈反对写操作
- 逻辑数据同步技术：
- 列存数据须要反对逻辑解码，须要从列存 XLog 的方向进行演进
- 分布式事务，DDL 等解决难度较大
- 备份 / 复原
- 不能马上提供服务，RTO 工夫较长
- 须要较大空间保留备份集
GaussDB(DWS) 以后在备份增量同步和备份 / 复原两个方向进行演进，他们都是基于备份 / 复原工具 Roach
(详情参见 Roach 备份复原 GaussDB(DWS))
- 备份 / 复原
备份 / 复原的原理图如下，在各个结点将实例备份到相应的介质上，并从介质上复原到新集群或老集群中。具体的性能不在此处开展形容，大家能够参考 (详情参见 Roach 备份复原 GaussDB(DWS)) 来理解细节。
对于实现容灾要求，须要解决的问题大体分三类：
- 疾速的备份复原
高性能备份、复原操作保障在较短的工夫内将数据迁徙到另一个集群，对于 RPO/RTO 要求不大的零碎来说实现和应用非常简单。
- 备份复原在集群可用的状况下即可进行，不受单点故障的影响
备份复原在集群可用的状况下就能够进行，集群只须要保障有可用正本就能够继续的进行备份，并且能够失常复原。
- 备份集的可靠性
备份集须要存储在牢靠的存储上，相似 OBS/NBU, 因为磁盘故障率绝对比拟高，相似备份集保留在磁盘上是非牢靠的计划。
- 双集群备份增量同步技术
以后 GaussDB(DWS) 应用在备份 / 复原的双集群架构来实现容灾，将生产集群的数据应用增量的形式同步到容灾的集群。
在这种架构下须要解决如下问题：
1. 缩小 RPO
备份复原无奈达到与流式的同步形式的 RPO，做不到 RPO= 0 的水平。
2. 备集群的可用性问题
- 备集群反对继续读 / 写
备集群是物理复原的形式，无奈反对写的操作的；然而在复原过程中是能够反对继续读的，以后在复原过程中须要停集群后将备份集中文件笼罩。
- 备集群集群复原失败可回退到一致性状态
在复原过程中会出结点故障，备份集损坏等等问题，会造成以后的复原过程无奈执行过来，此时须要回退到复原前的状态，保障备集群的可用性。
- 备集群复原不受单点故障影响
对于备集群来说，也会呈现各种单点故障的状况，实例故障，结点故障，CN 剔除等状况下，依然能够把集群复原成可用的状态。
- 备集群反对备份
备集群能够反对备份，用于扩大一些其它性能，实现相似多 AZ，异地的容灾。
3. 备份集治理
- 备份集生命周期治理
容灾是实现数据同步的性能，并非一个备份复原场景，并不需要保留大量备份集以及周期的去做全量备份，因而须要有一个机制实现备份集及时清理，保障占用资源可按。
- 备份集的可靠性
在容灾过程中，同样思考备份集的可靠性，避免备份集损坏状况，能够通过牢靠的介质来保留备份集，又能保障牢靠的读写性能。
- 继续增量数据同步
放弃继续的增量备份，相似降级前后，扩容前后，都要放弃增量备份来保障同步的性能。这里隐含着一个不言而喻的起因，如果全量备份的话，备份工夫长，并且复原进会将集群清空，此时容灾集群不可用，这个重大影响可用性。能够说防止全量备份是基于 Roach 的双集群容灾一个重要工作。
4. 双集群切换及 Failover
- 疾速切换
双集群的利用场景中，相似滚动降级，故障演练，此时须要切换两个集群，切换时要保障疾速将两边数据拉平，尽快提供服务并保障可用性。
- Failover 及之后的加回操作
因为 RPO != 0，所以在生产集群无奈提供服务时, 容灾集群在 Failover 操作后会提供读写服务，此时会有一部分数据失落，并在两个集群的数据产生了“分叉”，那么在生产集群复原后，加回之后中要将“分叉”的数据进行回退，以保障两边数据统一。
5. 异构的反对
此处异构是指逻辑构造 DN 数量统一，而 CN 数、结点数能够不雷同的状况，家喻户晓是因为以后计划是物理备份形式，因而如果 DN 数量发生变化，无奈从物理层进行重散布操作。
以上阐明的几点都是基于可靠性的角度来剖析，还有一个重要的因素是基于数仓的数据量和集群规模，不管备份 / 复原计划还是在此基础上的双集群备份增量同步的计划，对于网络带宽，介质的读写性能有较高的要求，因而须要依据集群规模和数据增量来抉择适合的组网形式和介质。
本文分享自华为云社区《GaussDB(DWS) 的容灾应该如何设计》，原文作者：Puyol。
点击关注，第一工夫理解华为云陈腐技术~
