

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

# Amazon ElastiCache 的備援功能
<a name="disaster-recovery-resiliency"></a>

AWS全球基礎設施是以AWS區域和可用區域為基礎建置的。AWS區域提供多個實體隔離和隔離的可用區域，這些區域以低延遲、高輸送量和高度備援的網路連接。透過可用區域，您所設計與操作的應用程式和資料庫，就能夠在可用區域之間自動容錯移轉，而不會發生中斷。可用區域的可用性、容錯能力和擴充能力，均較單一或多個資料中心的傳統基礎設施還高。

如需AWS區域和可用區域的詳細資訊，請參閱 [AWS全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)。

除了AWS全球基礎設施之外，Amazon ElastiCache 還提供數種功能，以協助支援您的資料彈性和備份需求。

**Topics**
+ [減少故障](#FaultTolerance)

## 減少故障
<a name="FaultTolerance"></a>

規劃您的 Amazon ElastiCache 實作時，您應規劃讓發生故障時對您的應用程式和資料造成最小的影響。本節中的主題涵蓋您可以採取用來保護您的應用程式和資料不受故障的方法。

**Topics**
+ [緩解執行 Memcached 時的故障](#FaultTolerance.Memcached)
+ [緩解執行 Valkey 或 Redis OSS 時的故障](#FaultTolerance.Redis)
+ [建議](#FaultTolerance.Recommendations)

### 緩解執行 Memcached 時的故障
<a name="FaultTolerance.Memcached"></a>

執行 Memcached 引擎時，您有下列選項可用於將故障的影響最小化。在您的故障緩解規劃中要解決兩個類型的故障：節點故障和可用區域故障。

#### 緩解節點故障
<a name="FaultTolerance.Memcached.Node"></a>

無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解節點故障，讓應用程式清楚了解節點故障的情況。若要減輕節點型叢集中節點故障的影響，請將快取的資料分散到更多節點。由於節點型叢集不支援複寫，節點故障一律會導致叢集遺失一些資料。

建立 Memcached 叢集時，您可以使用 1 到 60 個節點建立叢集，或透過特殊請求建立更多節點。將您的資料分割在更大量的節點間表示若節點故障，您遺失的資料較少。例如，如果將您的資料分割在 10 個節點間，任何單一節點大約會存放 10% 的快取資料。在此情況下，節點故障會遺失大約 10% 的快取，這個部分需要在建立和佈建替代節點時加以替代。如果在 3 個較大節點中快取相同的資料，節點的故障會遺失大約 33% 的快取資料。

如需指定 Memcached 叢集中節點數量的詳細資訊，請參閱[建立 Memcached 叢集 (主控台)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached)。

#### 緩解可用區域故障
<a name="FaultTolerance.Memcached.AZ"></a>

無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解可用區域故障，讓應用程式清楚了解 AZ 故障的情況。

若要減輕節點型叢集中可用區域故障的影響，請在盡可能多的可用區域中找到您的節點。在極少數的 AZ 故障情況下，您會遺失在該 AZ 快取的資料，而非在其他 AZ 快取的資料。

**為什麼要有這麼多節點？**  
*如果我的區域只有 3 個可用區域，既然若一個 AZ 故障，我會遺失大約 1/3 的資料，為什麼我需要超過 3 個節點？*

這是個好問題。請記得我們正嘗試緩解兩個獨特類型的故障，節點和可用區域。您是對的，如果您的資料分散在可用區域間，當其中一個區域故障時，您只會遺失在該 AZ 中快取的資料，而不論您擁有的節點數量為何。不過，如果某個節點故障，擁有的節點數量越多可減少資料遺失的比例。

沒有「神奇公式」可決定您叢集中的節點數量。您必須衡量資料遺失的影響、故障可能性與成本，並從中得出自己的結論。

如需指定 Memcached 叢集中節點數量的詳細資訊，請參閱[建立 Memcached 叢集 (主控台)](Clusters.Create-mc.md#Clusters.Create.CON.Memcached)。

如需區域及可用區域的詳細資訊，請參閱[選擇 ElastiCache 的區域和可用區域](RegionsAndAZs.md)。

### 緩解執行 Valkey 或 Redis OSS 時的故障
<a name="FaultTolerance.Redis"></a>

執行 Valkey 或 Redis OSS 引擎時，您有下列選項可將節點或可用區域故障的影響降至最低。

#### 緩解節點故障
<a name="FaultTolerance.Redis.Cluster"></a>

無伺服器快取會利用 Multi-AZ 架構自動緩解節點故障，讓應用程式清楚了解節點故障的情況。節點型叢集必須適當設定，以減輕個別節點的故障。

若要減輕 Valkey 或 Redis OSS 節點故障對節點型叢集的影響，您有下列選項：

**Topics**
+ [緩解故障：Valkey 或 Redis OSS 複寫群組](#FaultTolerance.Redis.Cluster.Replication)

##### 緩解故障：Valkey 或 Redis OSS 複寫群組
<a name="FaultTolerance.Redis.Cluster.Replication"></a>

Valkey 或 Redis OSS 複寫群組是由單一主節點組成，您的應用程式可以讀取和寫入，以及 1 到 5 個唯讀複本節點。每當資料寫入主要節點，它也會在僅供讀取複本節點上非同步更新。

**當僅供讀取複本故障時**

1. ElastiCache 偵測到故障的僅供讀取複本。

1. ElastiCache 讓故障的節點離線。

1. ElastiCache 啟動並於相同 AZ 中佈建替代節點。

1. 新節點會與主要節點同步。

在這段時間，您的應用程式可以繼續使用其他節點來讀取和寫入。

**Valkey 或 Redis OSS 異地同步備份**  
您可以在 Valkey 或 Redis OSS 複寫群組上啟用異地同步備份。無論您是否啟用多個可用區，系統將偵測並自動取代故障的主要節點。它的發生方式可能因多可用區域是否已啟用而不同。

**當多個可用區啟用時**

1. ElastiCache 偵測到主節點故障。

1. ElastiCache 將具有最短複寫延遲的僅供讀取複本節點提升為主節點。

1. 另一個複本與新主要節點同步。

1. ElastiCache 在故障主節點的可用區域中加速執行僅供讀取複本。

1. 新節點會與新提升的主要節點同步。

容錯移轉至複本節點的速度一般會較建立和佈建新主要節點來得快。這表示您的應用程式可以較未啟用多個可用區時更早繼續寫入至您的主要節點。

如需詳細資訊，請參閱[搭配 Valkey 和 Redis OSS 使用異地同步備份，將 ElastiCache 中的停機時間降至最低](AutoFailover.md)。

**當多個可用區停用時**

1. ElastiCache 偵測到主節點故障。

1. ElastiCache 讓主節點離線。

1. ElastiCache 建立和佈建新的主節點以取代故障的主節點。

1. ElastiCache 將新主節點與現有複本同步。

1. 同步完成時，新節點會如同叢集的主要節點般運作。

在此程序期間的步驟 1 到 4 期間，您的應用程式無法寫入主要節點。不過，應用程式可以繼續從複本節點讀取。

為了增加保護，建議您在不同可用區域 (AZ) 的複寫群組中啟動節點。如果您執行此動作，可用區域的故障只會影響該可用區域 (而非其他區域) 中的節點。

如需詳細資訊，請參閱[使用複寫群組的高可用性](Replication.md)。

#### 緩解可用區域故障
<a name="FaultTolerance.Redis.AZ"></a>

無伺服器快取會利用複寫的 Multi-AZ 架構自動緩解可用區域故障，讓應用程式清楚了解 AZ 故障的情況。

若要減輕節點型叢集中可用區域故障的影響，請盡可能在可用區域中找出每個碎片的節點。

不論碎片中有多少個節點，如果它們全都放在相同可用區域中，只要該可用區域發生災難性故障，就會造成您遺失所有碎片的資料。不過，如果將您的節點放在多個可用區域，任何可用區域的失敗只會造成您遺失該可用區域中的節點。

無論您在何時遺失節點，都會遇到效能降級，因為讀取操作現在由較少的節點共用。此效能降級將繼續，直到節點遭到取代為止。

如需指定 Valkey 或 Redis OSS 節點可用區域的資訊，請參閱 [建立 Valkey （停用叢集模式） 叢集 （主控台）](SubnetGroups.designing-cluster-pre.valkey.md#Clusters.Create.CON.valkey-gs)。

如需區域及可用區域的詳細資訊，請參閱[選擇 ElastiCache 的區域和可用區域](RegionsAndAZs.md)。

### 建議
<a name="FaultTolerance.Recommendations"></a>

我們建議您透過節點型叢集建立無伺服器快取，因為您會自動獲得更好的容錯能力，而不需要額外的組態。不過，建立節點型叢集時，您需要規劃兩種類型的故障：個別節點故障和廣泛的可用區域故障。最佳的故障緩解規劃可解決這兩種類型的故障。

#### 將節點故障的影響降至最低
<a name="FaultTolerance.Recommendations.NodeFailure"></a>

若要在使用 Valkey 或 Redis OSS 時將節點故障的影響降至最低，建議您的實作在每個碎片中使用多個節點，並將節點分散到多個可用區域。無伺服器快取會自動進行此操作。

對於 Valkey 或 Redis OSS 上的節點型叢集，我們建議您在複寫群組上啟用異地同步備份，以便 ElastiCache 在主節點故障時自動容錯移轉至複本。

執行 Memcached 並在節點間分割您的資料時，使用的節點愈多，任何節點故障時遺失的資料愈少。

#### 將可用區域故障的影響降到最低
<a name="FaultTolerance.Recommendations.AZFailure"></a>

若要將可用區域故障的影響降到最低，建議您在盡可能多的不同可用區域中啟動節點。在可用區域間平均分散節點，可將很少見的可用區域故障影響降到最低。無伺服器快取會自動進行此操作。

#### 其他預防工作
<a name="FaultTolerance.Recommendations.Other"></a>

如果您正在執行 Valkey 或 Redis OSS，除了上述內容之外，建議您排定叢集的定期備份。備份 (快照) 會建立一個 .rdb 檔案，供您在故障或損毀的情況下用來還原您的快取。如需詳細資訊，請參閱[快照和還原](backups.md)。