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技術學院釘釘圈子，和更多雲上人交流關於雲平臺的那些事。