データレプリカの管理
EMQXクラスターにおいて、耐久性のあるストレージは複数のデータレプリカによって高可用性を実現します。ノードがクラッシュした場合でも、クライアントはすぐに新しいノードに接続し、他のノード上のレプリカからデータを復旧できます。本ガイドでは、データレプリケーションの設定方法と耐久性ストレージの高可用性を確保する手順を説明します。内容は、新規に耐久性ストレージを備えたEMQXクラスターを構築する場合と、既存クラスターをアップグレードして耐久性ストレージを有効化する場合の2つのシナリオに分かれています。
初期クラスター構築
クラスターの初期構築時には、耐久性ストレージの確立とデータレプリケーションの開始に影響する複数の設定パラメータがあります。これらのパラメータはランタイム中に変更できず、一度耐久性ストレージが初期化されると変更は反映されません。
レプリケーションファクター
durable_storage.messages.replication_factor 設定パラメータで制御されるレプリケーションファクターは、クラスター全体で各シャードが持つべきレプリカ数を決定します。デフォルト値は 3 です。
書き込み操作の成功に必要なクォーラムサイズに影響するため、レプリケーションファクターは奇数に設定することが推奨されます。レプリケーションファクターが高いほど、クラスター内に分散されるデータのコピー数が増え、高可用性が向上します。ただし、合意形成に必要な通信が増えるため、ストレージおよびネットワークのオーバーヘッドも増加します。
TIP
小規模クラスターではレプリケーションファクターが厳密に適用されません。例えば、2ノードクラスターでは各シャードが両ノードにレプリケートされるため、実質的なレプリケーションファクターは 2 となり、追加のレプリケーションは不要です。EMQXは各シャードのレプリカをクラスター内の異なるノードに割り当て、冗長性を確保します。
シャード数
組み込みの耐久性ストレージは複数のシャードに分割され、それぞれ独立してレプリケートされます。シャード数が多いほど、MQTTメッセージのパブリッシュおよびサブスクライブの並列処理が向上します。ただし、各シャードはファイルディスクリプタなどのシステムリソースを消費し、セッションごとに保存されるメタデータの量も増加します。
durable_storage.messages.n_shards パラメータでシャード数を制御し、耐久性ストレージの初期化後は固定されます。
サイト数
durable_storage.messages.n_sites 設定パラメータは、耐久性ストレージの初期化および書き込み開始に必要な最低オンラインサイト数を決定します。この最低数が満たされると、耐久性ストレージは利用可能なサイトにシャードを均等に割り当て始めます。
デフォルト値は 1 であり、各ノードは最初は自分自身を唯一のデータ保存サイトと見なします。この設定は単一ノードのEMQXクラスターに最適化されています。クラスターが形成されると、あるノードの見解が優勢になり、他のノードは自身の保存データを放棄します。
複数ノードのクラスターでは、競合を避けるためにサイト数を初期クラスターサイズに設定することが推奨されます。耐久性ストレージの初期化後はこのパラメータを変更できません。
既存クラスターの変更
既存クラスターは、容量や耐久性、クライアントトラフィックの変化、古いノードの廃止および新ノードへの置き換えなどにより再設定が必要になる場合があります。これは、耐久性ストレージのレプリケーション対象サイトの追加や不要サイトの削除によって実現できます。
現在のシャード割り当ては、emqx ctl CLIの ds サブコマンドで確認可能です。
$ emqx ctl ds info
SITES:
...
SHARDS:
...サイトの追加
新しいノードがクラスターに参加すると、Site ID が割り当てられ、耐久性ストレージに含めることができます。いくつかのシャードレプリカの責任が新サイトに移され、データのレプリケーションが開始されます。
$ emqx ctl ds join messages <Site ID>
okクラスターのデータ量によっては、新サイト参加に時間がかかることがあります。この処理中も耐久性ストレージの可用性は損なわれませんが、サイト間のバックグラウンドデータ転送により一時的にクラスターのパフォーマンスが低下する可能性があります。
レプリカセットの変更は耐久的に保存されるため、ノードの再起動やネットワーク分断があっても結果に影響しません。クラスターは最終的に望ましい状態に一貫して到達します。
サイトの削除
サイトの削除は、削除対象サイトからシャードレプリカの責任を移譲することを伴います。追加と同様に時間とリソースを要します。
$ emqx ctl ds leave messages <Site ID>
okサイトを削除すると、実効的なレプリケーションファクターが設定値を下回る可能性があります。例えば、レプリケーションファクターが 3 で3ノードクラスターのうち1サイトを削除すると、実効レプリケーションファクターは 2 に低下します。サイトを恒久的に置き換える場合は、古いサイトを廃止する前に新しいサイトを追加するか、両操作を同時に行うことを推奨します。
サイトの割り当て
耐久性ストレージのレプリカを保持するサイト群の変更は、一度の操作で複数のサイトを設定可能です。
$ emqx ctl ds set_replicas messages <Site ID 1> <Site ID 2> ...この方法はサイト間のデータ転送量を最小化しつつ、可能な限りレプリケーションファクターを維持します。
災害からの復旧
災害発生時に効率的に復旧する方法を知ることは、サービス継続性の維持に不可欠です。本節では一般的な災害シナリオからの復旧手順を説明します。
ノードの完全喪失
最も一般的な災害シナリオの一つは、ノードの完全喪失です。これはハードウェアの復旧不能な故障、ディスク破損、あるいは人的ミスによって発生します。
ノードが完全に失われると、クラスターの可用性はある程度損なわれますが、クラスター内の他の健全なサイトにシャードレプリカを再割り当てすることで復旧可能です。
ノード喪失の通知
まず、クラスタに対して該当ノードがもはやメンバーでないことを通知します。これを行わないと、再割り当て処理は一時的なオフラインとみなし、遷移が無期限に停止する可能性があります。
shell$ emqx ctl cluster force-leave emqx@n2.localシャード遷移の開始
次に、失われたノードのシャードを他ノードに再割り当てし、可用性を回復します。
leaveコマンドを使用します。このコマンドはノードが失われているか到達不能でも動作しますが、遷移完了まで時間がかかる場合があります。shell$ emqx ctl ds leave messages 5C6028D6CE9459C7 # ここで5C6028D6CE9459C7は失われたノードのSite IDクラスター状態の監視
すべてのシャード遷移が正常に完了するまで待ちます。進行中の遷移は
infoコマンドで確認可能です。shell$ emqx ctl ds info <...> SITES: .------------------.-------------------.----------. : Site : Node : Status : :------------------:-------------------:----------: : D8894F95DC86DFDB : 'emqx@n1.local' : up : : 5C6028D6CE9459C7 : 'emqx@n2.local' : (!) LOST : : <...> SHARDS: .------------.----------------------.------------------------. : DB/Shard : Replicas : Transitions : :------------:----------------------:------------------------: :-messages/0-:----------------------:------------------------: : : 5C6028D6CE9459C7 (!) : - 5C6028D6CE9459C7 (!) : : : <...> : + D8894F95DC86DFDB : : <...>次のステップに進む前に遷移がすべて完了していることを確認してください。
最終処理
すべてのシャード遷移が完了したら、失われたサイトが今後復帰しないことをクラスタに通知します。
shell$ emqx ctl ds forget messages 5C6028D6CE9459C7この手順は、失われたノードを元のノード名で新しいノードに置き換える場合に特に重要です。これを行わないと、クラスターが同じノード名を異なるSite IDで認識し、混乱や問題を引き起こす可能性があります。