GaussDB数据库高可用性--两地三中心跨Region容灾

两地三中心跨Region容灾

可获得性

基于流式复制的异地容灾解决方案，从V500R002C00版本开始提供该解决方案。

特性简介

支持两地三中心跨Region容灾。

客户价值

金融、银行等业务需要底层数据库提供跨地域的容灾能力，来保证极端灾难情况下数据的安全和可用性。

特性描述

金融、银行业对数据的安全有着较高的要求，当发生火灾，地震，战争等极端灾难情况下，需要保证数据的安全性，因此需要采取跨地域的容灾的方案。跨地域容灾通常是指主备数据中心距离在200KM以上的情况，主机房在发生以上极端灾难的情况下，备机房的数据还具备能继续提供服务的能力。本特性的目的是提供一套支持gaussdb跨地域容灾的解决方案。

该特性当前提供如下解决方案：

1. 基于流式复制的异地容灾解决方案（从V500R002C00版本开始提供该解决方案）。

特性增强

V500R002C00版本开始针对两地三中心跨Region容灾特性新增基于流式复制的异地容灾解决方案：

• 支持容灾搭建。
• 支持灾备集群failover，以及灾备集群failover后主集群容灾解除。
• 支持容灾主备集群计划内switchover。
• 支持容灾状态查询。
• 支持容灾状态下主集群，灾备集群节点修复与节点替换。

503.0.0版本新增功能：

• 支持容灾主集群日志保持
• 支持容灾加回
• 支持容灾演练增强
• 支持结束容灾搭建等待状态的清理功能
• 支持灾备集群升主集群后手动升副本，恢复为灾备集群后手动降副本
• 支持容灾过程中修改容灾用户信息

505.2.0版本新增功能：

• 支持1个主集群连接2个备集群的基于流式复制的异地容灾场景。

 

特性约束

基于流式复制的异地容灾解决方案：

• 灾备集群可读不可写。灾备集群读不支持GTM FREE模式。
• GTM FREE模式下如果所有GTM都损坏，容灾功能将不可用。
• 不支持不同GTM模式的集群搭建容灾，GTM FREE模式不支持容灾搭建。
• 主集群和备集群应该具有相同的管理员用户名rdsAdminUser。
• 主集群和备集群应该具有相同的集群用户名。
• 灾备集群通过failover命令升主后，和原主集群灾备关系将失效，需要重新搭建容灾关系。
• 数据库实例状态对容灾操作的影响：
  • 在主集群和灾备集群处于normal状态且所有组件（CN、DN、ETCD、GTM、CM_Agent、CM_Server）状态正常时可进行容灾搭建；在主集群处于normal态所有组件状态正常并且灾备集群已经升主的情况下，主集群可执行容灾解除，其他集群状态不支持。
  • 在主集群和灾备集群处于normal状态且所有组件（CN、DN、ETCD、GTM、CM_Agent、CM_Server）状态正常时，通过计划内switchover命令，主集群可切换为灾备集群，灾备集群可切换为主集群。
  • 主集群和灾备集群部分组件（CN、DN、ETCD、GTM、CM_Agent、CM_Server）状态异常且仍满足少数派故障时，使用快速倒换模式，主集群可切换为灾备集群，灾备集群可切换为主集群。
  • 如果在主集群切换为灾备集群前，CM_SERVER主配置文件损坏，那么主集群切换为灾备集群后，原主集群CM无法感知已经切换为灾备集群。
  • 灾备集群处于非Normal且非Degraded状态时，无法升主，无法作为灾备集群继续提供容灾服务，需要修复或重建灾备集群。
  • 主集群分片存在多数派实例故障且没有打开最大可用模式时（参数most_available_sync），不会向灾备集群进行日志发送，需要及时修复主集群故障实例。
• 当灾备集群为2副本时，需要确保打开最大可用模式（参数most_available_sync）。灾备集群在1个副本损坏时，仍可以升主对外提供服务，如果剩余的这个副本也损坏，将导致不可避免的数据丢失。
• 灾备集群支持单机1副本部署（1CN、多DN（单副本）、1ETCD、1CMS、1CMA、1GTM ，单个DN资源不少于8核CPU），单机1副本集群当前版本仅支持安装、升级、参数设置、集群启停、集群状态查询、备份恢复，不支持扩容、节点修复、节点替换、修改端口、升降副本、灾备集群读等SLA功能，不支持单副本当做主集群搭建容灾。
• 主集群如果进行了强切操作（cm_ctl finishredo命令，参见《工具参考》系统内部使用的工具中的“统一集群管理工具”章节），需要重建灾备集群。
• 主集群如果进行了少数派AZ强启，会出现数据丢失，需要重建灾备集群。
• 容灾关系搭建之后，灾备集群不支持全备和增备，主集群支持全备和增备。如果主集群要做恢复，需要先解除容灾关系，在完成备份恢复后重新搭建容灾关系。
• 容灾关系搭建之后，灾备集群不支持逻辑复制，主集群支持逻辑复制。
• 灾备集群支持节点替换和节点修复，继承节点替换和修复的约束。
• 建立容灾关系的主集群与灾备集群之间不支持GUC参数的同步。
• 容灾关系搭建之后，不支持CN/DN实例用于流式复制的端口修改。
• 容灾关系搭建之后，主备集群不支持扩容。主备集群需解除容灾关系后，各自完成扩容，并重新搭建容灾关系。
• 容灾状态中灾备集群支持降副本，灾备集群升主并且删除容灾信息后正常支持升降副本，灾备集群升主且未删除容灾信息后正常支持升副本。
• 支持主集群与灾备集群CN个数不对等情况下搭建容灾，但主集群的CN配置数与灾备集群的CN配置比最大为8:1。
• 容灾搭建时需要在主集群和灾备集群下发容灾用户名和密码用于集群间鉴权：
  • 主备集群必须使用相同的容灾用户名和密码。
  • 不得使用已存在的数据库用户进行搭建。
• 搭建容灾的主备集群版本号必须相同。
• 容灾加回需要主集群和灾备集群处于normal状态且所有组件（CN、DN、ETCD、GTM、cm_agent、cm_server）状态正常。主集群如果有组件异常，可能会导致灾备集群加回失败。
• 容灾状态下主备集群升级：
  • 主备集群都要处于normal状态。
  • 主备集群升级时大版本升级会校验主备集群版本号是否相同，不相同不可升级。小版本升级不校验。
  • 不支持就地升级。
  • 当主集群升级忽略故障CN所在节点时，灾备集群进行升级时需忽略对应CN所在的节点。
• 容灾机制类约束：
  • 容灾集群不支持COPY TO操作，由于容灾集群的CN是备机，不能分配XID，COPY TO在CN上需要申请XID，故无法执行。执行时报错（ERROR: cannot assign TransactionIds during recovery）。
  • 容灾集群上pgxc_node表的内容是同步自主集群的，所以容灾集群的CN会根据pgxc_node表中的node_oid与真实的节点信息做一层映射，但主备集群的node_name不是完全对应的，这会导致通过EXECUTEDIRECT ON语法实现的视图在容灾集群上的查询结果出现异常（结果重复或缺失），建议直接在对应的节点上查询。
  • 主备集群异构、CN数量不一致时，进行灾备集群读之前，应先查询出与主集群存在映射关系的灾备集群CN，再根据查询出的CN进行相关业务操作（查询方式：select * from pgxc_disaster_read_status()）。如果连接到和主集群不存在映射关系的CN，由于此CN自身的一致性点不参与全局一致性点的计算，可能会出现连接报错（ERROR: cn data invisible: local csn 123456789, gtm snapshotcsn 123456999）。
  • 如果主集群与容灾集群之间出现断连，那么从容灾集群上查询到的数据可能是旧数据。
  • 如果使用JDBC连接容灾集群，且开启了负载均衡功能，那么查询请求会发送到主集群上，导致查询性能受到影响。
  • GTM-LITE方案，在CN与DN连接时，需要根据当前全局一致性点，计算出对应分片中，可用的DN副本，以下场景可能出现报错：Current slice cannot select a normal standby for standby read, slice: 1
    • 同一副本中，如果出现两个DN回放快慢不一致，且更快的DN出现重启时。处理方法：此时全局一致性点不会再推进，等待回放慢的分片跟上全局一致性点，报错消失
    • 容灾映射刚完成构建，但还未收集到各个CN、DN的回放、回收信息时。处理方法：仅启动时间窗会短暂出现，等待几秒钟后不再出现。
    • 极致RTO模式下，如果出现不同分片回放差异很大，部分回放快的分片回收点超过全局一致性点时。报错后处理方法：等待业务高峰通过，各分片回放差异减小后，报错消失，如果仅有个别CN回放很慢，可以通过cm_ctl stop命令，手工停止CN规避此问题。
  • 容灾搭建完成后，因容灾读本集群拓扑节点信息，依赖pgxc_node表回放后内部映射机制的构建。在容灾映射构建完成前，读请求会出现报错：Not support disaster read before init. 容灾集群关系搭建完成，灾备集群正常启动后，10s左右（主集群、灾备集群之间无RTO差距）此读报错消失。
  • 容灾集群由于pgxc_node表，是通过回放记录主集群的拓扑信息，如果出现，1）双集群集群间倒换，2）1：N主备集群部署场景下，主备集群倒换，3）主集群节点替换、CN剔除等，主集群拓扑结构变更导致灾备pgxc_node表被动更新时，由于分布式查询CN中使用的部分系统缓存，通过pgxc_node表中的记录oid作为key，当线程读到新的pgxc_node表信息，但系统缓存还未来得及更新时，此时间窗（3s左右）内会出现以下已知报错：
    • node id %d is in pgxc_group but not in the handles, maybe rebuilding DisasterCache. 根因：缓存中pgxc_group与缓存中通信dn矩阵中记录的OID不匹配。
    • cache lookup failed for node %u. 根因：pgxc_node表中的oid，与缓存中记录的节点信息oid不匹配。
    • Cannot reload pool when in a transaction block. 根因：会话在事务中，检测发现pgxc_node更新，但此处事务不支持reload pool，此处会报错，但不会持续报错。
    • pooler: shmemNums does not match with usessNums, pgxc_node reload failed. 根因：通信缓存agent中记录的备机节点个数是旧的，但会话内存变量记录的备机节点个数，已经随pgxc_node表的更新而刷新了。
• 回放查询冲突类约束：
  • 主集群频繁vacuum、频繁DDL会影响日志回放速度，回放机制本身可能出现查询与回放冲突，回放日志时，如果持有冲突的会话，已经执行超过max_standby_streaming_delay的时间，会主动结束查询，返回错误：ERROR: canceling statement due to conflict with recovery / ERROR: terminating connection due to conflict with recovery。
• 快照类约束：串并行回放容灾读：
  • 主集群做DDL操作，备集群回放DDL日志的时候，DDL在备集群上的某些节点中可能还没回放成功，校验快照失败，报错并结束查询（ERROR:current snapshot is invalid for this partition/relation）。
  • 主集群频繁vacuum会导致灾备集群查询的数据被提前清理掉等问题，读会话会检查快照是否大于DN最新的回放查询冲突点，不满足则说明此快照已经太旧了，不能读最新数据，主动报错并结束查询（ERROR: gtm csn small: gtm csn 123456789, lastReplayedConflictCSN 123456999 ）。
  极致RTO容灾读：
  • 由于磁盘空间不足、修改GUC参数触发了强制回收，或发生过启停，或某一分片回放慢导致全局一致性点长时间推进缓慢，均会导致正常回放的CN/DN，由于本地历史版本不支持当前一致性点而不可读，报错结束查询（ERROR：snapshot csn is not in csn-lsn list）。
• 性能约束
  • 当主备集群查询所能占用到的资源相同时，对于并行回放下的Astore表：
    • 在主集群无写业务、备集群的日志都回放完成的场景下，对于select count(*) from xxx语句的负载，从时延的维度上观察，备集群的查询性能达到主集群的80%。
    • 在带有写业务的场景下：主集群和容灾集群的查询性能可能都会受业务影响而有波动，单次查询不保证容灾集群的性能达到主集群的80%；在无DDL的场景下，对于sysbench和TPCC的负载，从TPS、第95百分位数和平均时延的维度上观察，容灾集群的性能达到主集群的80%。
    • 如果有多个查询的主节点或备节点部署在同一个机器上，因这个机器的资源不足导致查询性能下降的情况下，则上面两个场景不成立。
    • 当发现前两个场景不成立时，建议检查容灾集群中各节点是否存在资源（CPU、内存、磁盘）受限的情况。
    • 由于容灾集群在并行回放下的Astore表不支持index only scan查询，因而对于select count(*) from xxx语句的负载可能需要读取更多的数据页面，建议通过调整shared_buffers参数进行缓存优化。

依赖关系

无。

更多详情请参考GaussDB 文档中心：https://doc.hcs.huawei.com/db/zh-cn/gaussdbqlh/24.1.30/productdesc/qlh_03_0001.html