利用異地同步備份將 Redis ElastiCache 的停機時間降至最 - Amazon ElastiCache 的雷迪斯

本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。

利用異地同步備份將 Redis ElastiCache 的停機時間降至最

Redis 有許多執行個體可能需要取代主節點;其 ElastiCache 中包括特定類型的計劃維護,以及主節點或可用區域故障的不太可能發生事件。

此取代會導致叢集出現一些停機情況,但如果啟用異地同步備份,停機時間可降至最低。主節點的角色會自動容錯移轉到其中一個僅供讀取複本。不需要建立和佈建新的主要節點,因為 ElastiCache 會透明地處理這個節點。此容錯移轉及複本提升可確保您能在提升完成時立即繼續寫入新的主要節點。

ElastiCache 也會傳播已提升複本的網域名稱服務 (DNS) 名稱。它會執行這項操作的原因在於,若您的應用程式正在寫入主要端點,您的應用程式中便不需要變更任何端點。如果您是從個別端點讀取,則請確保將提升至主要端點的複本讀取端點變更為新複本的端點。

如果是計劃的節點替換,這些替換因維護更新或自助式更新而啟動,請留意以下事項:

  • 對 ElastiCache 於 Redis 叢集,當叢集提供傳入寫入要求時,已規劃的節點取代完成。

  • 對於 Redis 叢集模式已停用的叢集 (其已啟用的多個可用區是在 5.0.6 或更新版本的引擎上執行),在叢集為傳入寫入請求提供服務時,計劃的節點替換就會完成。

  • 對於 Redis 叢集模式已停用的叢集 (其已啟用的多個可用區是在 4.0.10 或更早版本的引擎上執行),您可能會注意到與 DNS 更新相關的短暫寫入中斷。此中斷最多可能需要幾秒鐘的時間。此程序的速度比重新建立及佈建新的主節點更快 (也就是沒有啟用異地同步備份時發生的程序)。

您可以使用 ElastiCache 管理主控台或 ElastiCache API 啟用異地同步備份。 AWS CLI

在 Redis 叢集 (在 API 和 CLI、複寫群組中) 上啟用 ElastiCache 異地同步備份可改善容錯能力。當您的叢集的讀取/寫入主要叢集因任何原因變得無法連線或失敗的情況下,這特別有用。只有在每個碎片中具有多個節點的 Redis 叢集上,才支援多個可用區。

啟用多個可用區

您可以在使用 ElastiCache 主控台或 API 建立或修改叢集 (API 或 CLI、複寫群組) 時啟用異地 AWS CLI同步備份 ElastiCache。

您只能在至少有一個可用僅供讀取複本的 Redis (停用叢集模式) 叢集上啟用異地同步備份。沒有僅供讀取複本的叢集無法提供高度可用性或容錯能力。如需建立附帶複寫叢集的資訊,請參閱建立 Redis 複寫群組。如需將僅供讀取複本新增到附帶複寫叢集的資訊,請參閱為 Redis (停用叢集模式) 複寫群組新增僅供讀取複本

啟用異地同步備份 (主控台)

當您建立新的 Redis 叢集或透過複寫修改現有 Redis 叢集時,可以使用 ElastiCache 主控台啟用異地同步備份。

預設會在 Redis (啟用叢集模式) 叢集上啟用異地同步備份。

重要

ElastiCache 僅當叢集包含與所有碎片中的主要複本不同的可用區域中至少一個複本時,才會自動啟用異地同步備份。

使用主 ElastiCache 控台建立叢集時啟用異地同步備份

如需此程序的詳細資訊,請參閱建立 Redis (停用叢集模式) 叢集 (主控台)。請務必確保您有一或多個複本,並啟用多個可用區。

在現有叢集上啟用異地同步備份 (主控台)

如需此程序的詳細資訊,請參閱使用 AWS Management Console修改叢集。

啟用異地同步備份 (AWS CLI)

下列程式碼範例使用 AWS CLI 為複寫群組redis12啟用異地同步備份。

重要

複寫群組 redis12 必須已存在,並且其中必須至少要有一個可用的僅供讀取複本。

若為 Linux、macOS 或 Unix:

aws elasticache modify-replication-group \ --replication-group-id redis12 \ --automatic-failover-enabled \ --multi-az-enabled \ --apply-immediately

針對 Windows:

aws elasticache modify-replication-group ^ --replication-group-id redis12 ^ --automatic-failover-enabled ^ --multi-az-enabled ^ --apply-immediately

此命令的 JSON 輸出看起來會與以下內容相似。

{ "ReplicationGroup": { "Status": "modifying", "Description": "One shard, two nodes", "NodeGroups": [ { "Status": "modifying", "NodeGroupMembers": [ { "CurrentRole": "primary", "PreferredAvailabilityZone": "us-west-2b", "CacheNodeId": "0001", "ReadEndpoint": { "Port": 6379, "Address": "redis12-001.v5r9dc.0001.usw2.cache.amazonaws.com" }, "CacheClusterId": "redis12-001" }, { "CurrentRole": "replica", "PreferredAvailabilityZone": "us-west-2a", "CacheNodeId": "0001", "ReadEndpoint": { "Port": 6379, "Address": "redis12-002.v5r9dc.0001.usw2.cache.amazonaws.com" }, "CacheClusterId": "redis12-002" } ], "NodeGroupId": "0001", "PrimaryEndpoint": { "Port": 6379, "Address": "redis12.v5r9dc.ng.0001.usw2.cache.amazonaws.com" } } ], "ReplicationGroupId": "redis12", "SnapshotRetentionLimit": 1, "AutomaticFailover": "enabling", "MultiAZ": "enabled", "SnapshotWindow": "07:00-08:00", "SnapshottingClusterId": "redis12-002", "MemberClusters": [ "redis12-001", "redis12-002" ], "PendingModifiedValues": {} } }

如需詳細資訊,請參閱 AWS CLI 命令參考中的下列主題:

啟用異地同步備份 (ElastiCache API)

下列程式碼範例使用 ElastiCache API 來為複寫群組redis12啟用異地同步備份。

注意

若要使用此範例,複寫群組 redis12 必須已存在,並且其中必須至少要有一個可用的僅供讀取複本。

https://elasticache.us-west-2.amazonaws.com/ ?Action=ModifyReplicationGroup &ApplyImmediately=true &AutoFailover=true &MultiAZEnabled=true &ReplicationGroupId=redis12 &Version=2015-02-02 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20140401T192317Z &X-Amz-Credential=<credential>

如需詳細資訊,請參閱 ElastiCache API 參考中的下列主題:

具有異地同步備份回應的故障案例

在異地同步備份推出之前,透過重新建立並重新佈建故障節點, ElastiCache 偵測並取代叢集的故障節點。如果啟用多個可用區,故障的主要節點會容錯移轉至複寫延遲最短的複本。選取的複本會自動提升為主要節點,這比建立並重新佈建新的主要節點更快。此程序通常只需要幾秒鐘,您便能再次寫入叢集。

啟用異地同步備份時,會 ElastiCache 持續監控主要節點的狀態。若主要節點故障,便會根據故障的類型執行以下其中一個動作。

只有主節點故障的故障案例

若只有主要節點故障,複寫延遲最短的僅供讀取複本便會提升至主要叢集。接著會在與故障的主要節點相同的可用區域中建立並佈建遭取代的僅供讀取複本。

當只有主節點發生故障時, ElastiCache 異地同步備份會執行下列動作:

  1. 失敗的主要節點會離線。

  2. 複寫延隔最少的僅供讀取複本會提升為主要節點。

    寫入通常可以在提升程序完成時繼續,這通常僅需要數秒鐘。如果您的應用程式正在寫入主要端點,則不需要變更用於寫入或讀取的端點。 ElastiCache傳播已提升複本的 DNS 名稱。

  3. 啟動及佈建替換用的僅供讀取複本。

    替換用的僅供讀取複本會在失敗主要節點所在的可用區域內啟動,維持節點的分佈。

  4. 複本會與新的主要節點同步。

新複本可供使用之後,請注意下列效果:

  • 主要端點 - 您不需要對應用程式進行任何變更,因為新主節點的 DNS 名稱會傳播到主要端點。

  • 讀取端點 - 讀取者端點會自動更新,以指向新的複本節點。

如需尋找叢集端點的資訊,請參閱下列主題:

 

主節點和某些僅供讀取複本故障的故障案例

若主要節點及至少一個僅供讀取複本失敗時,複寫延隔最少的可用複本會提升至主要叢集。新的僅供讀取複本也會在失敗節點及提升為主要節點複本的相同可用區域內建立及佈建。

當主節點和某些僅供讀取複本失敗時, ElastiCache 異地同步備份會執行下列動作:

  1. 失敗的主要節點和失敗的僅供讀取複本會離線。

  2. 複寫延隔最少的可用複本會提升為主要節點。

    寫入通常可以在提升程序完成時繼續,這通常僅需要數秒鐘。如果您的應用程式正在寫入主要端點,則不需要變更用於寫入的端點。 ElastiCache 傳播已提升複本的 DNS 名稱。

  3. 建立及佈建替換用的複本。

    替換用的複本會在失敗節點所在的可用區域內建立,維持節點的分佈。

  4. 所有叢集都會和新的主要節點同步。

在新節點可用之後,請對應用程式進行以下變更:

  • 主要端點 - 不要對應用程式做任何變更。新主要節點的 DNS 名稱會傳播到主要端點。

  • 讀取端點 - 讀取端點會自動更新,以指向新的複本節點。

 

整個叢集故障的故障案例

若所有項目都失敗,便會在原始節點的相同可用區域內重新建立及佈建所有節點。

在此案例中,叢集內的所有資料都會因為叢集內的每個節點都發生故障而遺失。這種情況相當罕見。

當整個叢集發生故障時, ElastiCache 異地同步備份會執行下列動作:

  1. 失敗的主要節點和僅供讀取複本會離線。

  2. 建立及佈建替換用的主要節點。

  3. 建立及佈建替換用的複本。

    替代項目會在失敗節點所在的可用區域內建立,維持節點的分佈。

    因為整個叢集失敗,資料會遺失,並且所有新的節點都會從零開始。

因為每個替換用節點都會具備與欲取代節點相同的端點,因此您不需要在應用程式內對任何端點進行變更。

如需尋找複寫群組端點的資訊,請參閱下列主題:

我們建議您在不同可用區域內建立主要節點和僅供讀取複本,以提升您的容錯能力層級。

測試自動容錯移轉

啟用自動容錯移轉後,您可以使用 ElastiCache 主控台 AWS CLI、和 ElastiCache API 對其進行測試。

在測試時,請注意下列事項:

  • 您可以使用此作業,在任何滾動 24 小時期間內,在最多 15 個碎片 (在 ElastiCache API 中稱為節點群組 AWS CLI) 上測試自動容錯移轉。

  • 若您在不同叢集 (在 API 和 CLI 中稱為複寫群組) 內的碎片上呼叫此操作,您可以同時進行呼叫。

  • 在某些情況下,您可能會在相同 Redis (啟用叢集模式) 複寫群組中的不同碎片上多次呼叫此作業。在這種情況下,必須先完成第一個節點取代,才能夠執行後續呼叫。

  • 若要判斷節點取代是否完成,請使用 Amazon ElastiCache 主控台 AWS CLI、或 ElastiCache API 檢查事件。尋找與自動容錯移轉相關的以下事件 (根據可能發生的順序列出):

    1. 複寫群組訊息:Test Failover API called for node group <node-group-id>

    2. 快取叢集訊息:Failover from primary node <primary-node-id> to replica node <node-id> completed

    3. 複寫群組訊息:Failover from primary node <primary-node-id> to replica node <node-id> completed

    4. 快取叢集訊息:Recovering cache nodes <node-id>

    5. 快取叢集訊息:Finished recovery for cache nodes <node-id>

    如需詳細資訊,請參閱下列內容:

  • 此 API 是專為在 ElastiCache 容錯移轉時測試應用程式的行為而設計。並非設計成啟動容錯移轉以解決叢集問題的操作工具。此外,在某些情況下,例如大規模運營事件, AWS 可能會阻止此 API。

使用測試自動容錯移轉 AWS Management Console

使用下列程序,透過主控台測試自動容錯移轉。

測試自動容錯移轉
  1. 請登入 AWS Management Console 並開啟 ElastiCache 主控台,網址為 https://console.aws.amazon.com/elasticache/

  2. 在導覽窗格中,選擇 Redis

  3. 從 Redis 叢集的清單,選擇您欲測試叢集左側的方塊。​此叢集至少需要有一個僅供讀取複本節點。

  4. Details (詳細資訊) 區域中,確認此叢集已啟用異地同步備份。若叢集尚未啟用多個可用區,請選擇不同叢集,或是修改此叢集以啟用多個可用區。如需詳細資訊,請參閱 使用 AWS Management Console

    圖片:已啟用異地同步備份的 Redis 叢集詳細資訊區域
  5. 若為 Redis (停用叢集模式),請選擇叢集的名稱。

    若是 Redis (啟用叢集模式),請執行下列操作:

    1. 選擇叢集名稱。

    2. Shards (碎片) 頁面上,針對您希望測試容錯移轉的碎片 (API 和 CLI 中稱為節點群組),選擇碎片名稱。

  6. 在 Nodes (節點) 頁面上,選擇 Failover Primary (容錯移轉主要節點)

  7. 選擇 Continue (繼續) 來容錯移轉主要節點,或是 Cancel (取消) 來取消操作而不容錯移轉主要節點。

    在容錯移轉程序期間,主控台會繼續將節點的狀態顯示為「可用」。若要追蹤容錯移轉測試的進度,請從主控台導覽窗格選擇 Events (事件)。在 Events (事件) 標籤上,觀察指出您容錯移轉已啟動的事件 (Test Failover API called) 並完成 (Recovery completed)。

 

使用測試自動容錯移轉 AWS CLI

您可以使用 AWS CLI 作test-failover業在任何啟用異地同步備份的叢集上測試自動容錯移轉。

參數
  • --replication-group-id - 必要。要測試的複寫群組 (在主控台上為叢集)。

  • --node-group-id - 必要項目。您欲測試自動容錯移轉的節點群組名稱。在滾動的 24 小時期間內,您最多可以測試 15 個節點群組。

下列範例會使用在 AWS CLI Redis (已啟用叢集模式) 叢redis00redis00-0003中的節點群組上測試自動容錯移轉。

範例 測試自動容錯移轉

若為 Linux、macOS 或 Unix:

aws elasticache test-failover \ --replication-group-id redis00 \ --node-group-id redis00-0003

針對 Windows:

aws elasticache test-failover ^ --replication-group-id redis00 ^ --node-group-id redis00-0003

上述命令的輸出會與以下內容相似。

{ "ReplicationGroup": { "Status": "available", "Description": "1 shard, 3 nodes (1 + 2 replicas)", "NodeGroups": [ { "Status": "available", "NodeGroupMembers": [ { "CurrentRole": "primary", "PreferredAvailabilityZone": "us-west-2c", "CacheNodeId": "0001", "ReadEndpoint": { "Port": 6379, "Address": "redis1x3-001.7ekv3t.0001.usw2.cache.amazonaws.com" }, "CacheClusterId": "redis1x3-001" }, { "CurrentRole": "replica", "PreferredAvailabilityZone": "us-west-2a", "CacheNodeId": "0001", "ReadEndpoint": { "Port": 6379, "Address": "redis1x3-002.7ekv3t.0001.usw2.cache.amazonaws.com" }, "CacheClusterId": "redis1x3-002" }, { "CurrentRole": "replica", "PreferredAvailabilityZone": "us-west-2b", "CacheNodeId": "0001", "ReadEndpoint": { "Port": 6379, "Address": "redis1x3-003.7ekv3t.0001.usw2.cache.amazonaws.com" }, "CacheClusterId": "redis1x3-003" } ], "NodeGroupId": "0001", "PrimaryEndpoint": { "Port": 6379, "Address": "redis1x3.7ekv3t.ng.0001.usw2.cache.amazonaws.com" } } ], "ClusterEnabled": false, "ReplicationGroupId": "redis1x3", "SnapshotRetentionLimit": 1, "AutomaticFailover": "enabled", "MultiAZ": "enabled", "SnapshotWindow": "11:30-12:30", "SnapshottingClusterId": "redis1x3-002", "MemberClusters": [ "redis1x3-001", "redis1x3-002", "redis1x3-003" ], "CacheNodeType": "cache.m3.medium", "DataTiering": "disabled", "PendingModifiedValues": {} } }

若要追蹤容錯移轉的進度,請使用 AWS CLI describe-events作業。

如需詳細資訊,請參閱下列內容:

 

使用 ElastiCache API 測試自動容錯移轉

您可以使用 ElastiCache API 作業TestFailover在任何已啟用異地同步備份的叢集上測試自動容錯移轉。

參數
  • ReplicationGroupId - 必要項目。要測試的複寫群組 (在主控台上為叢集)。

  • NodeGroupId - 必要項目。您欲測試自動容錯移轉的節點群組名稱。在滾動的 24 小時期間內,您最多可以測試 15 個節點群組。

以下範例會在複寫群組 (主控台上為叢集) redis00 中的節點群組 redis00-0003 上測試自動容錯移轉。

範例 測試自動容錯移轉
https://elasticache.us-west-2.amazonaws.com/ ?Action=TestFailover &NodeGroupId=redis00-0003 &ReplicationGroupId=redis00 &Version=2015-02-02 &SignatureVersion=4 &SignatureMethod=HmacSHA256 &Timestamp=20140401T192317Z &X-Amz-Credential=<credential>

若要追蹤容錯移轉的進度,請使用 ElastiCache DescribeEvents API 作業。

如需詳細資訊,請參閱下列內容:

 

Redis 多個可用區的限制

請注意 Redis 多個可用區的下列限制:

  • Redis 2.8.6 版及更新版本支援多個可用區。

  • T1 節點類型不支援 Redis 多個可用區。

  • Redis 複寫是非同步的。因此,當主要節點容錯移轉至複本時,可能會因複寫延遲而導致一小部分的資料遺失。

    當選擇要升級 ElastiCache 為主要的複本時,Redis 會選擇複寫延遲最小的複本。換句話說,它會選擇最新的複本。這麼做有助於減少遺失的資料量。具有最少複寫延遲的複本可以和失敗的主要節點位於相同可用區域或不同可用區域中。

  • 只有異地同步備份和自動容錯移轉停用時,才能手動將僅供讀取複本提升為 Redis (停用叢集模式) 的主節點。若要將僅供讀取複本節點提升為主要節點,請採取下列步驟:

    1. 停用叢集上的多個可用區。

    2. 停用叢集上的自動容錯移轉。您可以使用 Redis 主控台來執行這項操作,方法是取消勾選複寫群組的 Auto failover (自動容錯移轉) 核取方塊。您可以在呼叫作業false時將AutomaticFailoverEnabled屬性設定為,使用來執行此ModifyReplicationGroup操作。 AWS CLI

    3. 將僅供讀取複本提升為主要節點。

    4. 重新啟用多個可用區。

  • ElastiCache Redis 異地同步備份和僅附加檔案 (AOF) 是互斥的。若您啟用其中一項,便無法啟用另外一項。

  • 節點故障很少會是因為整個可用區域失敗所造成。在此情況下,只有在可用區域已備份時,才會建立取代失敗主要節點的複本。例如,假設有一個複寫群組,其中主要節點位於 AZ-a,複本位於 AZ-b 及 AZ-c。若主要節點失敗,複寫延隔最少的複本便會提升至主要叢集。然後,只有在 AZ-A 備份且可用時,才 ElastiCache 會在 AZ (失敗的主要複本所在的位置) 中建立新複本。

  • 由客戶初始化的主要節點重新開機不會觸發自動容錯移轉。其他重新開機和故障會觸發自動容錯移轉。

  • 主要節點重新開機時,便會在回到線上時清除資料。當僅供讀取複本看到已清除的主要叢集時,它們便會清除資料複本,造成資料遺失。

  • 在提升僅供讀取複本之後,其他複本便會和新的主要節點同步。初始化同步後,複本的內容會被刪除,而且它們會從新的主要節點同步資料。此同步程序會造成短暫的中斷,在此期間無法存取複本。此同步程序也會在與複本進行同步時,於主要節點上造成暫時性的負載增加。此行為是 Redis 的原生行為,而且不是異地 ElastiCache同步備份的唯一行為。如需有關此 Redis 行為的詳細資訊,請參閱 Redis 網站上的複寫

重要

對於 Redis 2.8.22 版及更新版本,您無法建立外部複本。

對於 2.8.22 之前的 Redis 版本,建議您不要將外部 Redis 複本連接到已啟用異地同步備份 ElastiCache 的 Redis 叢集。這種不受支援的組態可能會造成無法正確執行容錯移轉和復原的問題。 ElastiCache 若要將外部 Redis 複本連線到 ElastiCache叢集,請確定在進行連線之前未啟用異地同步備份。