关于rds:RDS的高可用核心Aurora

91次阅读

共计 3842 个字符,预计需要花费 10 分钟才能阅读完成。

简介: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 的管控架构

Aurora

该服务负责对 metaDB 中的信息进行保护,对托管于 aurora 的实例进行诊断。针对诊断后果异样的实例进行修复。

修复工作依赖备库状况,如果想要确保高可用失常,那么备库的状态至关重要。确保同步状态失常之外,还要确保主备提早在 60S 之内,能力确保修复工作失常进行。
作为 RDS 产品高可用外围的 aurora 服务,具备探测 (Diagnose)、决策(decision)、修复(treat) 的性能。

Fireman

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

2.2 HA 切换的流程架构

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 过程下发申请,开启备库过程。

原文链接
本文为阿里云原创内容,未经容许不得转载。

正文完
 0