データレプリカの管理
EMQXクラスターにおいて、耐久性のあるストレージは複数のデータレプリカを通じて高可用性を実現します。ノードがクラッシュした場合でも、クライアントはすぐに新しいノードに接続し、他のノード上のレプリカからデータを復旧できます。本ガイドでは、データレプリケーションの設定方法と耐久性ストレージの高可用性を確保する手順を説明します。本ガイドは、耐久性ストレージを備えた新しいEMQXクラスターのセットアップと、既存クラスターのアップグレードによる耐久性ストレージの有効化という2つのシナリオに分かれています。
初期クラスターセットアップ
クラスターの初期セットアップ時に、耐久性ストレージの構築とデータレプリケーションの開始に影響を与えるいくつかの設定パラメータがあります。これらのパラメータはランタイム中に変更できず、一度耐久性ストレージが初期化されると変更は反映されません。
耐久性ストレージを初期化する前に、すべてのノードのEMQXデータディレクトリがローカルファイルシステムを使用していることを確認してください。組み込み耐久性ストレージバックエンドは、NFSやSMB/CIFSなどのネットワークファイルシステムをサポートしていません。
レプリケーションファクター
durable_storage.<DB>.replication_factor 設定パラメータで制御されるレプリケーションファクターは、クラスター全体で各シャードが持つべきレプリカの数を決定します。デフォルト値は 3 です。
レプリケーションファクターは奇数に設定することが推奨されます。これは、書き込み操作の成功に必要なクォーラムサイズに影響を与えるためです。レプリケーションファクターが高いほど、クラスター全体にデータのコピーが多く分散されるため、高可用性が向上します。ただし、合意形成に必要な通信が増えるため、ストレージとネットワークのオーバーヘッドも増加します。
TIP
小規模クラスターではレプリケーションファクターが厳密に適用されない場合があります。例えば、2ノードクラスターでは、各シャードが両方のノードにレプリケートされるため、実質的なレプリケーションファクターは 2 となり、追加のレプリケーションは不要です。EMQXは、冗長性を確保するために各シャードのレプリカをクラスター内の異なるノードに割り当てます。
シャード数
組み込みの耐久性ストレージはシャードに分割されており、各シャードは独立してレプリケートされます。シャード数が多いほど、MQTTメッセージのパブリッシュとコンシュームをより並列に処理できます。ただし、各シャードはファイルディスクリプタなどのシステムリソースを消費し、セッションごとに保存されるメタデータの量も増加します。
durable_storage.messages.n_shards パラメータでシャード数を制御し、耐久性ストレージの初期化後は固定されます。
サイト数
durable_storage.n_sites 設定パラメータは、耐久性ストレージが初期化され書き込みを受け入れ始めるためにオンラインでなければならない最低限のサイト数を決定します。この最低数が満たされると、耐久性ストレージは利用可能なサイトにシャードをバランスよく割り当て始めます。
デフォルト値は 1 であり、これは各ノードが最初は自分自身をデータストレージを担当する唯一のサイトと見なすことを意味します。この設定は単一ノードのEMQXクラスターに最適化されています。クラスターが形成されると、最終的に1つのノードの見解が優勢となり、他のノードは保存していたデータを放棄します。
マルチノードクラスターでは、こうした競合を防ぐためにサイト数を初期クラスターサイズに設定することが推奨されます。なお、耐久性ストレージが初期化された後は、このパラメータを変更できません。
既存クラスターの変更
既存クラスターは、容量や耐久性、クライアントトラフィックの変化、古いノードの廃止と新しいノードへの置き換えなどにより再設定が必要になる場合があります。これは、耐久性ストレージのレプリケーションを持つサイトのセットに新しいサイトを追加したり、不要になったサイトを削除することで実現できます。
現在のシャード割り当て状況は、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で認識し、重大な混乱や問題を引き起こす可能性があります。