

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

# 對 Amazon MSK 叢集進行故障診斷
<a name="troubleshooting"></a>

下列資訊可協助您對 Amazon MSK 叢集可能發生的問題進行疑難排解。您也可以將您的問題張貼到 [AWS re:Post](https://repost.aws/)。如需對 Amazon MSK Replicator 進行故障診斷，請參閱 [MSK Replicator 故障診斷](msk-replicator-troubleshooting.md)。

**Topics**
+ [磁碟區取代因複寫過載而導致磁碟飽和](#replication-overload-disk-saturation)
+ [取用者群組停滯在 `PreparingRebalance` 狀態](#consumer-group-rebalance)
+ [將代理程式日誌傳送至 Amazon CloudWatch Logs 時出錯](#cw-broker-logs-error)
+ [沒有預設安全群組](#troubleshooting-shared-vpc)
+ [叢集顯示停滯在 CREATING 狀態](#troubleshooting-cluster-stuck)
+ [叢集的狀態從 CREATING 到 FAILED](#troubleshooting-cluster-failed)
+ [叢集狀態為 ACTIVE，但生產者無法傳送資料或取用者無法接收資料](#troubleshooting-nodata)
+ [AWS CLI 無法辨識 Amazon MSK](#troubleshooting-nocli)
+ [分割區離線或複本不同步](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [磁碟空間不足](#troubleshooting-lowdiskspace)
+ [記憶體不足](#troubleshooting-lowmemory)
+ [生產者取得 NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [複寫不足道分區 (URP) 數量大於零](#troubleshooting-urp)
+ [叢集具有名為 \$1\$1amazon\$1msk\$1canary 和 \$1\$1amazon\$1msk\$1canary\$1state 的主題](#amazon_msk_canary)
+ [分區複寫失敗](#partition_replication_fails)
+ [無法存取已開啟公開存取的叢集](#public-access-issues)
+ [無法透過 IPv6 引導存取叢集](#dualstack-issues)
+ [無法從 內部存取叢集 AWS：聯網問題](#networking-trouble)
+ [身分驗證失敗：太多連線](#troubleshoot-too-many-connects)
+ [失敗的身分驗證：工作階段太短](#troubleshoot-session-too-short)
+ [MSK Serverless：叢集建立失敗](#troubleshoot-serverless-create-cluster-failure)
+ [無法在 MSK 組態中更新 KafkaVersionsList](#troubleshoot-kafkaversionslist-cfn-update-failure)

## 磁碟區取代因複寫過載而導致磁碟飽和
<a name="replication-overload-disk-saturation"></a>

在意外磁碟區硬體故障期間，Amazon MSK 可能會將磁碟區取代為新的執行個體。Kafka 透過從叢集中的其他代理程式複寫分割區來重新填入新磁碟區。複寫分割區並趕上之後，它們就符合領導階層和同步內複本 (ISR) 成員資格。

**問題**  
在從磁碟區取代中復原的代理程式中，不同大小的某些分割區可能會先回到線上。這可能有問題，因為這些分割區可以提供來自仍在趕上 （複寫） 其他分割區之相同代理程式的流量。此複寫流量有時可能會使基礎磁碟區輸送量限制飽和，預設情況下為每秒 250 MiB。發生此飽和時，任何已追趕的分割區都會受到影響，導致與追趕分割區共用 ISR 的任何代理程式在叢集間延遲 （而不只是由於遠端 acks 而導致的領導分割區`acks=all`)。此問題在大小變化的分割區數量較大的叢集中更為常見。

**建議**
+ 若要改善複寫 I/O 狀態，請確定[最佳實務執行緒設定](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads)已就緒。
+ 為了降低基礎磁碟區飽和的可能性，請啟用具有較高輸送量的佈建儲存。對於高輸送量複寫案例，建議使用 500 MiB/s 的最低輸送量值，但所需的實際值會因輸送量和使用案例而有所不同。 [為 Amazon MSK 叢集中的標準代理程式佈建儲存輸送量](msk-provision-throughput.md)
+ 若要將複寫壓力降至最低，請降低`num.replica.fetchers`至預設值 `2`。

## 取用者群組停滯在 `PreparingRebalance` 狀態
<a name="consumer-group-rebalance"></a>

如果您的一個或多個取用者群組停滯在永久再平衡狀態，原因可能是 Apache Kafka 問題 [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752)，這會影響到 Apache Kafka 2.3.1 和 2.4.1 版。

若要解決此問題，建議您將叢集升級至 [Amazon MSK 2.4.1.1 錯誤修正版](supported-kafka-versions.md#2.4.1.1)，其中包含此問題的修正程式。如需有關將現有叢集更新至 Amazon MSK 2.4.1.1 錯誤修正版的相關資訊，請參閱[升級 Apache Kafka 版本](version-upgrades.md)。

 在不將叢集升級至 Amazon MSK 2.4.1.1 錯誤修正版的情況下，解決此問題的因應措施是設定 Kafka 用戶端使用[靜態成員通訊協定](#consumer-group-rebalance-static)或是[辨識與重新啟動](#consumer-group-rebalance-reboot)停滯的取用者群組的協調代理程式節點。

### 實施靜態成員通訊協定
<a name="consumer-group-rebalance-static"></a>

若要在您的用戶端實施靜態成員通訊協定，請執行以下操作：

1. 將 [Kafka Consumers](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) 組態的 `group.instance.id` 屬性設定為靜態字串，且其可辨識群組中的取用者。

1. 確保組態的其他執行個體已更新為使用靜態字串。

1. 將變更部署到您的 Kafka 取用者。

如果用戶端組態中的工作階段逾時設定的值足以讓取用者復原，而不過早觸發取用者群組再平衡，則使用靜態成員通訊協定會比較有效。例如，如果您的取用者應用程式可以容忍無法使用 5 分鐘，則工作階段逾時的合理值將是 4 分鐘，而不是 10 秒的預設值。

**注意**  
使用靜態成員通訊協定只會降低遇到此問題的可能性。即使使用靜態成員通訊協定，您仍可能會遇到此問題。

### 重新啟動協調代理程式節點
<a name="consumer-group-rebalance-reboot"></a>

若要重啟協調代理程式節點，請執行下列操作：

1. 使用 `kafka-consumer-groups.sh` 指令辨識群組協調器。

1. 使用 [RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker) API 動作，重新啟動停滯的取用者群組的群組協調器。

## 將代理程式日誌傳送至 Amazon CloudWatch Logs 時出錯
<a name="cw-broker-logs-error"></a>

當您嘗試設定叢集以向 Amazon CloudWatch Logs 傳送代理程式日誌時,可能會出現兩種例外狀況之一。

如果出現 `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` 例外狀況，請再試一次，但請使用開頭為 `/aws/vendedlogs/` 的日誌群組。如需詳細資訊，請參閱[啟用從特定 Amazon Web Services 記錄日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html)。

如果出現 `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` 例外狀況，請在帳戶中選擇現有的 Amazon CloudWatch Logs 政策，然後將下列 JSON 附加其中。

```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```

如果您嘗試將上述 JSON 附加到現有政策，但出現錯誤訊息，其中表示您已經達到所選政策的長度上限，請嘗試將 JSON 附加到另一個 Amazon CloudWatch Logs 政策中。將 JSON 附加至現有政策後，請再試一次，以設定將代理程式日誌傳遞至 Amazon CloudWatch Logs。

## 沒有預設安全群組
<a name="troubleshooting-shared-vpc"></a>

如果您嘗試建立叢集並收到錯誤，指出沒有預設安全群組，可能是因為您正使用與您共用的 VPC。請您的系統管理員授與您描述此 VPC 上安全群組的權限，然後再試一次。如需關於允許此動作的政策範例，請參閱 [Amazon EC2：允許以程式設計方式和主控台中管理與特定 VPC 關聯的 EC2 安全群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html)。

## 叢集顯示停滯在 CREATING 狀態
<a name="troubleshooting-cluster-stuck"></a>

有時叢集建立最多需要 30 分鐘。等候 30 分鐘，然後再次檢查叢集的狀態。

## 叢集的狀態從 CREATING 到 FAILED
<a name="troubleshooting-cluster-failed"></a>

請嘗試再次建立叢集。

## 叢集狀態為 ACTIVE，但生產者無法傳送資料或取用者無法接收資料
<a name="troubleshooting-nodata"></a>
+ 如果叢集建立成功 (叢集狀態為 `ACTIVE`)，但您無法傳送或接收資料，請確定您的生產者和取用者應用程式可以存取叢集。如需詳細資訊，請參閱 [步驟 3：建立用戶端機器](create-client-machine.md) 中的指導。
+ 如果您的生產者和取用者可以存取叢集，但仍然遇到產生和使用數據的問題，原因可能是 [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697)，這會影響 Apache 2.1.0 版本，並可能導致一或多個代理程式死鎖。請考慮遷移到 Apache 卡夫卡 2.2.1，其不受此錯誤影響。如需有關如何遷移的資訊，請參閱 [將 Kafka 工作負載遷移至 Amazon MSK 叢集](migration.md)。

## AWS CLI 無法辨識 Amazon MSK
<a name="troubleshooting-nocli"></a>

如果您 AWS CLI 已安裝 ，但無法辨識 Amazon MSK 命令，請將 升級至 AWS CLI 最新版本。如需如何升級 的詳細說明 AWS CLI，請參閱[安裝 AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)。如需如何使用 AWS CLI 執行 Amazon MSK 命令的資訊，請參閱 [Amazon MSK 主要功能和概念](operations.md)。

## 分割區離線或複本不同步
<a name="troubleshooting-offlinepartition-outofsyncreplicas"></a>

這些可能是磁碟空間不足的徵狀。請參閱 [磁碟空間不足](#troubleshooting-lowdiskspace)。

## 磁碟空間不足
<a name="troubleshooting-lowdiskspace"></a>

請參閱管理磁碟空間中的下列最佳實務：[監控磁碟空間](bestpractices.md#bestpractices-monitor-disk-space) 和 [調整資料保留參數](bestpractices.md#bestpractices-retention-period)。

## 記憶體不足
<a name="troubleshooting-lowmemory"></a>

如果您看到 `MemoryUsed` 指標過高或 `MemoryFree` 不足，這並不表示有問題。Apache Kafka 設計為盡可能地多使用記憶體，並且以最佳方式管理。

## 生產者取得 NotLeaderForPartitionException
<a name="troubleshooting-NotLeaderForPartitionException"></a>

這通常是暫時性錯誤。將生產者的 `retries` 組態參數設定為高於目前的值。

## 複寫不足道分區 (URP) 數量大於零
<a name="troubleshooting-urp"></a>

`UnderReplicatedPartitions` 是重要的監控指標。在狀態良好的 MSK 叢集中，此指標的值為 0。如果它大於零，可能是由於下列原因之一。
+ 如果 `UnderReplicatedPartitions` 是尖峰，問題可能是叢集未以適當的大小佈建，以處理傳入和傳出的流量。請參閱 [標準代理程式的最佳實務](bestpractices.md)。
+ 如果 `UnderReplicatedPartitions` 一直大於 0 (包括在低流量期間)，問題可能是您設定限制性 ACL，不授予主題對代理程式的存取權。若要複寫分割區，必須授權代理程式 READ 和 DESCRIBE 主題。READ 授權預設會授與 DESCRIBE 權限。如需有關設定 ACL 的詳細資訊，請參閱 Apache Kafka 文件中的 [授權和 ACL](https://kafka.apache.org/documentation/#security_authz)。

## 叢集具有名為 \$1\$1amazon\$1msk\$1canary 和 \$1\$1amazon\$1msk\$1canary\$1state 的主題
<a name="amazon_msk_canary"></a>

您可能會看到 MSK 叢集具有名為 `__amazon_msk_canary` 的主題，以及另一個名為 `__amazon_msk_canary_state` 的主題。這些是 Amazon MSK 針對叢集運作狀態和診斷指標建立和使用的內部主題。這些主題的大小可以忽略不計，且無法被刪除。

## 分區複寫失敗
<a name="partition_replication_fails"></a>

請確定您尚未在 CLUSTER\$1ACTIONS 上設定 ACL。

## 無法存取已開啟公開存取的叢集
<a name="public-access-issues"></a>

如果您的叢集已開啟公開存取，但仍無法從網際網路存取，請依照下列步驟執行：

1. 確定叢集安全群組的傳入規則允許您的 IP 地址和叢集的連接埠。如需叢集連接埠號碼的清單，請參閱[連接埠資訊](port-info.md)。同時確保安全群組的傳出規則允許傳出通訊。如需有關安全群組與其傳入、傳出規則的詳細資訊，請參閱《Amazon VPC 使用者指南》中的 [VPC 的安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html)。

1. 確定叢集 VPC 網路 ACL 的傳入規則中，允許您的 IP 地址和叢集的連接埠。與安全群組不同，網路 ACL 是無狀態的。這意味著您必須同時設定傳入和傳出規則。在傳出規則中，允許所有流量 (連接埠範圍：0-65535) 傳送到您的 IP 地址。如需詳細資訊，請參閱《Amazon VPC 使用者指南》中的[新增和刪除規則](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules)。

1. 確定您是使用公開存取 bootstrap-broker 字串來存取叢集。開啟公開存取的 MSK 叢集有兩個不同的引導代理程式字串，一個用於公開存取，另一個用於從 AWS內部存取。如需詳細資訊，請參閱[使用 取得引導代理程式 AWS 管理主控台](get-bootstrap-console.md)。

## 無法透過 IPv6 引導存取叢集
<a name="dualstack-issues"></a>

如果您在使用提供的 IPv6 引導字串連線至叢集時遇到問題，請依照下列步驟執行：

1.  確保您的用戶端已指派 IPv4 和 IPv6 地址。您的用戶端應用程式必須在同時啟用並正確設定 IPv4 和 IPv6 定址的子網路中執行。檢查您的 VPC 是否同時具有 IPv4 CIDR 區塊和相關聯的 IPv6 CIDR 區塊，確認您的子網路同時啟用 IPv4 和 IPv6 地址，並確認 EC2 執行個體或用戶端環境已同時指派 IPv4 和 IPv6 地址。如需詳細資訊，請參閱《Amazon [ VPCs 使用者指南》中的 VPC 和子網路的 IP 定址](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html)。

1.  確保安全群組傳入和傳出規則中存在相關的 IPv6 連接埠。新增傳入規則以允許來自 IPv6 地址之叢集連接埠上的流量，並設定傳出規則以允許 IPv6 流量。如需特定連接埠號碼，請參閱 MSK 文件中的[連接埠資訊](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html)。如果以雙堆疊模式執行，請記得更新 IPv4 和 IPv6 規則。如需有關安全群組與其傳入、傳出規則的詳細資訊，請參閱《Amazon VPC 使用者指南》中的 [VPC 的安全群組](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)。

1.  確保適用於 IPv6 支援的 JVM 屬性組態正確。在您的用戶端應用程式中，將 `java.net.preferIPv6Addresses` 設定為 `true`，將 `java.net.preferIPv4Stack`設定為 `false`。這些設定可以設定為系統屬性或 JVM 引數。在進行這些變更後重新啟動您的應用程式，讓它們生效。

## 無法從 內部存取叢集 AWS：聯網問題
<a name="networking-trouble"></a>

如果您有一個 Apache Kafka 應用程式無法與 MSK 叢集成功通訊，首先執行以下連線測試。

1. 使用 [取得 Amazon MSK 叢集的引導代理程式](msk-get-bootstrap-brokers.md) 中描述的任何方法來取得引導代理程式的地址。

1. 在下面的命令中，使用您在上一步中獲得的代理程式地址之一取代 *bootstrap-broker*。如果叢集設定為使用 TLS 驗證，請將 *port-number* 替換為 9094。如果叢集不使用 TLS 驗證，請將 *port-number* 替換為 9092。從用戶端機器執行命令。

   ```
   telnet bootstrap-broker port-number
   ```

   其中 port-number 為：
   + 如果叢集設定為使用 TLS 身分驗證，則為 9094。
   + 9092 如果叢集未使用 TLS 身分驗證。
   + 如果啟用公有存取，則需要不同的連接埠號碼。

   從用戶端機器執行命令。

1. 對所有引導代理程式重複前面的命令。

如果用戶端機器能夠存取代理程式，這表示沒有連線問題。在這種情況下，執行下列命令來檢查您的 Apache Kafka 用戶端是否已正確設定。若要取得 *bootstrap-brokers*，請使用 [取得 Amazon MSK 叢集的引導代理程式](msk-get-bootstrap-brokers.md) 中描述的任何方法。將 *主題* 替換為您的主題名稱。

```
<path-to-your-kafka-installation>/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```

如果上一個命令成功，這表示您的用戶端已正確設定。如果您仍然無法從應用程式生產和使用，請在應用程式層級偵錯問題。

如果用戶端機器無法存取代理程式，請參閱下列子節以取得以用戶端-機器設定為基礎的指引。

### 同一個 VPC 中的 Amazon EC2 用戶端和 MSK 叢集
<a name="troubleshoot-ec2-client-in-cluster-vpc"></a>

如果用戶端機器與 MSK 叢集在相同的 VPC 中，請確定叢集的安全群組具有的傳入規則可接受來自用戶端機器安全群組的流量。如需設定這些規則的資訊，請參閱[安全群組規則](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules)。如需如何從位於與叢集相同 VPC 中 Amazon EC2 執行個體存取叢集的範例，請參閱[開始使用 Amazon MSK](getting-started.md)。

### 不同 VPC 中的 Amazon EC2 用戶端和 MSK 叢集
<a name="troubleshoot-peering-connection"></a>

如果用戶端機器和叢集位於兩個不同的 VPC 中，請確定下列各項：
+ 兩個 VPC 是對等的。
+ 對等連線的狀態為作用中。
+ 兩個 VPC 的路由表已正確設定。

如需 VPC 對等連線的相關資訊，請參閱 [使用 VPC 對等連線](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html)。

### 內部部署用戶端
<a name="troubleshoot-on-prem-client"></a>

如果現場部署用戶端設定為使用 連線至 MSK 叢集 Site-to-Site VPN，請確定下列事項：
+ VPN 連線狀態為 `UP`。如需如何檢查 VPN 連線狀態的詳細資訊，請參閱[如何檢查 VPN 通道的目前狀態？](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/)。
+ 叢集 VPC 的路由表包含目標具有格式 `Virtual private gateway(vgw-xxxxxxxx)` 的內部部署 CIDR 路由。
+ MSK 叢集的安全群組允許連接埠 2181、連接埠 9092 (如果您的叢集接受純文字流量) 和連接埠 9094 (如果您的叢集接受 TLS 加密的流量) 上的流量。

如需更多 Site-to-Site VPN 故障診斷指引，請參閱[對 Client VPN 進行故障診斷](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html)。

### Direct Connect
<a name="troubleshoot-direct-connect"></a>

如果用戶端使用 Direct Connect，請參閱[故障診斷 Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html)。

如果先前的故障診斷指南無法解決問題，請確定沒有防火牆封鎖網路流量。若要進一步偵錯，請使用類似 `tcpdump` 和 `Wireshark` 的工具來分析流量，並確定流量已到達 MSK 叢集。

## 身分驗證失敗：太多連線
<a name="troubleshoot-too-many-connects"></a>

`Failed authentication ... Too many connects` 錯誤表示代理程式正在自我保護，因為一個或多個 IAM 用戶端太積極嘗試建立連線。若要讓代理程式接受更高的新 IAM 連線速率，您可以增加 [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms) 組態參數值。

若要深入了解每個代理程式新連線的速率限制，請參閱[Amazon MSK 配額](limits.md)頁面。

## 失敗的身分驗證：工作階段太短
<a name="troubleshoot-session-too-short"></a>

當您的用戶端嘗試使用即將過期的 IAM 登入資料連線到叢集時，會發生此`Failed authentication ... Session too short`錯誤。請務必檢查 IAM 登入資料如何重新整理。最有可能的是，憑證被取代的時間太接近工作階段過期，這會導致伺服器端的問題，以及身分驗證失敗。

## MSK Serverless：叢集建立失敗
<a name="troubleshoot-serverless-create-cluster-failure"></a>

如果您嘗試建立 MSK Serverless 叢集，但工作流程失敗，則您可能沒有建立 VPC 端點的許可。允許 `ec2:CreateVpcEndpoint` 動作，確認您的管理員已授予建立 VPC 端點的許可。

如需有關執行所有 Amazon MSK 動作所需許可的完整清單，請參閱 [AWS 受管政策：AmazonMSKFullAccess](security-iam-awsmanpol-AmazonMSKFullAccess.md)。

## 無法在 MSK 組態中更新 KafkaVersionsList
<a name="troubleshoot-kafkaversionslist-cfn-update-failure"></a>

當您更新 [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html) 資源中的 [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist) 屬性時，更新會失敗，並顯示下列錯誤。

```
Resource of type 'AWS::MSK::Configuration' with identifier '<identifierName>' already exists.
```

當您更新 `KafkaVersionsList` 屬性時， 會使用更新的 屬性 AWS CloudFormation 重新建立新的組態，然後再刪除舊的組態。 CloudFormation 堆疊更新失敗，因為新組態使用與現有組態相同的名稱。這類更新需要[資源替換](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement)。若要成功更新 `KafkaVersionsList`，您還必須在相同的操作中更新 [Name](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) 屬性。

此外，如果您的組態與使用 AWS 管理主控台 或 建立的任何叢集連接 AWS CLI，請將以下內容新增至您的組態資源，以防止[失敗的資源刪除嘗試](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted)。

```
UpdateReplacePolicy: Retain
```

更新成功後，請前往 Amazon MSK 主控台並刪除舊組態。如需 MSK 組態的相關資訊，請參閱 [Amazon MSK 佈建組態](msk-configuration.md)。