数据库系列之GoldenDB高可用技术

2022-05-09 00:00:00 线程 节点 切换 同步 水位

分布式核心数据库的高可用是保证业务连续性的基础，本文主要介绍GoldenDB的快同步技术以及各个组件节点的高可用技术实现，加深对GoldenDB分布式数据库高可用实现的理解。

1、GoldenDB高可用

1.1 GoldenDB同步技术
1.1.1 MySQL半同步复制
MySQL主从复制是一个异步的复制过程，主库发送更新事件到从库，从库读取更新记录，并执行更新记录，使得从库的内容与主库保持一致。主从复制的基本过程如下图所示：

  • 主从复制的完成通过以下三个进程实现的
  1. 主库 binary log dump 线程：当从库连接主库时，主库会创建一个log dump 线程，用于发送bin-log的内容。在读取bin-log中的操作时，此线程会对主库上的bin-log加锁，当读取完成，甚至在发动给从库之前，锁会被释放。

  2. 从库I/O线程：当从库执行start slave命令之后，从库会创建一个I/O线程用来连接主库，请求主库中更新的bin-log。I/O线程接收到主库binlog dump 进程发来的更新之后，保存在本地relay-log中。

  3. 从库SQL线程：SQL线程负责读取relay log中的内容解析成具体的操作并执行，终保证主从数据的一致性。

MySQL异步复制的过程并不会验证从库接收binlog是否完成，因此在故障场景下可能会出现从库没有接收到主库发送过来的binlog日志，导致主库从库数据不一致，甚至会出现数据丢失的可能。为了解决以上问题，MySQL引入了半同步复制技术，半同步复制中主库要等待至少一个从库节点将binlog文件flush到relay log中的返回即认为数据同步正常。

半同步复制技术有以下特性：

  • 半同步复制必须在主库和从库两端同时开启，如果在主库上没打开，或者从库上没有开启，主库都会使用异步方式复制

  • 从库在连接到主库时会询问主库是不是配置了半同步

  • 如果半同步复制主库从库节点都开启了，那么此时主库的事务线程在提交时会被阻塞并等待，会出现两种情况：至少一个从库节点ack通知主库已经收到了所有这个事务的Binlog日志；或者一直等待直到超过配置的超时参数rpl_semi_sync_master_timeout，这种情况下半同步复制将自动关闭，转换为异步复制

  • 从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会ack通知对应主库上面的等待线程。

  • 如果在等待过程中，等待时间已经超过了设置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制。

在MySQL中安装半同步模块并设置参数rpl_semi_sync_master_enabled开启半同步复制：

mysql> set global rpl_semi_sync_master_enabled = 1;mysql> set global rpl_semi_sync_master_timeout = 2000;
1.1.2 GoldenDB中的快同步
MySQL半同步复制过程中binary log dump 线程和从库replay log SQL线程都是单线程工作，这在一定程度生会影响复制的性能。GoldenDB中依然采用的是mysql半同步复制技术，不过利用多线程和并行复制技术对binlog数据同步进行了优化，在高并发、高网络时延下性能可以提升20%。

1）并行复制

原生MySQL中binlog dump thread和SQL thread是单线程的，在GoldenDB中使用多线程对此进行了优化。

2）线程池

  • 减少线程重复创建和销毁开销，提高性能

线程池预先创建一定数量的线程，在监听到新的连接请求时，线程池直接从现有线程中分配线程提供服务。服务结束后该线程不会直接销毁，而是去处理其它请求，避免了线程和内存对象的频繁创建和销毁，减少了上下文切换，提高了资源利用率。

  • 系统保护，防止DB雪崩

线程池技术同时也限制了并发线程数，即限制了MySQL运行的线程数。当连接或请求超过设置的大线程数时候，新的请求需要排队，防止DB出现雪崩，保护底层DB。

3）机房间的数据同步方式

  • 本地机房和同城机房数据采用快同步复制

  • 本地机房和同城机房元数据采用快同步复制

  • 本地机房/同城机房和异地机房间数据采用异步复制

  • 本地机房/同城机房和异地机房间元数据采用快同步复制

  • 同城机房GTM采用实时同步复制，异地机房GTM不从主机房同步数据

1.2 GoldenDB分组技术
在分布式一主多备架构下，全节点的数据同步，耗时长、用户体验差。因此GoldenDB采用分组技术，将数据节点和事务节点GTM实现分组管理，实现业务的灵活配置。

  • 数据节点集群由多个分片组成，其中一个分片失效，只影响该分片，其它分片中的事务不受影响

  • GTM集群由一个分片组成，该分片可由多个team组成，每个team内有多个GTM节点

  • DB节点按照区域进行分组，比如本地两个team、同城1个team，team数以及team内的分片节点数可以自由设置

  • 主节点根据team响应进行回应，一个team内只要有不少于配置的响应分片数予以回应，则认为这个team的节点是正常的

  • team响应策略可以保证只要team内有一份完整的数据即可保证数据零丢失，同时也可以保证分组间RPO=0

1）分组配置中有几点需要注意

  • 异地机房备节点不参与分组响应策略

  • 分组team响应数是集群级别的设置，不能为每个team单独设置响应数

  • 主节点计数配置，在本地一主一备的配置下，如果设置主节点计数并且team响应数为1，则无法保证本地备节点的数据完整性；如果设置主节点不计数并且team响应数为1，在一主一备的配置下，当本地备节点出现响应延迟，则水位线会降低（高低水位见下一部分内容），降低水位的过程中对该分片的业务会有影响

2）分组策略的配置

  • 大保护策略：所有分组均需要返回响应

  • 高性能策略：无需分组响应

  • 高可用策略：分组响应数大于所配置的小分组响应数（即低水位）

其中高可用策略是以低代价保障RPO为0，在保障数据一致性的前提下大程度的兼顾了服务高可用及同步性能。

1.3 GoldenDB高低水位
GoldenDB中的水位是指主节点收到分组响应的数目，响应数越多则水位越高、越少则水位越低。GoldenDB中高低水位涉及的相关配置包括：高水位、低水位、主是否计数、Team内响应的DB数。

  • 以3组为例，不同用户配置的影响

1.3.1 数据节点高低水位
数据节点的高低水位策略和高低水位的配置、team响应数以及主是否计数有关。以一主三备的数据分片为例，主机和备机1在team1、备机2和备机3在team2，配置的高水位为2、低水位为1，主计数，Team内响应的DB数为2。

  1. 当有效team数为2时，该分片满足高水位运行条件，分片运行在高水位之上

  2. 当有效team数为1时，该分片满足低水位运行条件，分片运行在高低水位之间，系统有低于高水位的告警

  3. 当有效分片数小于1时，该分片不满足低水位运行条件，分片运行在低水位之下，系统有低于低水位的告警，分片为只读状态

注：当由高水位降为低水位的时候，分片会出现短暂的交易TPS降为0的现象，该暂停对外提供服务窗口的时间和Innodb的半同步参数rpl_semi_sync_master_timeout有关。

  • 本地同城和异地的高低水位配置

数据节点的高低水位配置中，本地同城和异地使用不同的配置策略，本地和同城使用一台、异地使用另外一套。当系统运行在本地或同城的时候，只有本地同城的高低水位生效，异地的高低水位不会生效。当系统切换到异地后，异地的高低水位才会生效。

1.3.2 GTM节点高低水位
GTM高低水位和DB数据节点的高低水位的原理大致相同，在实现上有以下不同：

  • GTM主节点所在的team中GTM默认是不计数的

  • GTM高低水位信息存储在本地机房的GTM内存中，该信息没有同步到异地

  • 与数据节点不同的是，异地高低水位与本地同城共用一套

1.4 GoldenDB节点高可用
1.4.1 DB数据节点高可用
DB数据节点是通过一主多备的方式实现高可用，主备之间通过快同步复制技术实现数据同步。DB节点之间的主备切换可以通过OMM（Insight管理界面）发起，当DB主节点出现故障时，由CM（ClusterManager）发起故障切换流程。

1.4.2 GTM事务节点高可用
GTM事务节点通过一主多备的方式实现高可用，主备之间通过MQ增量实时同步消息的方式同步GTID信息。GTM节点之间的主备切换可以通过OMM（Insight管理界面）发起，当GTM主节点出现故障时，由MDS（Metadataserver）发起故障切换流程。

1.4.3 管理节点高可用

GoldenDB支持通过HA或Zookeeper两种方案实现管理节点高可用。

1）管理节点HA方案

HA是通过Pacemaker实现双机热备，通常把正在执行的业务称为活动节点，活动节点的备份称为备用节点。当活动节点出现问题，导致正在运行的业务不能正常运行时，备用节点此时会侦测到，并立即接管活动节点来执行任务，从而实现业务的不中断或短暂中断。

管理节点同机房内采用HA方案，本地和同城机房通过快同步方式同步数据。

2）管理节点zookeeper方案

在zookeeper管理中，所有的事务请求都必须由一个全局的服务器来协调处理（称为Leader），其它服务器称为follower服务器。Leader负责将客户端事务请求转换为事务proposal，并将该proposal分发给集群所有的follower服务器，之后Leader需要等待所有follower服务器的反馈，当超过半数的follower正确的反馈后，leader则会再次向所有的follower服务器分发commit消息，要求将前一个proposal进行提交。

  • Zookeeper方案中的zookeeper集群建议使用奇数，防止出现脑裂

  • Zookeeper集群的每台服务器都会在内存中维护当前服务器的状态，并且每台机器间都相互保持通信，当存在一半的机器能够正常工作，整个集群都能正常对外服务

  • 在管理节点切换的过程中，可能会存在zookeeper主节点和RDB主节点不在一台服务器上的情况

1.4.4 计算节点高可用
GoldenDB中的计算节点是无状态的，所有的计算节点集群都对外提供服务，当其中一个计算节点出现故障的时候，业务访问会路由到其它正常计算节点，对业务基本无感知。

1.5 GoldenDB组件异常切换
1.5.1 DB数据节点异常切换
ClusterManager根据以下条件之一判断DB主节点异常：

  • 主节点的DBagent和ClusterManager链接断开（默认是丢3个心跳）

  • 主节点上所有备节点和主节点的IO线程断开链接

当ClusterManager判断DB数据主节点出现异常的时候，会触发DB切换流程：

  1. 将主节点停止服务，将该分片所有的DB设置为只读，等待所有备机回放完成（默认60s）

  2. 通过脚本获得高低水位信息

  3. 获取所有备机的GTID，超过60s则认为备机异常，设置该备机异常

  4. 当出现多点故障时，需判断

    1. 低于低水位时，DB不能故障切换

    2. 高低水位之间，存在FAM_S或FAM_D的DB不能切换

    3. 高水位时，存在多个FAM_D不能切换

  5. 如果可以切换则进行下一步，否则不满足一致性切换则切换失败

  6. 具备切换条件后，将GTID大的节点置为新主，并解除只读，修正备机的主备关系

注：DB数据节点切换优先切换本地节点，如果跨机房切换设置没打开，当本地副本不可用时，切换会失败。

1.5.2 GTM事务节点异常切换
GTM主异常，分为两种情形：

  • GTM主机器异常，由操作系统通过系统链路告知MDS，GTM异常了，触发故障主备切换流程，且MDS告警

  • GTM主断网或者网络延迟，操作系统无法感知，MDS通过OS每隔2s检测一次链路，检测8次链路均异常，MDS再等5s后看GTM是否恢复，如果16+5秒后GTM主仍没有恢复，则触发主备切换流程，且MDS告警

GTM异常切换流程如下：

  1. MDS设置原主GTM为不可用状态，并通知PM（PM通知proxy）、CM禁用GTM

  2. MDS收到PM、CM禁用GTM的响应消息后通知所有备GTM停止服务，并选择一个GTM作为新主（先本地备再同城备，异地备不参与选主）

  3. 所有备GTM清除与原主的链路，并向MDS回停服响应，MDS收到停服响应后，更新GTM元数据中主从信息

  4. MDS通过OS链路通知所有可用状态的GTM启动服务和主从切换结果

  5. 从GTM收到启动服务请求后向新的主GTM建立链路

  6. 主GTM收到启动服务请求后向备GTM全量同步GTID和sequence数据

  7. 主GTM给MDS回复主从切换应答；新的主GTM确认有一台从GTM全量同步完成后升级为active状态；

  8. MDS通知PM（通知proxy）、CM启用GTM并下发新的主GTM信息；（proxy收到启动服务请求后创建与主GTM链路、CM收到启动服务请求后创建与主GTM链路）

  9. MDS给OMM回应主从切换应答，刷新OMM，主从切换成功

1.5.3 管理节点异常切换
以zookeeper管理为例，定时任务会监听管理节点组件及OMM相关进程和RDB的状态，并将状态信息保存到zookeeper中。当监听出现问题（进程不存在、状态异常等）触发整体切换流程，切换流程如下：

  1. 根据一直运行的脚本获取高低水位信息，在切换开始时检验是否低于高水位，

  2. 如果低于高水位，不触发切换逻辑；高于高水位时，杀本地管理节点及OMM

  3. 等待所有备机回放完成

  4. 查询所有参与选主的管理节点：根据是否允许跨机房切换来确定参与选主的管理节点，返回参与选主管理节点的信息

  5. 判断参与选主管理节点中有无一致性副本

  6. 如无一致性副本，则选取gtid大且优先级高的管理节点为主；如有一致性副本，则选取一致性副本中优先级高的作为新主

  7. 选出新主后根据标志位判断新主是否需要拉数据，如果无一致性副本，则需要向新主拉数据

  8. 确保新主数据大后，启动新主的OMM、管理节点，建立RDB主备关系

  9. 校验RDB主备一致性，若成功则返回新主ip并提供服务

管理节点中的RDB数据库异常切换流程同上。其中管理节点异常切换还需要注意以下几点：

  1. 管理节点中的组件（MDS、CM、PM和OMM）其中一个状态异常会触发整体切换

  2. 管理组件和RDB是不同的切换逻辑，当管理组件异常时会触发管理组件的主切换，但是RDB的主备没有发生切换，所以会出现管理组件的主和RDB的主不在同一个节点的情况

  3. Zookeeper作为管理组件和RDB状态的管理者，RDB主备之间还是通过快同步方式同步

到这里，GoldenDB有关的高可用技术已经介绍完毕，中间个人理解可能出现错漏。

参考资料：

  1. MySQL半同步复制技术：https://www.cnblogs.com/zero-gg/p/9057092.html

  2. GoldenDB高可用技术介绍

相关文章