RDS的高可用核心---Aurora

阿里云关系型数据库RDS是一种稳定可靠、可弹性伸缩的在线数据库服务。
阿里云关系型数据库RDS基于阿里云分布式文件系统和高性能存储，提供了容灾、备份、恢复、监控、迁移等方面的全套解决方案，彻底解决数据库运维的烦恼。
那么，为了确保数据库的高可用性，RDS管控如何进行保障的呢？

1.RDS的高可用功能

首先从整体架构来看，RDS分为以下三种架构和容灾方式。

1.1 主备架构

RDS实例采用主备架构，两个实例位于不同服务器，自动同步数据。主实例不可用时，系统会自动将数据库连接切换至备实例。

1.2 同城容灾

在不同可用区部署主备实例，独立的电力、网络环境可提升数据可靠性。

1.3 异地容灾

RDS MySQL支持创建异地灾备实例，通过数据传输实现异地数据实时同步，在突发状况下，用户可将异地灾备实例切换为主实例，保障业务可用性。

2. RDS的高可用核心Aurora

RDS的高可用核心是Aurora服务，Aurora是RDS HA服务的代码实现，是以集群方式部署的分布式服务。一个region部署一套Aurora集群，每个机房大概3-5个Aurora实例。总数大概20左右，其中一个实例为leader（JGroup选举得出），其它为follower。leader和follower本质上是相同的服务进程，只是选举后leader不仅具有follower的功能，还负责系统元数据的管理及HA任务分发。

2.1 aurora的管控架构

图1

Aurora

该服务负责对metaDB中的信息进行维护，对托管于aurora的实例进行诊断。针对诊断结果异常的实例进行修复。
修复工作依赖备库情况，如果想要确保高可用正常，那么备库的状态至关重要。确保同步状态正常之外，还要确保主备延迟在60S之内，才能确保修复工作正常进行。
作为RDS产品高可用核心的aurora服务，具有探测(Diagnose)、决策(decision)、修复(treat)的功能。

Fireman

该服务是aurora的agent节点，部署在数据库物理机中。主要配合aurora修复工作，完成aurora下发的命令，如重启实例、kill进程、设置只读等。

2.2 HA切换的流程架构

图2

aurora服务每15秒探测一次已托管实例的健康状态(创建实例之后自动托管于aurora)。下发checkMaster任务。

如果探测成功，则进入决策阶段，等待下一次探测任务。如果探测不成功，则继续执行checkMaster任务，如果连续三次探测失败，则进入决策阶段，进行failover。

进入决策阶段之后首先确定HA切换原因，确定原因之后进入修复阶段，进行HA切换修复。
修复阶段首先请求SLB确定backend绑定的物理IP，确定为主库的IP和端口。通过主库的IP找到对应的备库的IP和端口。并确定备库的同步状态和主备延迟大小和磁盘空间是否符合切换条件。

如果确认成功，则进行下一步。如果确认失败，则退出。

杀掉备库的所有进程，之后再次试探主库是否可以连接。

如果可以连接，需要杀掉主库的所有线程，或者停止MySQL进程。确保没有新的连接产生。如果不可以连接，则继续下一步。

确认备库与主库的心跳时间差。

如果大于60s，则退出。如果小于60s，则继续。

前置检查成功之后开始正式修复工作。修复详情如下：

2.3 探测
Diagnose

开启诊断：diagnose started
依据SLB链路上的IP确定当前主库，在主库执行心跳检查SQL：
connection_timeout=15，squery_timeout=15s

SET sql_log_bin = 1;
/* rds internal mark */ INSERT INTO mysql.ha_health_check (id, type)
VALUES (${当前时间戳}, 'm')
ON DUPLICATE KEY UPDATE id = ${当前时间戳};
/* rds internal mark */ DELETE FROM mysql.ha_health_check WHERE id ${当前时间戳} AND type = 'm';

CheckMaster

第一次检查，如果成功，则直接进行决策，如不成功进行第二次检查。

CheckMaster

第二次检查，如果成功，则直接进行决策，如不成功进行第三次检查。

CheckMaster

第三次检查，如果成功，则直接进行决策，如不成功进行故障决策。

2.4 决策
2.4.1 SetHaReason

根据连接报错设置HA切换类型。

MASTER_DOWN

如果有类似"Connection refused"的网络不通错误信息，即为网络不通。将切换原因设置为MASTER_DOWN。

CONNECTION_TIMEOUT

如果有类似"Connection timed out"的连接超时，即为连接超时。将切换原因设置为CONNECTION_TIMEOUT。

TCP_TIMEOUT

是否连接正常，但读超时。如果有"Read timed out"错误信息，即为读超时。
执行如下sql，如果1执行有异常，或者2返回“是否大于1000”，均视为IO Hang, 将切换原因设置为TCP_TIMEOUT。

1.SELECT id FROM mysql.ha_health_check WHERE type = 'm'
2.SELECT max(max_time) FROM information_schema.INNODB_IO_STATUS

MASTER_HANG

如果有类似"MySQLTimeoutException.class"的报错，则将切换原因设置为MASTER_HANG。

2.4.2 Failover

开启修复。

2.5 修复
RefreshCurrentBackend

通过请求SLB，得到后端IP，端口，ins_id.

FindTargetSlave

所有备库节点进行如下查询操作，条件从上至下，符合多的优先。
show slave statue;

检查主备延迟，不能超过60s。
1. show slave status 有返回
2. Master_Log_File最大
3. Read_Master_Log_Pos最大

检查目标备库磁盘空间，是否满(95%)。
设置目标备库为只读。
执行如下命令：

show global variables like 'read_only'

如果返回非“ON”，则执行如下命令：

set global read_only = ON

KillTargetProcess

kill备库所有连接。

BackendConnectable

探测主库是否可连接。
如果不可连接，继续下一阶段。
如果可连，执行如下操作。
1.kill原主库的客户端连接。
2.将其设置为只读。

成功：再次kill主库的客户端连接, 以确保原主不会再有写入操作。失败：Kill原主库上的MySQL进程，以确保原主不会再有写入操作。

3.放大sync_binlog: set global sync_binlog = 1000
4.关闭event: set global event_scheduler = OFF
5.等待备库同步，如果同步失败，退出，回滚将主库设为读写状态。

show global variables like rds_rpl_double_sync_enabled 如果有返回就执行1， 否则2
1 select master_pos_wait('${file}', ${pos}, ${timeout});
2 select master_pos_wait('${file}', ${pos}, ${timeout}, '')
其中file, pos是前面show status返回的Master_Log_File, Read_Master_Log_Pos
如果SQL返回第1列结果是空，或者是-1，都认为同步失败。

CheckTimestampDelta

探测heartbeat on master，slave

SELECT id FROM mysql.ha_health_checkWHERE type ='m'
SELECT id FROM mysql.ha_health_checkWHERE type ='s'

对比ID转化的时间戳是否差距在60s之内。

TransferApplyBinlog

给备库主机上的fireman进程下发请求，获取日志信息。

LogMasterSlaveStatus

查看slave status。

ChangeBackend

请求SLB，更换backend for vip。
更换backend，从主库IP:端口，更改为备库IP:端口。

KillBackendProcess

杀死原主库上的进程。

MaintainMetadata

修改dbaas库的instance_stat表中的主备关系。

KeepTargetReadWrite

给新主库的fireman进程下发请求，新主库执行如下命令，关闭只读。

set read_only OFF

ReduceTargetSyncBinlog

减小sync_binlog参数。
新主库执行如下命令：

set sync_binlog =1

OpenTargetEventScheduler

打开event_scheduler参数。
新主库执行如下命令：

set event_scheduler = 'ON'

FireChangeMasterTask

开启change master for readonly instance任务。

StartupBackend

给新备库的fireman进程下发请求，开启备库进程。

我们是阿里云智能全球技术服务-SRE团队，我们致力成为一个以技术为基础、面向服务、保障业务系统高可用的工程师团队；提供专业、体系化的SRE服务，帮助广大客户更好地使用云、基于云构建更加稳定可靠的业务系统，提升业务稳定性。我们期望能够分享更多帮助企业客户上云、用好云，让客户云上业务运行更加稳定可靠的技术，您可用钉钉扫描下方二维码，加入阿里云SRE技术学院钉钉圈子，和更多云上人交流关于云平台的那些事。

本文转自网络，原文链接：https://developer.aliyun.com/article/784434
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！