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