关于数据库:运维实践-OpenMLDB-跨机房容灾方案

背景
在单集群部署环境下,OpenMLDB 具备集群内节点级别的高可用能力。但若受到机房断电或者自然灾害等不可抗拒因素,则将造成的机房或大部分节点无奈失常运行的状况,从而引发该集群状态异样,导致在线服务中断。为此,OpenMLDB 提供了一个跨机房容灾计划来解决该问题。在该计划中,用户能够在多个异地机房,别离部署独立的 OpenMLDB 集群,并且将这多套 OpenMLDB 集群设置成为主从复制模式。在这种部署架构下,如果主集群无奈提供服务,用户能够进行主从切换,从而保障业务不中断。

架构

名词定义

  • 主集群:能反对读写的集群,并且能够给从集群同步数据。一个主集群能够有多个从集群。
  • 从集群:只提供读申请的集群,数据和主集群保持一致;能够在须要的时候切换为主集群;能够部署多个。
  • 分片 leader:主分片,接管读写数据。
  • 分片 follower:从分片,只承受分片 leader 同步过去的数据,目前不承受客户端的间接写申请。
  • offset:本文 offset 特指 OpenMLDB 的 binlog 所保留的数据偏移量,该值越大,阐明保留有更多的陈腐数据。

对于名词的进一步解释能够查看 OpenMLDB 的在线模块架构文档:https://openmldb.ai/docs/zh/m…

指标

  • 主集群反对写操作,主从集群都能够反对读操作
  • 一个主集群能够有多个从集群作为备份
  • 主集群出现意外不可用时可能手动切换,让其中一个从集群晋升为主集群
  • 可能主动解决主集群或者从集群外部节点下线不可用(包含 nameserver 和 tablet)的状况

技术计划

主从集群的整体技术架构如下图所示:

主从集群之间的同步信息,次要蕴含数据同步和元信息同步两局部。

初始状态

对于主从集群的初始状态,能够为以下状态之一:

  • 主集群和从集群的数据均为空
  • 主或从集群不为空,主从集群的表名以及 schema 统一,并且主集群 offset 大于等于从集群的 offset,否则会报错。

元信息同步

元信息同步产生在主从集群的 nameserver 之间。具体的过程如下:

  • 建设好主从关系之后,主集群的 nameserver 会向从集群同步主集群的表信息,从集群创立相应的表。留神,主从集群节点数不须要统一,然而每张表的分片数须要保持一致。
  • 主集群的 nameserver 每隔一段时间获取从集群的表拓扑信息

数据同步

主从集群之间的数据同步次要通过 binlog 进行,其总体的同步逻辑如下:

  • 单集群外部:leader → followers 同步数据
  • 主从集群之间:主集群 leader → 从集群 leader 同步数据
    下图可视化列举了该同步逻辑和数据流方向。

假如有一个从集群,表为三正本。其具体过程为:主集群分片的 leader 会创立两个 replicator 线程来负责集群外部数据同步,以及 1 个 replicator 线程来负责同步数据到从集群的 leader;从集群的 leader 会创立两个 replicator 线程,别离给从集群外部的 followers 同步数据。
replicator 的具体同步逻辑如下:

  • 读取 binlog 并把数据传给 follower
  • follower 收到数据,增加到本地 binlog,同时写到本地分片表中

默认状况下,replicator 会一直读取最新的 binlog,如果没有最新数据写入就会期待一小段时间(默认为 100ms),再尝试读取。在同步时效性要求比拟高的场景下,能够批改默认配置(参数 binlog_sync_wait_time,详见文档配置文件),缩小等待时间,然而可能会减少 CPU 的资源耗费。

集群外部主动故障转移

主集群 nameserver 离线

  • 主集群中主 namserver 离线之后,主集群中的备 nameserver 就会降级为主 nameserver,更新从集群中表的拓扑信息到新的主 nameserver
  • 主集群中备 nameserver 离线,不做任何操作

从集群 nameserver 离线

  • 从集群中主 nameserver 离线之后,从集群中的备 nameserver 就会降级为主 nameserver。主集群向从集群获取表拓扑信息时,返回谬误,主集群就会读取从集群的 ZooKeeper 信息,以获取最新的主 nameserver,而后更新表拓扑信息
  • 从集群中备 nameserver 离线之后不做任何操作

主集群 tablet 离线

  • 主集群内做故障转移,相应的分片选出新的 leader
  • 新的 leader 从新和从集群中分片所在的 tablet 建设数据同步关系

从集群 tablet 离线

  • 从集群做故障转移,相应的分片选出新的 leader
  • 主集群 nameserver 获取从集群表拓扑构造发现曾经有变动,删除对应变动分片的数据同步关系并从新建设

主从集群间手动故障转移

主集群不可用
通过运维命令,晋升从集群为主集群。同时,业务方的写流量和读流量须要切换到以后的新的主集群下,该流量的切换过程须要由业务方零碎来实现。

从集群不可用
业务方原有在从集群上的读流量(如果有),须要全副切换到主集群下。该流量的切换过程须要由业务方零碎来实现。

主从集群搭建实际

集群启动后默认为主集群。通过命令能够将一个集群增加为另一个集群的从集群,或者进行切换、移除。

启动 NS client

主从集群的治理在 NS client 下进行操作,能够应用如下命令启动 NS client。

$ ./bin/openmldb --zk_cluster=172.27.2.52:12200 --zk_root_path=/onebox --role=ns_client

其中 zk_cluster 是 ZooKeeper 地址,zk_root_path 是集群在 ZooKeeper 的根门路,role 是启动的角色需指定为 ns_client

对于 NS client 的更多信息,能够参考运维 CLI。

增加从集群

能够应用命令 addrepcluster 来增加一个从集群,其应用格局为:

addrepcluster $zk_cluster_follower $zk_root_path_follower $cluster_alias

比方须要增加的从集群的 ZooKeeper 地址为 10.1.1.1:2181,OpenMLDB 在该 ZooKeeper 上的根门路为 10.1.1.2:2181 /openmldb_cluster,增加当前的从集群别名为 prod_dc01,则能够在主集群的 NS client 上执行如下命令进行从集群的增加:

addrepcluster 10.1.1.1:2181,10.1.1.2:2181 /openmldb_cluster  prod_dc01

移除从集群

能够执行命令 removerepcluster 来删除一个从集群,比方删除下面增加的从集群 prod_dc01

removerepcluster prod_dc01

切换集群角色

switchmode 命令能够批改集群的角色。参数能够为 leader 或者 normal。如果须要把从集群晋升成主集群,参数设置为 leader。如果要批改为一般的集群,参数设置为 normal。

switchmode leader

查看从集群

showrepcluster 命令能够查问所有从集群,输入后果相似:

FAQ

Q1: 如何解决分布式的“脑裂”问题?
A1:在分布式环境中,常常会遇到“脑裂”问题。所谓脑裂,简略来说就是在某些非正常状态下(比方因为网络阻塞),两个集群选举出了不同的 leader。Raft 之类的一致性协定能很好的解决相似问题,如要求 leader 必须获取半数以上的投票。
OpenMLDB 的选主和这些协定不太一样,OpenMLDB 是由 ZooKeeper 和 nameserver 来选主的。节点是否下线通过 ZooKeeper 中 ephemeral node 实现,nameserver 选主的时候从该集群的所有 follower 中抉择 offset 最大的一个作为新的 leader,所以实质上来说 OpenMLDB 的主从集群计划不会呈现脑裂的问题。

Q2: 如何判断主集群不可用,须要进行主从切换?
A2: 目前 OpenMLDB 在集群整体不可用的状态上并不会主动判断或主动切换,设计主从集群计划次要是为了应答如机房断电等重大事故。
因而目前须要人为主观去判断主集群是否处于不可用状态,从而须要进行主从切换。造成主集群不可用的常见起因如:整个集群的服务器不可抗拒起因无法访问、ZooKeeper 无奈复原、局部 tablet 下线导致无奈复原或者复原工夫过长等。

Q3: 是否可能在某些状况下会数据失落?
A3: 尽管主从集群计划减少了多一层的高可用机制,然而也不能保证数据齐全不失落,以下状况仍然会呈现数据失落,相干问题均会在后续版本进行修复或者优化:

  • 主集群外部 tablets failover 后,新选出来的 leader 的 offset 比从集群中的 leader 的 offset 小,会造成两者 offset 差值之间的这部分数据失落
  • 主从切换过程中,如果主集群有写流量,那么可能会造成局部未及时从原有主集群同步到从集群的数据失落
  • 从集群表格拓扑发生变化,并且主集群尚未捕捉,此时如果执行主从切换,会造成从拓扑构造发生变化到切换胜利之间的数据失落

Q4: 是否能够反对多个从集群
A4: 一个主集群能够反对多个从集群,只有在主集群上执行增加从集群命令 addrepcluster 进行增加即可。

Q5: 和业界其余主从集群计划的比拟?
A5:

列举了两个业界罕用数据库作为比拟 —— TiDB 和 MySQL,OpenMLDB 的做法和这两个在架构上比拟类似。TiDB 将数据从 TiKV 传到 TiFlash 也是通过相似形式实现的,TiFlash 有一个 Learner 的概念相似于 OpenMLDB 从集群的 leader。TiKV 会把数据同步到 Learner 下面,而后再由 Learner 去做集群内的数据同步。MySQL 的主从复制,跟咱们做法也是相似的,它也是通过 binlog,将数据定期地同步到从集群下面,从集群再进行 binlog 的集群内读取和同步。

开发进度

目前主从集群计划在试验阶段,其外围性能都曾经开发结束,并且进行了充沛的测试。目前次要遗留问题为:

  • SQL 命令目前只有创立表、删除表、以及数据插入操作能够主从集群主动同步,其余命令(比方 SQL 上线,批改 TTL 等)目前尚不反对主动同步,须要手动在主从集群上别离执行。

【腾讯云】轻量 2核2G4M,首年65元

阿里云限时活动-云数据库 RDS MySQL  1核2G配置 1.88/月 速抢

本文由乐趣区整理发布,转载请注明出处,谢谢。

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据