EMQX 5.8 の既知の問題

e5.8.9

バージョン	問題	回避策	ステータス
5.0.0	クラスターにおけるルートおよびセッションレジストリの不整合 ネットワークパーティションの回復、ノードの異常シャットダウン、クリーンアップ時のRPCタイムアウトなどのクラスターイベント後に、ルートテーブルおよびグローバルセッション（チャネル）レジストリに古いまたは欠落したエントリが残る複数の関連問題があります。具体的な症状は以下の通りです： - レプリカントノードのサブスクライバー向けルートがネットワークパーティション回復後に完全に再同期されず、影響を受けたノードの再起動まで一部のサブスクリプションがメッセージを受信しなくなる場合があります。 - レプリカントノードが所有するチャネルがパーティション回復後にグローバルレジストリから削除され、誤ったセッションテイクオーバー（再接続クライアントが古いセッションを置き換えない）やダッシュボードのクライアント数の誤表示を引き起こします。 - セッションの所有プロセスがクリーンな登録解除なしに終了した場合（例えば、登録解除のレプリケーションがネットワーク分断により阻害された場合や、コアのコンセンサスチェックがダウンイベントのクリーンアップ中にタイムアウトした場合）、グローバルセッションレジストリの行が無期限に残留し、同じクライアントIDが再接続しない限りこれらの死んだ行が蓄積されます。 これらの修正は新しいリリースラインに含まれていますが、5.8にはバックポートされません。詳細はemqx/emqxのPR #17076、#17257、#17522を参照してください。	-	5.10.4以降、6.1.2以降、または6.2.1以降にアップグレードしてください
5.8.9	DashboardからMQTTコネクターの静的クライアントIDを設定できない	各ノードの設定ファイルから静的クライアントIDを設定してください。
5.1.0	新しいコアノードがクラスターに追加された際にレプリカントノードが起動でハングする場合がある 新しいコアノードを追加するクラスター変更時に、新規追加されたコアがレプリカントノードに必要なレプリケーション関連プロセスの起動に失敗することがありました。これにより、アップグレードまたは新規追加されたレプリカントノードが起動時にハングすることがありました。 Kubernetes環境では、レプリカントポッドのreadinessプローブが失敗し、コントローラーがポッドを繰り返し再起動する問題が発生しました。 この問題は、例えば既存の2コア＋2レプリカントクラスターに新たに2つのコアノードと2つの新しいEMQXバージョンのレプリカントを追加するアップグレードロールアウト時に発生しやすいです。	レプリカントノードが起動時にハングした場合は、新規追加されたコアノードを1台ずつ強制的に再起動し、レプリカントの起動が完了するまで繰り返してください。	5.8.9で修正済み

e5.8.8

バージョン	問題	回避策	ステータス
5.8.0	前の項目を削除した後にメッセージ変換やスキーマ検証の無効化が反映されない メッセージ変換またはスキーマ検証のエントリを削除し、その後リスト内の後続のエントリを無効化しても、エントリは有効のまま残ります。	任意のEMQXノードで以下のコマンドを実行してください。 $ emqx eval "begin ets:delete_all_objects(emqx_message_transformation_index), emqx_message_transformation_config:load() end."	5.8.8で解決済み
5.8.1	ノード再起動後に外部スキーマレジストリが読み込まれない	-	5.8.8で解決済み
5.7.0	クラスターリンクのガベージコレクションがアクティブルートを誤って削除する場合がある 複数の独立したクラスターリンクが設定され、一部のリンクが長期間ダウンしている場合、ガベージコレクション処理が誤って内部ルーティングテーブルのアクティブルートを削除することがあります。これにより、影響を受けたクラスターリンクはメッセージの一部のみを転送するか、メッセージ転送を完全に停止することがあります。	-	5.8.9、6.1.0で修正済み

e5.8.6

バージョン	問題	回避策	ステータス
5.8.5	クラスターから離脱したノードへの接続失敗によるRPCエラーがログに断続的に出現する この種のログメッセージの急増は通常、ルーティングアップグレード後に始まります。ログ例： pid: <0.123456.0>, msg: event=connect_to_remote_server, peer=emqx@10.11.12.13, port=5370, reason=ehostunreach これらのメッセージの存在は、既存接続のメッセージ配信に影響があることを示しません。	EMQXホストのいずれかで以下のコマンドを実行してください。エラーログに記載された実際のノード名（例：emqx@10.11.12.13）に置き換えてください。 実行前に、このノードがクラスターに含まれていないことを必ず確認してください。 $ emqx eval "emqx_router:cleanup_routes('emqx@10.11.12.13')"	5.9.0で解決予定
5.4.0	TLSリスナーがデフォルト設定で起動した場合、tlsv1.3のみへのホットアップデートができない incompatible,[client_renegotiation,{versions,['tlsv1.3']}]のようなエラーが発生する場合があります。	リスナーを一旦無効化し、設定変更後に再度有効化してください。	5.9.0で解決予定
5.0.0	Linuxの単調クロックが逆戻りするとノードがクラッシュする 特定の仮想Linux環境では、OSが単調クロックを維持できず、Erlang VMがOS monotonic time stepped backwards!というメッセージで終了することがあります。	そのような環境では、etc/vm.args内で+cフラグをfalseに設定してください。
5.0.0	IoTDBのバッチモードでbatch_size > 1の場合に正常に動作しない可能性がある EMQXはIoTDB v1 APIを使用しており、バッチ操作のネイティブサポートがありません。バッチ機能を模倣するために反復処理を使用していますが、これは原子性がなくバグの原因となる場合があります。	-
5.8.1	IoTDBのThriftドライバーはasyncモードをサポートしていない	-
5.3.0	SAMLベースのSSOの制限 EMQXダッシュボードはSAML 2.0標準に基づくシングルサインオンをサポートし、OktaおよびOneLoginをIDプロバイダーとして統合しています。しかし、SAMLベースのSSOは現在、証明書署名検証機構をサポートしておらず、その複雑さからAzure Entra IDとは互換性がありません。	-

e5.8.4

バージョン	問題	回避策	ステータス
5.0.0	停止中に新しいノードがクラスターに参加するとノードが起動できない 2ノード以上のクラスターで、一部のノードが停止中に新しいノードがクラスターに参加すると、停止していたノードは再起動に失敗し、以下のようなログを出力します。 2024-10-03T17:13:45.063985+00:00 [error] Mnesia('emqx@172.17.0.5'): ** ERROR ** (core dumped to file: "/opt/emqx/MnesiaCore.emqx@172.17.0.5_1727_975625_63176"), ** FATAL ** Failed to merge schema: {aborted,function_clause}	data/mnesiaディレクトリを削除し、ノードを再起動してください。	5.8.5で解決済み
5.8.0	サイト数が失われるとシャードレプリカセットの変更が停止する この問題はDurable Sessionsが有効でDS Raftバックエンドを使用している場合にのみ発生する可能性があります。 Durable Storageデータのレプリケーションサイトとして機能するノードがクラスターを永久に離脱し、データの引き継ぎを行わなかった場合、レプリカセットの遷移要求が永遠に完了しない状況になることがあります。 簡略化した例として、emqx ctl ds infoの出力は以下のようになります。ここで、ノードemqx@emqxc1-core0.localはクラスターを離脱し、すべてのシャードの唯一のレプリケーションサイトでした。その後、emqx@emqxc2-core0.localにemqx ds join messages ABCDEF2222222222で引き継ぎが要求されました。 Site ABCDEF1111111111 'emqx@emqxc1-core0.local' (!) UNIDENTIFIED ABCDEF2222222222 'emqx@emqxc2-core0.local' up <...> Shard Replicas messages/0 (!) ABCDEF1111111111 messages/1 (!) ABCDEF1111111111 <...> messages/9 (!) ABCDEF1111111111 Shard Transitions messages/0 +ABCDEF2222222222 -ABCDEF1111111111 messages/1 +ABCDEF2222222222 -ABCDEF1111111111 <...> messages/9 +ABCDEF2222222222 -ABCDEF1111111111 この例では、遷移+ABCDEF2222222222は決して完了しません。	-	5.8.5で解決済み

e5.8.1

バージョン	問題	回避策	ステータス
5.8.0	Kafkaディスクバッファディレクトリ名の変更 Kafka（Azure EventHubs、Confluent Platform）プロデューサー統合の動的トピックテンプレート導入により、ディスク上のバッファディレクトリ名に互換性のない変更が加わりました。 diskモードバッファを使用している場合は、古いバージョンからのアップグレード後にバッファされたメッセージが失われるのを防ぐため、5.8.2リリースを待つことを推奨します。 hybridモードバッファを使用している場合は、古いディレクトリを手動でクリーンアップする必要があります。	-	5.8.2で解決済み
5.8.0	Kafkaディスクバッファの再開問題 diskモードバッファを使用している場合、ノード再起動後にKafka（Azure EventHubs、Confluent Platform）プロデューサーがディスクからKafkaへの送信を自動的に再開しません。送信は新しいメッセージがトピックプロデューサーの動的追加をトリガーした場合にのみ開始されます。	-	5.8.2で解決済み
5.4.0	監査イベント表示時のパフォーマンス低下 監査ログを有効にし、ダッシュボードで特定のイベントを表示すると、まれに大幅なパフォーマンス低下やメモリ制約のあるノードでEMQXノードのクラッシュを引き起こす場合があります。問題が発生しやすいイベントには、バックアップおよびリストアAPIリクエストや、大きなデータ構造を操作するEMQXリモートコンソールのコマンドが含まれます。これによりノードの起動や応答が遅くなる場合もあります。	ダッシュボードの最大ダッシュボードレコードサイズを調整するか、log.audit.max_filter_size設定を下げてください。時間経過とともに問題のあるイベントは新しいイベントの記録により監査ログから消去されます。	5.8.2で解決済み
5.8.1	GET /monitor HTTP APIおよびダッシュボードでのゲージ値の歪み ダッシュボードのデータ提供にも使われるGET /monitor HTTP APIで、時間範囲を1時間からより長い期間に変更すると、過去1時間以内に収集された最新のデータポイントが歪んで表示される場合があります。例えば、3つの接続が誤って9つ以上と表示されることがあります。この問題は過去1時間以内のデータポイントにのみ視覚的に発生し、1時間より古いデータでは歪みが不可逆的です。 影響を受けるゲージ： disconnected_durable_sessions subscriptions_durable subscriptions topics connections live_connections	-	5.8.2で解決済み

e5.8.0

バージョン	問題	回避策	ステータス
5.0.0	ノードシャットダウン時のレースコンディションによるクラッシュ RPCチャネルが確立されている最中にノードがシャットダウンすると、ピアノードがクラッシュする可能性があります。	-	5.8.1で解決済み