Amazon ElastiCache 受管維護和服務更新說明頁面

問：什麼是 Amazon ElastiCache 中的服務更新？

服務更新是 Amazon ElastiCache 中的一項功能，讓您可以自行決定套用某些服務更新。這些更新可以是以下類型：安全修補程式或次要軟體更新。這些更新有助於增強叢集的安全性、可靠性和操作效能。

這些服務更新的價值在於，您可以控制何時套用更新 (例如，當發生重要業務事件，需要 ElastiCache 叢集具有全年無休可用性時，可以延遲套用服務更新)。

有關每項服務更新的詳細資訊，請參閱「更新描述」屬性的值。 

問：如何獲得有關可用 ElastiCache 服務更新的通知？

當有 Memcached 或 Redis 叢集適用的服務更新時，我們會透過多種管道通知您，包括 Amazon ElastiCache 主控台、電子郵件、Amazon Simple Notification Service (SNS)、AWS Personal Health Dashboard 和 Amazon CloudWatch Events。

問：在維護時段套用的更新與服務更新有何不同？

透過我們的持續受管維護提供的更新與服務更新提供的更新是分開的。透過持續受管維護套用的更新直接在維護時段排程，無須您採取任何動作。服務更新則是定時的，可讓您控制何時透過「建議按日期套用」來套用更新。若屆時仍未套用更新，則 ElastiCache 可能會在維護時段排程這些更新。

問︰如何確定是否應套用可用的服務更新？

若您的 ElastiCache Redis 叢集正在參與 HIPAA、PCI 或 FedRAMP 合規計劃，則您必須透過其中的「建議按日期套用」，來套用服務更新，以便保持合規。如需詳細資訊，請參閱合規的自助服務安全更新。

若是其他叢集，我們建議您根據業務節奏套用服務更新。即使您無法透過其「建議按日期套用」來套用服務更新，也可以在其「更新到期日期」之前套用。但是，「更新到期日期」可能隨時變更，具體取決於新更新的可用性。

問：將服務更新套用於 ElastiCache for Redis 叢集有什麼影響？ 我會遺失資料或中斷與叢集的連線嗎？

當您或 Amazon ElastiCache 將服務更新套用至一個或多個 Redis 叢集時，更新會在每個碎片內一次套用至不超過一個節點，直到全部所選叢集完成更新。更新的節點幾乎不會有停機時間，而剩餘的 Redis 叢集會繼續提供流量。

• 叢集組態不會有任何變化。
• 您會看到 CloudWatch 指標出現延遲，這些延遲會盡快趕上。

服務更新會透過節點替換以與「持續的受管維護更新」相同的方式套用。有關更新如何套用以及如何準備應用程式以將影響最小化的詳細資訊，請參閱本頁持續的受管維護更新部分中的以下問題。

• 節點替換對我的應用程式有何影響？
  
• 若要有順暢的替換體驗並將資料遺失的機率降到最低，應遵循何種最佳實務？
• 我應該遵循哪些用戶端組態最佳實務，最大限度地減少維護期間的應用程式中斷狀況？
  

問：是否存在與套用更新至 ElastiCache for Memcached 叢集相關聯的停機時間？

是，該節點將被新的空節點取代。快取內容將不再存在並重新開始。

問：我是否可以選擇退出服務更新？

您可以透過驗證「到期日後自動更新」屬性的值來判斷是否可以選擇退出服務更新。如果服務更新的「到期日後自動更新」屬性值為「no」，則可以選擇退出此服務更新。然而，如果服務更新的「到期日期之後自動更新」屬性的值為「是」且「建議按日期套用」時間已過，ElastiCache 會自動在即將來到的維護時段期間將服務更新排程至任何其餘的叢集。此自動服務更新將在「更新到期日」之前排定，並且您將在更新前一週收到含有預定時間的通知。即使可以選擇退出，我們仍強烈建議套用安全性更新。  如果您選擇在維護期間之前將服務更新套用於其餘叢集，則 ElastiCache 不會在維護時段期間重新套用服務更新。

問：為什麼在維護時段期間 ElastiCache 無法直接套用服務更新？

服務更新的目的是讓您可以靈活選擇何時套用它們。對於不參與 ElastiCache 支援的合規性計劃的叢集，可以選擇不套用這些更新，或者選擇全年不使用這些更新。僅在服務更新「到期日期之後自動更新」屬性的值為「否」時才會如此。如需詳細資訊，請參閱我是否可以選擇退出服務更新？

問：我是否可以使用服務更新，來選擇退出 Amazon ElastiCache 服務維護並自行套用可用的更新？

否，服務更新與叢集維護時段期間 Amazon ElastiCache 直接套用的持續受管維護更新互斥。

問：所有服務更新屬性清單在哪？

屬性及其描述的完整清單在套用自助服務更新中提供。

問：是否所有服務更新都具有相同的時間表？

為幫助確定多長時間套用可用的服務更新，您可以參考「嚴重性」服務更新屬性，該屬性具有以下值 (按優先級排序)：

1. 關鍵：建議立即套用 (在 14 天或更短時間內)
2. 重要：建議在您業務流程允許的情況下盡快套用 (30 天或更短時間內)
3. 中：建議在 60 天或更短時間內套用
4. 低：建議在 90 天或更短時間內套用

如需詳細資訊，請參閱我們的公共文件 – 套用更新。

問：服務更新多久發佈一次？

發佈計劃取決於服務更新的重要性。

問：什麼是「符合服務更新 SLA」屬性？

此屬性反映您的叢集是否透過「推薦按日期套用」進行更新。若在「建議按日期套用」之後套用服務更新，則屬性「符合服務更新 SLA」將被設定為「否」。

該資訊與參與 HIPAA、PCI 和 FedRAMP 合規性計劃的 Amazon ElastiCache Redis 叢集相關。如需詳細資訊，請參閱合規的自助服務安全更新。

問：若我錯過一項或多項服務更新，以後是否可以套用這些更新？

是。除非服務更新「說明」屬性中另有說明，否則服務更新始終為累積：若您在「更新到期日期」前錯過套用這些更新，則它們將包含在下一次服務更新中。類型為「安全性」的服務更新屬於此累積類別。

問：我是否可以選擇將服務更新套用於 ElastiCache 叢集中的特定節點？

否，服務更新在叢集級別套用。若取消正在進行的更新，則叢集可能會更新某些節點，而某些節點未更新。在這種情況下，叢集將繼續顯示在要套用服務更新的叢集清單中。叢集會繼續正常執行。

問：為什麼即使我沒有套用服務更新，我的 ElastiCache 叢集中的一個或多個節點的更新狀態也從「未套用」變為「完成」？

在兩種情況下可能會發生這種情況：

(a) 若錯過套用可選的服務更新，並且該更新現在處於「到期」狀態。因此，參與合規性計劃的叢集必須始終套用所有服務更新。
(b) 若您的節點由於任何其他原因而被取代，例如計劃中的維護事件或節點容錯移轉，Amazon ElastiCache 將為新節點提供包含最新服務更新的節點。

在這兩種情況下，叢集都會繼續正常執行。

問：若我有需要套用到期服務更新的節點該怎麼辦？ 我是否應等待下一次服務更新？

新節點包含所有適用的服務更新，因此您可以手動取代尚未更新的現有節點以獲取最新更新。

問：服務更新是否針對特定引擎？

是。服務更新可能僅適用於 Redis，僅適用於 Memcached，或者適用於 Redis 和 Memcached。您可以查找「引擎」和「引擎版本」服務更新屬性，以確定每次更新的範圍。

問：是否可將排定的服務更新變更到更適當的時間？ 如果我變更維護時段，排定的更新會怎樣？

是，您可以變更維護時段，推遲服務更新。如果排定的日期符合叢集的維護時段，則排定的更新將僅套用至叢集。一旦變更維護時段，且排定的日期已過，服務更新將在未來幾週重新排程至新指定的時段。您將在新日期到來的前一週收到新的通知。

AWS 上的安全是共同的責任。強烈建議您盡早套用更新。

問：為什麼我會收到同個叢集的多個更新通知？ 我是否需要全部套用？

您的叢集可能屬於不同服務更新的一部分。大多數更新不會要求您分開套用。套用一個更新至您的叢集會在任何適用的時候將其他更新標記為已完成。如果狀態未自動變更為「已完成」，則您可能需要將多個更新分開套用至同一叢集。

問：在「推薦的套用日期」後排定和套用服務更新會怎樣？

如果「到期日期後自動更新」屬性的值為「是」，則 ElastiCache 會在「推薦的套用日期」之後針對剩餘叢集排程服務更新。 更新將排定在叢集的維護時段，在更新套用之前，您會在排定日期的前一週收到新的通知。

排定的服務更新會以與「持續的受管維護更新」相同的方式套用至叢集。 有關如何套用更新、如何變更排定的更新，以及如何為針對排定的更新準備應用程式以將影響最小化的詳細資訊，請參閱以下章節。

問：如果服務更新無法在單一維護時段內套用至整個叢集，會怎樣？

為了保持叢集的穩定性，ElastiCache 會在一個碎片內一次僅套用至一個節點。如果服務更新無法在單一維護時段內套用至整個叢集，則將排定為在後續維護時段中繼續。您將在下個排定日期收到新的通知，並作出相應準備。

問：我可以復原服務更新嗎？

一旦更新開始，客戶便無法復原服務更新。如果在套用服務更新後發現問題，請聯絡 AWS Support 團隊。

問：什麼是持續的受管維護更新？

這些更新是強制性的，可以直接在維護時段套用，而無須您採取任何動作。這些更新與服務更新提供的更新是分開的。

問：節點取代需要花費多長時間？

取代通常可在幾秒內完成。某些執行個體組態和流量模式可能需要較長的時間替換。例如，Redis 主要節點可能沒有足夠的可用記憶體，也可能發生寫入流量過高的情況。如果從這種主要節點同步空白複本，主要節點可能會在嘗試處理內送寫入和同步複本時發生記憶體不足的情形。在這種情況下，主節點會中斷與複本的連線，然後重新啟動同步程序。而且可能需要嘗試很多次才能順利同步複本。如果內送寫入流量持續維持很高的情況，也可能永遠無法順利同步複本。

Memcached 節點不需要同步，因此，無論節點大小如何，都可以更快完成替換。

問：節點替換對我的應用程式有何影響？

對於 Redis 節點，替換程序旨在盡全力保留您的現有資料，且需要成功完成 Redis 複寫。對於單一節點 Redis 叢集，ElastiCache 會動態產生複本、複寫資料，然後容錯移轉至該複本。對於包含多個節點的複寫群組，ElastiCache 會替換現有的複本，並將資料從主複本同步到新的複本。如果啟用異地同步備份與自動容錯移轉，替換主複本會觸發容錯移轉到僅供讀取複本。對於設定成使用 Redis 叢集用戶端的 Redis 叢集組態，以及啟用自動容錯移轉的非叢集組態，計劃的節點替換會在叢集處理傳入寫入請求時完成。如果停用異地同步備份，ElastiCache 會替換主複本，然後從僅供讀取複本同步資料。在此期間，主節點無法使用，導致寫入中斷時間更長。

對於 Memcached 節點，替換程序會啟動空的新節點，並終止目前的節點。新的節點在切換期間將暫時無法使用。切換完成後，在空的新節點填入快取資料時，應用程式的效能可能會降低。

問：若要有順暢的替換體驗並將資料遺失的機率降到最低，應遵循何種最佳實務？

對於 Redis 節點，替換程序旨在盡全力保留您的現有資料，且需要成功完成 Redis 複寫。我們儘量一次僅從相同的叢集中替換可讓叢集保持穩定的節點數量。您可在不同的可用區域佈建主複本和僅供讀取複本。在這種情況下，節點替換後，將會從不同可用區域的對等節點同步資料。我們還建議您將 Redis 引擎版本升級至 5.0.6 或更高版本，因為這些引擎版本提高了穩定性，且可讓您的叢集在修補活動期間 (如果已啟用自動容錯移轉) 連續服務傳入的寫入請求。最後，如果您的組態僅包括每個碎片一個主複本和一個單一複本，建議在修補之前新增其他複本。這將防止在修補過程中降低可用性和風險。對於單一節點 Redis 叢集，建議您為 Redis 提供足夠的記憶體，如這裡所述。對於包含多個節點的 Redis 複寫群組，也建議您將替換程序排在低內送寫入流量期間進行。

對於 Memcached 節點，將您的維護時段安排在內送寫入流量較低的時間、測試應用程式的容錯移轉功能，以及使用 ElastiCache 提供的「更加智慧」用戶端。您無法避免資料遺失，因為 Memcached 只將資料放在記憶體中。

問：我應該遵循哪些用戶端組態最佳實務，最大限度地減少維護期間的應用程式中斷狀況？

對於 Redis，叢集模式組態在受管或非受管操作期間具有最佳可用性，而且始終建議使用支援叢集模式的用戶端連接到叢集探索端點。對於停用的叢集模式，建議一律在所有寫入操作使用主端點。複本節點的各個節點端點可用於所有讀取操作。如果叢集啟用自動容錯轉移，則主節點可能會變更，因此應用程式應確認節點的角色並更新所有讀取端點，確保不會對主節點造成重大負載。停用自動容錯移轉後，節點的角色不會變更，但與啟用自動容錯移轉的叢集相比，受管或非受管操作的停機時間會更長。避免僅將讀取請求導向僅供讀取複本。如果將用戶端設定成為僅將讀取請求導至僅供讀取複本，請確保至少有兩個僅供讀取複本，避免維護期間發生任何讀取中斷。

問：如何自行管理節點替換？

建議您在排定的維護時段內，由 ElastiCache 為您管理節點替換程序。建立 ElastiCache 叢集時，您可以透過每週維護時段指定偏好的替換時間。若要將維護時段變更為之後更方便的時間，可以使用 ModifyCacheCluster API，也可以在 ElastiCache 管理主控台按一下 Modify。

若您選擇自行管理替換，可依照使用案例和叢集組態採取不同的動作：

• 變更維護時段。
• 使用備份和還原程序重新啟動 Redis 執行個體。
• 若您的 Redis 叢集組態停用叢集模式

o 替換僅供讀取複本 (停用叢集模式) – 在 Redis 複寫群組手動替換僅供讀取複本的程序。
o 替換主要節點 (停用叢集模式) – 在 Redis 複寫群組手動替換主要節點的程序。
o 替換獨立節點 (停用叢集模式) – 替換獨立 Redis 節點的兩種不同程序。

• 若您的 Redis 叢集組態啟用叢集模式

o 使用一或多個碎片替換叢集中的節點 – 若要替換節點，您可以使用備份與恢復，或者擴展後再縮減。

如需這些所有選項的詳細說明，請參閱安排節點替換時可採取的動作頁面。

若是 Memcached，只要刪除和重新建立叢集即可。完成替換之後，您的執行個體應該不會再有任何相關聯的排程事件。

問：如何知道有關即將執行的排程替換資訊？

若要接收通知，您可以針對重大事件，如排程的取代事件，設定 Amazon SNS 通知。這可透過「事件」區段下的 ElastiCache 管理主控台，或使用 describe-events API 來檢查即將發生的 ElastiCache：NodeReplacementScheduled 事件來實現。

如需設定 SNS 通知，請使用這裡提供的資訊。

問：是否可將排定的維護變更到更適當的時間？

是，您可以變更叢集的維護時段。若要將維護時段變更為之後更方便的時間，可以使用 API (ModifyCacheCluster 或 ModifyReplicationGroup)，也可以在 ElastiCache 管理主控台按一下 Modify。

變更維護時段之後，ElastiCache 服務就會在新指定的時段安排節點維護。請參閱以下範例，了解變更如何生效。

例如，

假設現在是 11 月 9 日星期四 15:00，下一個維護時段是 11 月 10 日星期五 17:00。以下是三種案例及其結果：

• 您將維護時段變更為星期五 16:00 (現在的日期時間之後、下一個排定的維護時段之前)。節點將於 11 月 10 日星期五 16:00 進行替換。
• 您將維護時段變更為星期六 16:00 (現在的日期時間之後、下一個排定的維護時段之後)。節點將於 11 月 11 日星期六 16:00 進行替換。
• 您將維護時段變更為星期三 16:00 (早於這星期中現在的日期時間)。節點將於下一個星期三 11 月 15 日 16:00 進行替換。

問：為什麼要進行這些節點替換？

需要進行這些替換，才能在基礎主機套用強制軟體更新。這些更新有助於強化我們的安全、可靠性和操作效能。

問：這些替換是否會同時影響多個可用區域中的節點？

根據叢集組態，我們可能從相同叢集替換多個節點，但會保持叢集的穩定。如果是 Redis 碎片叢集，我們盡量不會一次從相同碎片中替換多個節點。此外，我們盡量不會跨所有碎片替換叢集中的大部分主節點。
至於非碎片叢集，我們會嘗試盡可能在維護時段內錯開這些節點替換，以持續保持叢集的穩定。

問：不同區域中不同叢集的節點是否可以同時替換？

是，如果這些叢集的維護時段設定在相同的時間，則這些節點可以同時替換。