

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

# 在 MSK 佈建叢集上修補
<a name="patching-impact"></a>

Amazon MSK 會定期更新叢集中代理程式上的軟體。維護包括計劃的更新或非計劃的修復。計劃維護包括作業系統更新、安全性更新，以及維護叢集運作狀態、安全性和效能所需的其他軟體更新。我們會執行意外維護，以解決突然的基礎設施降級。我們會對 Standard 和 Express 代理程式執行維護，但體驗不同。

## 標準代理程式的修補
<a name="patching-standard-brokers"></a>

如果您遵循[最佳實務](bestpractices.md)，標準代理程式的更新不會影響您應用程式的寫入和讀取。

Amazon MSK 使用軟體的滾動更新來維持叢集的高可用性。在此過程中，代理程式一次重新啟動一個，Kafka 會自動將領導力移至另一個線上代理程式。當您在 中 AWS 管理主控台 或透過 `DescribeClusterOperation`和 `ListClusterOperations` APIs 檢視叢集操作時，這些維護操作會以 的操作類型顯示`SECURITY_PATCHING`。Kafka 用戶端具有內建機制，可自動偵測分割區領導層的變更，並繼續將資料寫入 MSK 叢集並讀取。隨時遵循 [Apache Kafka 用戶端的最佳實務](bestpractices-kafka-client.md) 可順暢操作叢集，包括修補期間。

在代理程式離線後，在您的用戶端上看到暫時性中斷連線錯誤是正常的。您也將觀察 p99 讀取和寫入延遲 （通常為高毫秒，最多 \$12 秒） 中的短暫時段 （最多 2 分鐘，通常較少）。這些峰值是預期的，由用戶端重新連線至新的領導者代理程式所造成；這不會影響您的生產或消耗，並在重新連線後解決。如需詳細資訊，請參閱[中介裝置離線和用戶端容錯移轉](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html)。

您也會觀察到指標 的增加`UnderReplicatedPartitions`，因為已關閉的代理程式上的分割區不會再複寫資料。這不會影響應用程式寫入和讀取，因為在其他代理程式上託管的這些分割區複本現在正在處理請求。

軟體更新之後，當代理程式重新上線時，它需要「追上」離線時產生的訊息。在追趕期間，您可能會發現磁碟區輸送量和 CPU 的使用量增加。如果您在代理程式上有足夠的 CPU、記憶體、網路和磁碟區資源，這些應該不會影響寫入和讀取至叢集。

## 針對 Express 代理程式的修補
<a name="patching-express-brokers"></a>

Express 代理程式沒有維護時段。Amazon MSK 會以時間分佈的方式持續自動更新叢集，這表示您可以在該月偶爾重新啟動單一代理程式。這可確保您不需要針對整個叢集的一次性維護時段制定任何計劃或調整。一如往常，流量在代理程式重新開機期間將保持不中斷，因為領導層將變更為會繼續提供請求的其他代理程式。當您在 中 AWS 管理主控台 或透過 `DescribeClusterOperation`和 `ListClusterOperations` APIs 檢視叢集操作時，這些維護操作會以 的操作類型顯示`BROKER_UPDATE`。

快速代理程式具有最佳實務設定和護欄，讓您的叢集能夠彈性地載入在維護期間可能發生的變更。Amazon MSK 會在您的 Express 代理程式上設定輸送量配額，以減輕叢集超載的影響，這可能會在代理程式重新啟動期間導致問題。當您使用 Express 代理程式時，這些改進功能不需要預先通知、規劃和維護時段。

快速代理程式一律以三種方式複寫資料，讓您的用戶端在重新啟動期間自動容錯移轉。您不需要擔心因為複寫因素設為 1 或 2 而無法使用主題。此外，追上重新啟動的 Express 代理程式比標準代理程式更快。Express 代理程式的修補速度越快，表示針對叢集排程的任何控制平面活動，規劃中斷越少。

與所有 Apache Kafka 應用程式一樣，用戶端連線至 Express 代理程式仍有共用的用戶端-伺服器合約。設定您的用戶端來處理代理程式之間的領導容錯移轉仍然至關重要。隨時遵循 [Apache Kafka 用戶端的最佳實務](bestpractices-kafka-client.md)來順暢操作叢集，包括在修補期間。在代理程式重新啟動後，[在您的用戶端上看到暫時性中斷連線錯誤](troubleshooting-offlinebroker-clientfailover.md)是正常的。這不會影響您的生產和使用，因為跟隨中介裝置將接管分割區領導。您的 Apache Kafka 用戶端會自動容錯移轉，並開始傳送請求給新的領導者代理程式。