Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Memecahkan masalah klaster MSK Amazon Anda
Informasi berikut dapat membantu Anda memecahkan masalah yang mungkin Anda miliki dengan kluster MSK Amazon Anda. Anda juga dapat memposting masalah Anda ke [AWS re:Post](https://repost.aws/). Untuk memecahkan masalah Amazon MSK Replicator, lihat. [Memecahkan masalah MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi](#replication-overload-disk-saturation)
+ [Kelompok konsumen terjebak di `PreparingRebalance` negara bagian](#consumer-group-rebalance)
+ [Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Tidak ada grup keamanan default](#troubleshooting-shared-vpc)
+ [Cluster tampak macet dalam status CREATING](#troubleshooting-cluster-stuck)
+ [Status cluster berubah dari CREATING menjadi FAILED](#troubleshooting-cluster-failed)
+ [Status klaster AKTIF tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data](#troubleshooting-nodata)
+ [AWS CLI tidak mengenali Amazon MSK](#troubleshooting-nocli)
+ [Partisi offline atau replika tidak sinkron](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [Ruang disk hampir habis](#troubleshooting-lowdiskspace)
+ [Memori hampir habis](#troubleshooting-lowmemory)
+ [Produser mendapat NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Partisi yang kurang direplikasi (URP) lebih besar dari nol](#troubleshooting-urp)
+ [Cluster memiliki topik yang disebut \$1\$1amazon\$1msk\$1canary dan \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Replikasi partisi gagal](#partition_replication_fails)
+ [Tidak dapat mengakses klaster yang mengaktifkan akses publik](#public-access-issues)
+ [Tidak dapat mengakses cluster melalui IPv6 bootstrap](#dualstack-issues)
+ [Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan](#networking-trouble)
+ [Otentikasi gagal: Terlalu banyak koneksi](#troubleshoot-too-many-connects)
+ [Otentikasi gagal: Sesi terlalu singkat](#troubleshoot-session-too-short)
+ [MSK Tanpa Server: Pembuatan cluster gagal](#troubleshoot-serverless-create-cluster-failure)
+ [Tidak dapat memperbarui KafkaVersionsList dalam konfigurasi MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi
Selama kegagalan perangkat keras volume yang tidak direncanakan, Amazon MSK dapat mengganti volume dengan instance baru. Kafka mengisi kembali volume baru dengan mereplikasi partisi dari broker lain di cluster. Setelah partisi direplikasi dan ditangkap, mereka memenuhi syarat untuk keanggotaan leadership dan in-sync replica (ISR).
**Masalah**
Dalam broker yang pulih dari penggantian volume, beberapa partisi dengan berbagai ukuran dapat kembali online sebelum yang lain. Ini bisa menjadi masalah karena partisi tersebut dapat melayani lalu lintas dari broker yang sama yang masih mengejar (mereplikasi) partisi lain. Lalu lintas replikasi ini terkadang dapat memenuhi batas throughput volume yang mendasarinya, yaitu 250 MiB per detik dalam kasus default. Ketika saturasi ini terjadi, partisi apa pun yang sudah tertangkap akan terpengaruh, menghasilkan latensi di seluruh cluster untuk setiap broker yang berbagi ISR dengan partisi yang tertangkap (bukan hanya partisi pemimpin karena acks jarak jauh). `acks=all` Masalah ini lebih sering terjadi pada cluster yang lebih besar yang memiliki jumlah partisi yang lebih besar yang ukurannya bervariasi.
**Rekomendasi**
+ Untuk memperbaiki I/O postur replikasi, pastikan [pengaturan utas praktik terbaik](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) sudah ada.
+ Untuk mengurangi kemungkinan saturasi volume yang mendasarinya, aktifkan penyimpanan yang disediakan dengan throughput yang lebih tinggi. Nilai throughput min 500 MiB/s direkomendasikan untuk kasus replikasi throughput tinggi, tetapi nilai aktual yang dibutuhkan akan bervariasi dengan throughput dan kasus penggunaan. [Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon](msk-provision-throughput.md).
+ Untuk meminimalkan tekanan replikasi, turunkan `num.replica.fetchers` ke nilai default. `2`
## Kelompok konsumen terjebak di `PreparingRebalance` negara bagian
Jika satu atau lebih grup konsumen Anda terjebak dalam keadaan penyeimbangan kembali terus-menerus, penyebabnya mungkin masalah Apache Kafka [KAFKA-9752, yang memengaruhi Apache Kafka versi 2.3.1](https://issues.apache.org/jira/browse/KAFKA-9752) dan 2.4.1.
Untuk mengatasi masalah ini, kami sarankan Anda meningkatkan klaster Anda ke[Amazon MSK perbaikan bug versi 2.4.1.1](supported-kafka-versions.md#2.4.1.1), yang berisi perbaikan untuk masalah ini. Untuk informasi tentang memperbarui klaster yang ada ke Amazon MSK bug-fix versi 2.4.1.1, lihat. [Tingkatkan versi Apache Kafka](version-upgrades.md)
Solusi untuk menyelesaikan masalah ini tanpa memutakhirkan cluster ke Amazon MSK bug-fix versi 2.4.1.1 adalah dengan mengatur klien Kafka untuk digunakan[Protokol keanggotaan statis](#consumer-group-rebalance-static), atau ke [Identifikasi dan reboot](#consumer-group-rebalance-reboot) node broker koordinasi dari grup konsumen yang macet.
### Menerapkan protokol keanggotaan statis
Untuk menerapkan Protokol Keanggotaan Statis di klien Anda, lakukan hal berikut:
1. Atur `group.instance.id` properti konfigurasi [Konsumen Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) Anda ke string statis yang mengidentifikasi konsumen dalam grup.
1. Pastikan bahwa contoh lain dari konfigurasi diperbarui untuk menggunakan string statis.
1. Terapkan perubahan ke Konsumen Kafka Anda.
Menggunakan Protokol Keanggotaan Statis lebih efektif jika batas waktu sesi dalam konfigurasi klien diatur ke durasi yang memungkinkan konsumen untuk pulih tanpa memicu penyeimbangan ulang grup konsumen sebelum waktunya. Misalnya, jika aplikasi konsumen Anda dapat mentolerir ketidaktersediaan 5 menit, nilai yang wajar untuk batas waktu sesi adalah 4 menit, bukan nilai default 10 detik.
**catatan**
Menggunakan Protokol Keanggotaan Statis hanya mengurangi kemungkinan menghadapi masalah ini. Anda mungkin masih mengalami masalah ini bahkan saat menggunakan Protokol Keanggotaan Statis.
### Mem-boot ulang node broker koordinasi
Untuk me-reboot node broker koordinator, lakukan hal berikut:
1. Identifikasi koordinator grup menggunakan `kafka-consumer-groups.sh` perintah.
1. Mulai ulang koordinator grup grup konsumen yang macet menggunakan tindakan [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API.
## Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs
Saat Anda mencoba menyiapkan klaster untuk mengirim log broker ke Amazon CloudWatch Logs, Anda mungkin mendapatkan salah satu dari dua pengecualian.
Jika Anda mendapatkan `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` pengecualian, coba lagi tetapi gunakan grup log yang dimulai dengan`/aws/vendedlogs/`. Untuk informasi selengkapnya, lihat [Mengaktifkan Logging dari Amazon Web Services tertentu](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Jika Anda mendapatkan `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` pengecualian, pilih kebijakan CloudWatch Log Amazon yang ada di akun Anda, dan tambahkan JSON berikut ke dalamnya.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Jika Anda mencoba menambahkan JSON di atas ke kebijakan yang ada tetapi mendapatkan kesalahan yang mengatakan Anda telah mencapai panjang maksimum untuk kebijakan yang Anda pilih, coba tambahkan JSON ke salah satu kebijakan Amazon Logs Anda yang lain. CloudWatch Setelah Anda menambahkan JSON ke kebijakan yang ada, coba sekali lagi untuk menyiapkan pengiriman broker-log ke Amazon Logs. CloudWatch
## Tidak ada grup keamanan default
Jika Anda mencoba membuat klaster dan mendapatkan kesalahan yang menunjukkan bahwa tidak ada grup keamanan default, itu mungkin karena Anda menggunakan VPC yang dibagikan dengan Anda. Minta administrator Anda untuk memberi Anda izin untuk mendeskripsikan grup keamanan di VPC ini dan coba lagi. Untuk contoh kebijakan yang mengizinkan tindakan ini, lihat [Amazon EC2: Mengizinkan Mengelola Grup Keamanan EC2 yang Terkait Dengan VPC Tertentu, Secara Terprogram,](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) dan di Konsol.
## Cluster tampak macet dalam status CREATING
Terkadang pembuatan cluster bisa memakan waktu hingga 30 menit. Tunggu selama 30 menit dan periksa status cluster lagi.
## Status cluster berubah dari CREATING menjadi FAILED
Coba buat cluster lagi.
## Status klaster AKTIF tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data
+ Jika pembuatan klaster berhasil (status klaster`ACTIVE`), tetapi Anda tidak dapat mengirim atau menerima data, pastikan bahwa aplikasi produsen dan konsumen Anda memiliki akses ke klaster. Untuk informasi lebih lanjut, lihat panduan di[Langkah 3: Buat mesin klien](create-client-machine.md).
+ Jika produsen dan konsumen Anda memiliki akses ke cluster tetapi masih mengalami masalah dalam memproduksi dan mengkonsumsi data, penyebabnya mungkin [KAFKA-7697, yang mempengaruhi Apache Kafka](https://issues.apache.org/jira/browse/KAFKA-7697) versi 2.1.0 dan dapat menyebabkan kebuntuan di satu atau lebih broker. Pertimbangkan untuk bermigrasi ke Apache Kafka 2.2.1, yang tidak terpengaruh oleh bug ini. Untuk informasi tentang cara bermigrasi, lihat[Migrasikan beban kerja Kafka ke kluster MSK Amazon](migration.md).
## AWS CLI tidak mengenali Amazon MSK
Jika Anda telah AWS CLI menginstal, tetapi tidak mengenali perintah MSK Amazon, tingkatkan AWS CLI ke versi terbaru. Untuk petunjuk terperinci tentang cara meng-upgrade AWS CLI, lihat [Menginstal AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). Untuk informasi tentang cara menggunakan perintah AWS CLI untuk menjalankan Amazon MSK, lihat[Fitur dan konsep utama MSK Amazon](operations.md).
## Partisi offline atau replika tidak sinkron
Ini bisa menjadi gejala ruang disk rendah. Lihat [Ruang disk hampir habis](#troubleshooting-lowdiskspace).
## Ruang disk hampir habis
Lihat praktik terbaik berikut untuk mengelola ruang disk: [Memantau ruang disk](bestpractices.md#bestpractices-monitor-disk-space) dan[Sesuaikan parameter retensi data](bestpractices.md#bestpractices-retention-period).
## Memori hampir habis
Jika Anda melihat `MemoryUsed` metrik berjalan tinggi atau `MemoryFree` hampir habis, itu tidak berarti ada masalah. Apache Kafka dirancang untuk menggunakan memori sebanyak mungkin, dan mengelolanya secara optimal.
## Produser mendapat NotLeaderForPartitionException
Ini sering merupakan kesalahan sementara. Tetapkan parameter `retries` konfigurasi produsen ke nilai yang lebih tinggi dari nilai saat ini.
## Partisi yang kurang direplikasi (URP) lebih besar dari nol
`UnderReplicatedPartitions`Metrik adalah salah satu yang penting untuk dipantau. Dalam cluster MSK yang sehat, metrik ini memiliki nilai 0. Jika lebih besar dari nol, itu mungkin karena salah satu alasan berikut.
+ Jika `UnderReplicatedPartitions` runcing, masalahnya mungkin cluster tidak disediakan pada ukuran yang tepat untuk menangani lalu lintas masuk dan keluar. Lihat [Praktik terbaik untuk pialang Standar](bestpractices.md).
+ Jika `UnderReplicatedPartitions` secara konsisten lebih besar dari 0 termasuk selama periode lalu lintas rendah, masalahnya mungkin Anda telah menetapkan pembatasan ACLs yang tidak memberikan akses topik ke broker. Untuk mereplikasi partisi, broker harus diberi wewenang untuk topik BACA dan DESKRIPSI. DESCRIBE diberikan secara default dengan otorisasi BACA. Untuk informasi tentang pengaturan ACLs, lihat [Otorisasi dan ACLs dalam dokumentasi](https://kafka.apache.org/documentation/#security_authz) Apache Kafka.
## Cluster memiliki topik yang disebut \$1\$1amazon\$1msk\$1canary dan \$1\$1amazon\$1msk\$1canary\$1state
Anda mungkin melihat bahwa klaster MSK Anda memiliki topik dengan nama `__amazon_msk_canary` dan satu lagi dengan nama`__amazon_msk_canary_state`. Ini adalah topik internal yang dibuat dan digunakan Amazon MSK untuk kesehatan klaster dan metrik diagnostik. Topik-topik ini dapat diabaikan dalam ukuran dan tidak dapat dihapus.
## Replikasi partisi gagal
Pastikan Anda belum mengatur ACLs CLUSTER\$1ACTIONS.
## Tidak dapat mengakses klaster yang mengaktifkan akses publik
Jika klaster Anda mengaktifkan akses publik, tetapi Anda masih tidak dapat mengaksesnya dari internet, ikuti langkah-langkah berikut:
1. Pastikan aturan masuk grup keamanan klaster memungkinkan alamat IP Anda dan port cluster. Untuk daftar nomor port cluster, lihat[Informasi pelabuhan](port-info.md). Juga pastikan bahwa aturan keluar grup keamanan memungkinkan komunikasi keluar. Untuk informasi selengkapnya tentang grup keamanan serta aturan masuk dan keluarnya, lihat [Grup keamanan untuk VPC Anda di Panduan Pengguna](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) Amazon VPC.
1. Pastikan alamat IP Anda dan port cluster diizinkan dalam aturan masuk ACL jaringan VPC cluster. Tidak seperti kelompok keamanan, jaringan tidak ACLs memiliki kewarganegaraan. Ini berarti Anda harus mengonfigurasi aturan masuk dan keluar. Dalam aturan keluar, izinkan semua lalu lintas (rentang port: 0-65535) ke alamat IP Anda. Untuk informasi selengkapnya, lihat [Menambahkan dan menghapus aturan](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) di Panduan Pengguna Amazon VPC.
1. Pastikan Anda menggunakan string bootstrap-broker akses publik untuk mengakses cluster. Kluster MSK yang memiliki akses publik diaktifkan memiliki dua string bootstrap-broker yang berbeda, satu untuk akses publik, dan satu untuk akses dari dalam. AWS Untuk informasi selengkapnya, lihat [Dapatkan broker bootstrap menggunakan Konsol Manajemen AWS](get-bootstrap-console.md).
## Tidak dapat mengakses cluster melalui IPv6 bootstrap
Jika Anda mengalami masalah saat menghubungkan ke cluster menggunakan string IPv6 bootstrap yang disediakan, ikuti langkah-langkah berikut:
1. Pastikan klien Anda memiliki alamat IPv4 dan IPv6 yang ditetapkan. Aplikasi klien Anda harus berjalan di subnet yang memiliki pengalamatan IPv4 dan IPv6 diaktifkan dan dikonfigurasi dengan benar. Periksa apakah VPC Anda memiliki blok IPv4 CIDR dan blok CIDR IPv6 terkait, konfirmasikan subnet Anda memiliki alamat IPv4 dan IPv6 yang diaktifkan, dan verifikasi instans EC2 atau lingkungan klien Anda memiliki keduanya dan alamat yang ditetapkan. IPv4 IPv6 Untuk informasi selengkapnya, lihat [Pengalamatan IP untuk subnet Anda VPCs dan subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) di Panduan Pengguna Amazon VPC.
1. Pastikan IPv6 port yang relevan ada dalam aturan masuk dan keluar grup keamanan. Tambahkan aturan masuk untuk mengizinkan lalu lintas pada port klaster dari IPv6 alamat Anda dan konfigurasikan aturan keluar untuk mengizinkan IPv6 lalu lintas. Untuk nomor port tertentu, lihat [Informasi port](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) dalam dokumentasi MSK. Ingatlah untuk memperbarui keduanya IPv4 dan IPv6 aturan jika berjalan dalam mode dual-stack. Untuk informasi selengkapnya tentang grup keamanan serta aturan masuk dan keluarnya, lihat [Grup keamanan untuk VPC Anda di Panduan Pengguna](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) Amazon VPC.
1. Pastikan konfigurasi properti JVM benar untuk IPv6 dukungan. Dalam aplikasi klien Anda, atur `java.net.preferIPv6Addresses` ke `true` dan `java.net.preferIPv4Stack` ke`false`. Pengaturan ini dapat dikonfigurasi baik sebagai properti sistem atau argumen JVM. Mulai ulang aplikasi Anda setelah membuat perubahan ini agar diterapkan.
## Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan
Jika Anda memiliki aplikasi Apache Kafka yang tidak dapat berkomunikasi dengan sukses dengan kluster MSK, mulailah dengan melakukan tes konektivitas berikut.
1. Gunakan salah satu metode yang dijelaskan [Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md) untuk mendapatkan alamat broker bootstrap.
1. Dalam perintah berikut ganti *bootstrap-broker* dengan salah satu alamat broker yang Anda peroleh pada langkah sebelumnya. Ganti *port-number* dengan 9094 jika cluster diatur untuk menggunakan otentikasi TLS. Jika cluster tidak menggunakan otentikasi TLS, ganti *port-number* dengan 9092. Jalankan perintah dari mesin klien.
```
telnet bootstrap-broker port-number
```
Dimana nomor port adalah:
+ 9094 jika cluster diatur untuk menggunakan otentikasi TLS.
+ 9092 Jika cluster tidak menggunakan otentikasi TLS.
+ Nomor port yang berbeda diperlukan jika akses publik diaktifkan.
Jalankan perintah dari mesin klien.
1. Ulangi perintah sebelumnya untuk semua broker bootstrap.
Jika mesin klien dapat mengakses broker, ini berarti tidak ada masalah konektivitas. Dalam hal ini, jalankan perintah berikut untuk memeriksa apakah klien Apache Kafka Anda sudah diatur dengan benar. Untuk mendapatkan*bootstrap-brokers*, gunakan salah satu metode yang dijelaskan dalam[Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md). Ganti *topic* dengan nama topik Anda.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Jika perintah sebelumnya berhasil, ini berarti klien Anda diatur dengan benar. Jika Anda masih tidak dapat memproduksi dan mengkonsumsi dari aplikasi, debug masalah di tingkat aplikasi.
Jika mesin klien tidak dapat mengakses broker, lihat subbagian berikut untuk panduan yang didasarkan pada pengaturan mesin klien Anda.
### Klien Amazon EC2 dan cluster MSK di VPC yang sama
Jika mesin klien berada dalam VPC yang sama dengan kluster MSK, pastikan grup keamanan klaster memiliki aturan masuk yang menerima lalu lintas dari grup keamanan mesin klien. Untuk informasi tentang mengatur aturan ini, lihat [Aturan Grup Keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Untuk contoh cara mengakses cluster dari instans Amazon EC2 yang berada di VPC yang sama dengan cluster, lihat. [Mulai menggunakan Amazon MSK](getting-started.md)
### Klien Amazon EC2 dan kluster MSK berbeda VPCs
Jika mesin klien dan cluster berada dalam dua yang berbeda VPCs, pastikan hal berikut:
+ VPCs Keduanya mengintip.
+ Status koneksi peering aktif.
+ Tabel rute keduanya VPCs diatur dengan benar.
Untuk informasi tentang peering VPC, lihat Bekerja [dengan Koneksi Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Klien lokal
Dalam kasus klien lokal yang diatur untuk terhubung ke kluster MSK menggunakan Site-to-Site VPN, pastikan hal berikut:
+ Status koneksi VPN adalah`UP`. Untuk informasi tentang cara memeriksa status koneksi VPN, lihat [Bagaimana cara memeriksa status terowongan VPN saya saat ini?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/) .
+ Tabel rute VPC klaster berisi rute untuk CIDR lokal yang targetnya memiliki format. `Virtual private gateway(vgw-xxxxxxxx)`
+ Grup keamanan klaster MSK memungkinkan lalu lintas pada port 2181, port 9092 (jika klaster Anda menerima lalu lintas teks biasa), dan port 9094 (jika klaster Anda menerima lalu lintas terenkripsi TLS).
Untuk panduan Site-to-Site VPN pemecahan masalah lainnya, lihat [Pemecahan Masalah Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Jika klien menggunakan Direct Connect, lihat [Pemecahan Masalah Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Jika panduan pemecahan masalah sebelumnya tidak menyelesaikan masalah, pastikan tidak ada firewall yang memblokir lalu lintas jaringan. Untuk debugging lebih lanjut, gunakan alat seperti `tcpdump` dan `Wireshark` untuk menganalisis lalu lintas dan untuk memastikan bahwa itu mencapai cluster MSK.
## Otentikasi gagal: Terlalu banyak koneksi
`Failed authentication ... Too many connects`Kesalahan menunjukkan bahwa broker melindungi dirinya sendiri karena satu atau lebih klien IAM mencoba menghubungkannya dengan tingkat yang agresif. Untuk membantu broker menerima tingkat koneksi IAM baru yang lebih tinggi, Anda dapat meningkatkan parameter [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms)konfigurasi.
Untuk mempelajari lebih lanjut tentang batas tarif untuk koneksi baru per broker, lihat [Kuota MSK Amazon](limits.md) halaman.
## Otentikasi gagal: Sesi terlalu singkat
`Failed authentication ... Session too short`Kesalahan terjadi ketika klien Anda mencoba terhubung ke klaster menggunakan kredensyal IAM yang akan kedaluwarsa. Pastikan Anda memeriksa bagaimana kredensyal IAM Anda disegarkan. Kemungkinan besar, kredensyal diganti terlalu dekat dengan kedaluwarsa sesi yang menyebabkan masalah di sisi server, dan kegagalan otentikasi.
## MSK Tanpa Server: Pembuatan cluster gagal
Jika Anda mencoba membuat kluster MSK Tanpa Server dan alur kerja gagal, Anda mungkin tidak memiliki izin untuk membuat titik akhir VPC. Verifikasi bahwa administrator Anda telah memberi Anda izin untuk membuat titik akhir VPC dengan mengizinkan tindakan. `ec2:CreateVpcEndpoint`
Untuk daftar lengkap izin yang diperlukan untuk melakukan semua tindakan MSK Amazon, lihat. [AWS kebijakan terkelola: MSKFull Akses Amazon](security-iam-awsmanpol-AmazonMSKFullAccess.md)
## Tidak dapat memperbarui KafkaVersionsList dalam konfigurasi MSK
Saat Anda memperbarui [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)properti di [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)sumber daya, pembaruan gagal dengan kesalahan berikut.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Saat Anda memperbarui `KafkaVersionsList` properti, AWS CloudFormation membuat ulang konfigurasi baru dengan properti yang diperbarui sebelum menghapus konfigurasi lama. Pembaruan CloudFormation tumpukan gagal karena konfigurasi baru menggunakan nama yang sama dengan konfigurasi yang ada. Pembaruan semacam itu membutuhkan [penggantian sumber daya](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Agar berhasil memperbarui`KafkaVersionsList`, Anda juga harus memperbarui properti [Nama](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) dalam operasi yang sama.
Selain itu, jika konfigurasi Anda dilampirkan dengan cluster apa pun yang dibuat menggunakan Konsol Manajemen AWS or AWS CLI, tambahkan berikut ini ke sumber daya konfigurasi Anda untuk mencegah [upaya penghapusan sumber daya yang gagal](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Setelah pembaruan berhasil, buka konsol MSK Amazon dan hapus konfigurasi lama. Untuk informasi tentang konfigurasi MSK, lihat. [Konfigurasi Amazon MSK yang disediakan](msk-configuration.md)