本頁說明 Memorystore for Redis Cluster 如何維護執行個體。此外，本文也提供資訊和設定建議，讓用戶端應用程式瞭解如何善用 Memorystore for Redis Cluster 的零停機維護設計。這些建議適用於高可用性叢集和沒有副本的叢集。但強烈建議所有生產用途案例都採用高可用性設定。
為確保服務安全可靠、效能卓越，而且是最新版本，Memorystore for Redis Cluster 會定期更新執行個體。這些更新稱為「維護」。維護作業完全由服務管理，且設計上不會造成停機。
維護作業通常分為以下幾類：
- Memorystore 功能。如要啟動部分功能，Memorystore 需要進行維護更新。
- 作業系統修補程式。我們會持續監控作業系統中新發現的安全漏洞，發現後，我們會修補作業系統，保護您免於新風險。
- 資料庫修補程式。維護作業可能包括 Redis 更新，以改善執行個體的安全性、效能和可靠性特徵，超越 OSS Redis 提供的功能。
設定用戶端應用程式
如要設定用戶端應用程式，在維護期間盡可能維持最佳效能和可用性，請按照下列步驟操作：
- 請按照「Redis 用戶端最佳做法」的指南，使用及設定 OSS Redis 叢集用戶端，確保排定的維護作業不會影響用戶端應用程式。建議您採用用戶端設定，透過定期重新整理內嵌拓撲和輪替背景連線，避免連線重設。
- 在主要和副本節點上執行代表性工作負載時，請使用一系列更新作業 (例如擴大或縮小、副本計數變更) 測試用戶端應用程式，並監控對用戶端的影響。這些更新會測試用戶端上的內嵌拓撲重新整理邏輯、完整同步影響、新節點探索，以及現有節點移除功能。測試可確保 OSS Redis 叢集用戶端設定正確，避免對應用程式造成負面影響。
定期維護
Memorystore for Redis Cluster 採用逐步部署和先建立再銷毀的生命週期策略，避免維護作業造成任何停機影響。如要達到零停機維護目標，請搭配使用 OSS Redis 叢集通訊協定的要求重新導向功能，以及下列 Memorystore 機制：
- 協調式容錯移轉，不會遺失任何資料。
- 順利移除節點，讓用戶端能趕上叢集拓撲更新，且不會影響可用性。
- 叢集的 Private Service Connect 端點不會受到維護作業影響。如要進一步瞭解這些端點，請參閱「叢集端點」。
以下各節所述的服務行為僅適用於排定的維護作業。如要瞭解硬體故障等非預期事件的影響，請參閱「非預期容錯移轉期間的用戶端行為」。
逐步部署策略
系統會逐步擴大 Memorystore for Redis Cluster 維護部署作業的範圍，並以適當的速率執行作業，以便及早偵測到故障，進而減輕影響並確保穩定性。烘烤時間 (套用及監控更新的時間，之後才會視為成功並繼續進行) 會整合至服務規模的 Memorystore 叢集機群。此外，烘烤時間會整合至區域 (多個容錯網域) 的叢集內，以減少影響範圍 (如有)。
對於設定為高可用性的叢集，系統一次最多只會更新一個容錯網域/區域，確保叢集分片 (包括主要和副本) 在更新期間維持高可用性。此外，一次只會更新少數 Redis 節點。更新作業會使用「先建立再刪除」的生命週期機制，盡量確保叢集穩定性。更新含有大量分片的叢集時，這項策略的優點最為顯著。在任何時間點，只將更新套用至整體使用者鍵空間的一小部分，可確保資料可用性達到最高水準。
先建立再銷毀的生命週期策略
Redis 叢集有多個分片。每個分片都有一個主要節點，以及零或多個副本節點。Memorystore 會使用下列程序，更新分片中任何現有的主要或副本 Redis 節點：
- Memorystore for Redis Cluster 會先在分片中新增一個完全採用最新軟體更新的副本，為確保在發生非預期的啟動失敗時，仍能保留佈建的容量，Memorystore 會建立全新的節點，而不是更新現有節點。
- 如果待更新分片中的節點是主要節點，系統會先將其轉換為副本，再使用協調式容錯移轉移除。
- 接著，Memorystore 會移除使用舊版軟體的副本。
- 叢集中的每個節點都會重複執行這個程序。
與一般就地更新的滾動式部署作業相比，先建立再刪除策略有助於保留叢集的佈建容量，但會導致用戶端應用程式的可用性中斷 (有時還會遺失資料)。對於沒有副本的分片，Memorystore for Redis Cluster 仍會先佈建新的副本、協調容錯移轉，最後取代分片的現有主要節點。
步驟 1：新增 Redis 副本
建立前先刪除機制的第一步，是使用完整同步 OSS Redis 機制新增具備最新軟體的副本節點，將資料從主要節點複製到副本節點。方法是分叉子程序，並利用無磁碟複製功能啟動副本。
如要充分運用叢集的水平擴充架構，建議您佈建更多分片，以縮減節點內的鍵空間大小。每個節點的資料集越小，完整同步作業對分叉延遲的影響就越小。還能加快節點間的資料複製速度。
步驟 2：協調主要容錯移轉
如果需要更新的 Redis 節點是主要節點，Memorystore 會先對新加入的副本節點執行協調式容錯移轉，然後繼續移除節點。在協調式容錯移轉期間，用戶端和 Redis 節點會共同運作，並使用下列策略來避免應用程式停機：
- 主要節點會暫時封鎖傳入的用戶端要求，確保現有副本與主要節點完全同步。
- 備用資源完成選舉程序，接管主要角色。
- 先前的主要節點 (現在是副本) 會解除封鎖現有要求，並使用 OSS Redis 叢集通訊協定將要求重新導向至新選出的主要節點。傳送至先前副本節點的任何新要求，都會繼續重新導向至新的主要節點。
- 與 Redis 叢集相容的用戶端會重新整理記憶體內拓撲。並學習新的主要端點位址，不再需要重新導向。
協調式容錯移轉通常只需要幾十毫秒。不過，叢集總大小可能會增加容錯移轉延遲時間。同樣地，待排清至副本的傳輸中資料也可能遺失。叢集大小可能會影響主要節點的聚合，進而影響選取新主要節點的決策。
步驟 3：移除 Redis 副本
建立前先刪除機制最後一步，是移除舊版軟體上的副本節點。如果節點突然移除，用戶端應用程式會受到影響，因為用戶端會快取端點資訊和叢集拓撲。Memorystore for Redis Cluster 移除 Redis 副本時會採取正常關機程序，讓用戶端應用程式在節點強制關機前重新整理拓撲。拓撲會經過自訂，讓用戶瞭解新的副本。拓撲也會在移除副本前忘記要移除的副本。
執行舊版軟體的副本節點會保留一段時間 (通常是幾分鐘)，並開始將傳入的讀取要求重新導向至分片的主要節點。這項功能可讓 OSS Redis 叢集用戶端重新整理叢集拓撲，並瞭解新的副本端點。如果用戶端在排空期過後嘗試連線至已移除的節點，嘗試會失敗，進而觸發叢集用戶端上的叢集拓撲重新整理，以便瞭解副本變更。叢集拓撲的新重新整理作業不會看到要移除的副本節點。
維護設定
有了 Memorystore，您就能自訂維護時間表，配合應用程式需求並盡量減少中斷。只要為叢集設定維護期間，即可完成這項操作。
維護期間是針對每個 Memorystore 叢集設定，並提供下列設定選項：
- 星期幾。指定維護作業的日期。
- 開始時間 (小時)。維護作業開始的小時。
維護期間為 1 小時。請注意，在某些情況下，維護作業可能會超出所選時間範圍。
為叢集執行個體設定維護期間後，系統就會根據維護期間的偏好設定，排定日後的自動維護作業。
預設維護期間
如未設定維護期間，Memorystore 會根據叢集的時區，在下列其中一個時間範圍內更新叢集：
平日時段 (週一至週五)。晚上 10 點至凌晨 6 點
週末時段。週五晚上 10 點至週一早上 6 點
維護範例
身為零售商購物車服務的管理開發人員，您有責任監督生產環境，包括 Memorystore for Redis Cluster 執行個體。為確保維護期間的效能不受影響，請盡量在叢集流量最少的時段安排維護作業，通常是週日午夜前後。
在這種情況下，您可以將實際工作環境叢集的維護期間設為：
- 星期幾。星期日。
- 開始時間 (小時)。凌晨 1 點。
即將進行的維護作業通知
為確保您隨時掌握叢集維護事件的最新資訊，您可以設定電子郵件通知，在預定維護時間前至少一週收到通知。這類通知的主旨行會顯示「"Upcoming maintenance for your Cloud Memorystore instance [your-cluster-name]"」。
叢集開始維護時，系統也會傳送通知。電子郵件主旨為「"Maintenance
is undergoing for your Cloud Memorystore instance [your-cluster-name]"」。
維護完成後，系統會傳送完成通知。電子郵件標題為「"Completed Maintenance
for your Cloud Memorystore instance [your-cluster-name]"」。
如果 Memorystore 重新安排維護作業，您會收到電子郵件，通知您維護作業已取消。這封電子郵件的主旨行會是「"Canceled maintenance for your Cloud Memorystore instance [your-cluster-name]"」。
你必須選擇接收這類維護通知。如要訂閱維護通知，請按照下列步驟操作：
如要接收 Memorystore 的維護通知，請務必在執行個體排定的維護更新前至少一週，完成上述步驟。否則系統就沒有足夠時間通知你即將進行維護。
系統會將通知寄到與你 Google 帳戶連結的電子郵件地址。您無法設定自訂電子郵件別名 (例如團隊電子郵件別名)。目前我們不支援將通知傳送至其他電子郵件地址。
訂閱維護通知後，您會在指定專案中，收到所有排定維護作業的 Memorystore 叢集警報。訂閱後，您會收到各個叢集的個別通知。
如需如何找出排定維護作業的操作說明，請參閱「找出排定維護作業」。
重新安排維護時間
如果叢集已設定維護期間，本節將提供重新排定維護作業的指南。舉例來說，如果預計在目前的維護期間推出新服務，您可能會想將維護期間延後到推出幾天後。
在原定時間的兩週內，您可以隨意重新安排維護時間。重新安排時間時，你可以選擇下列任一選項：
- 立即更新。您不必等待排定的維護時段，可以立即將更新套用至叢集。
- 自訂日期和時間。這樣一來，您就能在原定維護時間的兩週內，選擇任何特定時間。
重新安排維護時間時，請注意下列限制：
- 如果距離目前排定的維護時間不到一小時，您就無法重新安排維護時間。
- 重新安排時間後，系統會傳送電子郵件，確認取消先前的維護作業，並傳送新的維護作業通知，內含更新後的排程。
如需重新安排維護時間的操作說明，請參閱「重新安排維護時間」一文。
常見問題
以下是 Memorystore for Redis Cluster 維護政策的常見問題：
如何得知叢集排定的維護時間？
建議您訂閱通知並設定維護期，瞭解執行個體何時排定維護作業。您也可以使用「尋找排定的維護作業」手動檢查，看看回應中是否已設定 maintenance_schedule 欄位。
我何時會收到即將進行維護作業的通知？
如果您已訂閱維護通知並設定維護時間範圍，系統會在維護事件發生前至少 1 週，透過電子郵件通知您。
我可以延後維護多久？
為叢集排定維護作業後，您可以立即開始更新執行個體，或將更新作業延後最多 2 週 (從原先排定的維護時間算起)。舉例來說，如果維護作業預定於 10 月 11 日晚上 11:15 進行，您可以延期至 10 月 25 日晚上 11:15。如果未採取行動，系統會在排定的時間執行維護作業。
詳情請參閱「重新安排維護時間」。
為確保維護更新順利進行，應遵循哪些最佳做法？
為確保維護更新作業順利進行，建議您採取下列行動：
- 按照操作說明設定用戶端應用程式
- 您應設定維護期間，確保系統不會在 Redis 使用高峰時段進行維護。
- 您應選擇接收維護通知，這樣系統會在為執行個體安排維護更新時，提前至少七天透過電子郵件通知您。
- 如果應用程式使用時間沒有影響較小或沒有影響的時段，建議使用服務預設的逐步推出功能，其中已納入最佳做法。詳情請參閱「定期維護」一文。
何時應立即套用維護作業？
其中一個適用情境是在測試叢集上立即套用維護更新，瞭解對應用程式的影響。這樣您就能觀察維護作業的影響，並視需要/允許延後實際叢集的維護作業。
如果目前時間適合叢集，且您預期叢集未來會出現高負載，也可以立即排定維護作業。
維護更新是否一律會在維護期間內完成？
更新會在您指定的維護期間內開始。更新通常會在時間範圍內完成，但我們無法保證。
我可以選擇不進行維護作業，或是先為特定叢集安排維護作業嗎？
否，您無法選擇不進行維護，也無法控制叢集的維護順序。 不過，收到首次維護通知後，您可以重新安排維護時間，最多延後 2 週。
後續步驟
- 查看管理 Redis 叢集維護期間所需的權限。