データレプリカの管理
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で認識し、重大な混乱や問題を引き起こす可能性があります。