ApsaraMQ for Kafka ブローカーをアップグレードすると、メッセージの順序の問題、クライアントの切断、またはパーティション間でのメッセージの不均等な分散が発生する可能性があります。
ApsaraMQ for Kafka ブローカーをアップグレードすると、以下の問題が発生する可能性があります。
アップグレード中、ApsaraMQ for Kafka クラスター内のすべてのブローカーが 1 つずつ再起動します。ブローカーの再起動中もサービスは中断されることなく継続します。ただし、各ブローカーの再起動後 5 分以内に消費されたメッセージは、特定のパーティションで順序が乱れる可能性があります。サーバーレスの ApsaraMQ for Kafka および ApsaraMQ for Confluent インスタンスは、バージョンアップグレード中に Apache Kafka のセマンティクスに完全に準拠することにご注意ください。
ブローカーの再起動中、それらのブローカーに接続されているクライアントで切断が発生する可能性があります。クライアントが自動再接続をサポートしている場合、他のブローカーが自動的にサービスを引き継ぎます。
ブローカーのアップグレードおよび再起動中、異なるパーティション間でメッセージ処理のボリュームが不均等になる可能性があります。これがビジネス運用にどのように影響するかを評価する必要があります。
一部のシナリオでは、ブローカーの IP アドレスが変更される可能性があります。クライアントが IP アドレスではなくドメイン名を使用して Kafka サーバーに接続するようにしてください。
すべてのブローカーのアップグレードプロセスには、通常 5 分から 15 分かかります。複数のインスタンスを管理している場合は、まずテストクラスターをアップグレードできます。テストクラスターでアップグレード結果を確認した後、本番クラスターのアップグレードに進むことができます。
Sarama ライブラリで開発された Go クライアントを使用してメッセージを送信およびサブスクライブする場合、ブローカーのアップグレード中にメッセージの重複が発生する可能性があります。詳細については、「Sarama Go クライアントを使用してメッセージを送受信することが推奨されない理由」をご参照ください。