两地三中心


难度 中等

大家晚上好,我是growdu,目前在kingbase主要负责数据库集群高可用的研发设计。今天由我来给大家讲解KES集群高可用——两地三中心方案。

本次内容主要从以下四个方面讲解:方案概述、方案实现、方案实例以及未来发展。
下面我们先来看下方案概述:

大家都知道对于数据库来说,数据至关重要,对数据进行备份,保证数据不丢,保障服务不停成为我们必须要处理的三个问题。
而kingbase的两地三中心方案就是围绕着这三点来展开实现的。

针对以上三点呢,国家出台了相关的国家标准,金融行业也制定了相关的金融标准。国家标准和金融标准其实就是两地三中心方案的雏形和基本背景。
尤其是在金融行业,商业银行监管要求更是对两地三中心方案进行了细化。

这里列出了从06年到现在的标准要求,主要包括这么几个方面:

  • 06年的时候提出了大型银行应同时采用同城和异地灾难和备份恢复,这个就是现在两地三中心方案的基本的轮廓。这里的两地就是同城和异地。
  • 07年的时候对两地三中心的灾难恢复进行了量化,使用RPO、RTO对灾难恢复进行分级,使两地三中心的架构可衡量
  • 08年进一步将信息系统按重要程度划分为A、B、C类系统,不同的系统对应不同的灾备方案,比如A类系统就必须有同城备份和异地备份,这其实就是说要用两地三中心
  • 10年的时候标准规定商业银行可以先设立生产中心,再设立灾备中心,这里其实就是说明了两地三中心架构的可扩展性
  • 11年明确了RTO和RPO的要求,重要业务RTO不得大于4小时,RPO不得低于半小时
  • 到了12年呢则是提出切换演练的要求,也就是说两地三中心应该要支持故障切换功能
  • 而到了2020年的时候,则是使用可用性将两地三中心进一步量化了,要求可用性要达到99.99%,其实就相当于是前面说到的数据不丢,服务不停。停也只能停一小会。

这个就是两地三中心方案的一个基本背景和基本要求,kingbase的两地三中心方案就是在这个背景和要求上做进一步的设计开发和完善。下面呢根据前面提到的概念进行详细的介绍。
首先我们先看下RPO和RTO,这个是衡量两地三中心方案的重要指标,也是用户层面能看到的最直观的东西,我们的方案靠不靠谱就看两个参数。
RPO呢被称作恢复点目标,是指业务系统所允许的在灾难过程中的最大数据丢失量,用来衡量容灾系统的数据冗余备份能力。RPO通俗来说就是我能丢多少数据。
RTO呢是指恢复时间目标,是指信息系统从灾难状态恢复到可运行状态所需的时间,用来衡量容灾系统的业务恢复能力。
其实RTO就是服务能停多久。

有了RTO和RPO后就可以根据RTO和RPO的时长来对灾难恢复能力进行等级划分,根据RTO和RPO的时长不同将灾难恢复能力分为6级,灾难恢复能力等级越高,可用性就越高,当然实现难度越大。
对于两地三中心来说,灾难恢复能力至少应达到5级,即RTO=数分钟到2天,RPO=0到30分钟,这个是两地三中心的基本目标,或者说是最低要求。

这里要求其实还是比较宽松的,比如RTO=数分钟到2天,意味着最长可以在2天内恢复数据库访问,这其实在实际系统里是不能接受的。
2天不服务客户,客户早就跑了。
而RPO=0到30分钟就更不能接受了,这意味着最多可以丢30分钟的数据,这要是负债数据丢了这么多,客户不得笑死。

所以呢,金融规范里增加了可用性的概念,同时对灾难恢复等级提出了更高的要求。
这里我们还是重点看5级灾难恢复能力,可以看到RTO应该小于30分钟,RPO呢应该尽量等于0,用可用性来说呢就是可用性应该达到99.99%。

用我们之前的话说,就是服务不能停,数据不能丢,要停的话不能超过30分钟。对于客户来说,几分钟内不可用,勉强还是可以接受的。
这个呢也是kingbase两地三中心方案的基本能力要求,当然kingbase两地三中心方案是奔着RPO=0,RTO=0去的,也就是服务不停,数据不丢。

到这里对两地三中心方案有了一个大致的认识,下面我们来看下两地三中心具体是什么样的。

先来看看两地三中心,顾名思义,两地是指不同的城市,比如北京和上海,三中心是指生产中心、同城灾备中心、异地灾备中心。生产中心主要负责对外提供服务,同城灾备中心一般采用同步的方式和生产中心同步备份数据,异地灾备中心内采用异步的方式备份数据。
这个就是两地三中心的基本形式。

根据两地三中心的基本形式可以扩展衍生出多个方案,两地三中心并不要求一步定位,一下子就部署好三个中心。
它可能是先部署生产中心,再部署灾备中心,最后才演变成两地三中心,它是可以扩展的。

下面我们来看一下每种架构的区别和特点,首先来看下同城双中心。
同城双中心由部署在同一个城市不同机房的两个双中心组成,中心间采用同步的方式同步数据。生产中心会选出一个主节点,然后中心内的其他节点,也就是备节点或者说备节点采用同步的方式与主库相连,同城灾备中心的其中一个备节点与生产中心的主节点采用同步的方式与主库连接。

另外,为了处理中心间故障切换,一般情况下我们会部署一个中心间仲裁节点observer,用于在一个中心故障或者中心间出现网络故障时

同城双中心说完之后呢再来看下异地双中心,异地双中心与同城双中心除了两个中心分布在不同城市的不同机房外,中心间的流复制关系也有所不同。


文章作者: growdu
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 growdu !
  目录
分类导航
随笔3 AI29 计算机基础13 算法1 博客搭建7 ChatGPT2 集群63 计算机通信1 数据库59 数据库深入93 数据库93 Docker11 DPDK26 编辑工具4 Elasticsearch4 FAQ1 Go Web1 hometown2 编程语言16 人生11 网络9 Linux38 OPC1 openGauss4 页面12 PostgreSQL54 程序员自我修养1 协议11 stock1 存储5 成长之路1 工具20 视频作品1 VPP18 Vue13 Web1 代码示例11 BenchmarkSQL1 PostgreSQL 源码修炼之路14
最热文章
1
PostgreSQL 逻辑复制全链路:以一个真实事务为例,从 `INSERT` 到 `apply` 的源码级旅程
数据库🔥 2162
2
PostgreSQL 逻辑复制 Stream 执行逻辑源码级拆解:从 reorderbuffer 触发到订阅端落盘回放
数据库🔥 1765
3
PostgreSQL 行锁机制源码级深度拆解:4 种锁模式 + xmax + MultiXact 的完整链路
数据库🔥 1656
4
PostgreSQL reorderbuffer.c 函数级源码全集:5615 行 / 95 个函数的逐函数解析
数据库深入🔥 1650
5
PostgreSQL 目录快照源码级深度拆解:系统表读取的 MVCC 真相与失效机制
数据库🔥 1604
6
13 逻辑复制深入
数据库深入🔥 1570
7
0 Postgresql存储、索引及系统优化、主备切换
PostgreSQL🔥 1495
8
PostgreSQL 读一行数据源码级深度拆解:MVCC 在每个环节的落点
数据库🔥 1464
9
PostgreSQL WAL 记录类型完全指南:21 个 RMGR × 80+ 种记录的源码级拆解
数据库🔥 1431
10
一文读懂openguass dcf网络模块
集群🔥 1420
11
PostgreSQL 元数据存储机制:从磁盘文件到内存缓存,`pg_class` 撑起的整个系统表体系
数据库🔥 1411
12
openGauss 并行解码设计原理深度拆解:reader + 多 worker + CSN 三层架构的源码级剖析
数据库深入🔥 1344
13
逻辑复制源码分析
数据库深入🔥 1327
14
PostgreSQL 逻辑复制:catalog 改动、可见性判定与 xmin/xmax 推进全景
数据库深入🔥 1317
15
自托管服务全家桶:从原文方案到可复制实操手册
人生🔥 1278
16
PostgreSQL CREATE_REPLICATION_SLOT 端到端源码分析:从 SQL 到 snapbuild 状态机的完整链路(每个函数每个参数)
数据库深入🔥 1277
17
PostgreSQL syscache 模块源码深度拆解:CatCache 数据结构、LRU 哈希表、cache invalidation 全链路
数据库深入🔥 1216
18
PostgreSQL 18 内核数据结构全景:RangeVar 与 20+ 个核心数据结构源码级拆解
数据库🔥 1158
19
PostgreSQL 逻辑复制里 `RUNNING_XACTS` 写入机制与快照 `xmin / xmax / xip` 的演化:源码级深度拆解
数据库🔥 1119
20
PostgreSQL 分区表:从一行 `PARTITION BY` 到路由热路径的全链路拆解
数据库🔥 1094