メインコンテンツにスキップ
バージョン: 5.0

マスター/スレーブ自動フェイルオーバーモード

架构图

このドキュメントでは、主に、自動マスター/スレーブ切り替えをサポートするRocketMQクラスタをデプロイする方法を紹介します。そのアーキテクチャは上の図に示すとおりです。主に、自動マスター/スレーブ切り替えをサポートするコントローラーコンポーネントを追加します。これは、独立してデプロイすることも、NameServerに埋め込むこともできます。

参照

詳細については、設計思想およびクイックスタートを参照してください。

コントローラーのデプロイ​

コントローラーコンポーネントは、マスターの選択を提供します。コントローラーに耐障害性が必要な場合は、3つ以上のレプリカでデプロイする必要があります（Raftマジョリティプロトコルに従います）。

ヒント

コントローラーが単一コピーとしてのみデプロイされている場合でも、ブローカーのフェイルオーバーを完了できますが、シングルポイントコントローラーが失敗した場合、切り替え能力に影響しますが、既存のクラスタの通常の送受信には影響しません。

コントローラーをデプロイする方法は2つあります。1つは、デプロイのためにNameServerに埋め込むことです。これは、enableControllerInNamesrvを設定することで開くことができます（選択的に開くことができ、すべてのNameServerで開く必要はありません）。このモードでは、NameServer自体は依然としてステートレスです。これは、埋め込みモードでNameServerが失敗した場合、切り替え能力にのみ影響し、元のルーティング取得などの機能には影響しないことを意味します。もう1つは、コントローラーコンポーネントを独立してデプロイすることです。

デプロイのためにNameServerにコントローラーを埋め込む​

内嵌部署图

コントローラーをデプロイのためにNameServerに埋め込む場合は、NameServer構成ファイルでenableControllerInNamesrv=trueを設定し、コントローラー構成を記述するだけで済みます。

enableControllerInNamesrv = true
controllerDLegerGroup = group1
controllerDLegerPeers = n0-127.0.0.1:9877;n1-127.0.0.1:9878;n2-127.0.0.1:9879
controllerDLegerSelfId = n0
controllerStorePath = /home/admin/DledgerController
enableElectUncleanMaster = false
notifyBrokerRoleChanged = true

パラメータの説明：

  • enableControllerInNamesrv：NameServerでコントローラーを有効にするかどうか、デフォルトはfalseです。
  • controllerDLegerGroup：DLedger Raftグループの名前、同じDLedger Raftグループ内では一致する必要があります。
  • controllerDLegerPeers：DLedgerグループ内のノードのポート情報、同じグループ内のノードの構成は一致する必要があります。
  • controllerDLegerSelfId：ノードID、controllerDLegerPeersのいずれかである必要があります。同じグループ内の各ノードは一意である必要があります。
  • controllerStorePath：コントローラーログストレージの場所。コントローラーはステートフルであり、コントローラーは再起動またはクラッシュ時にデータを回復するためにログに依存する必要があります。このディレクトリは非常に重要であり、簡単に削除することはできません。
  • enableElectUncleanMaster：SyncStateSetの外部からマスターを選ぶことができるかどうか。trueの場合、古いデータを持つレプリカをマスターとして選択し、メッセージを失う可能性があります。デフォルトはfalseです。
  • notifyBrokerRoleChanged：ブローカーレプリカグループの役割が変更されたときに積極的に通知するかどうか、デフォルトはtrueです。

パラメータを設定したら、構成ファイルを指定してNameServerを起動できます。

$ nohup sh bin/mqnamesrv -c namesrv.conf &

コントローラーの独立したデプロイ​

架构图

独立してデプロイするには、次のスクリプトを実行します

$ nohup sh bin/mqcontroller -c controller.conf &

mqcontrollerスクリプトは、ソースコードパッケージのdistribution/bin/mqcontrollerにあります。構成パラメータは、埋め込みモードの場合と同じです。

注意

コントローラーを独立してデプロイした後でも、ルーティング検出機能を提供するためにNameServerを個別にデプロイする必要があります。

ブローカーのデプロイ​

ブローカーの起動方法は以前と同じですが、次の追加パラメータがあります

  • enableControllerMode：ブローカーコントローラーモードの全体的なスイッチ。この値がtrueの場合にのみ、自動プライマリ/セカンダリ切り替えモードが有効になります。デフォルトはfalseです。
  • controllerAddr：コントローラーのアドレス。複数のコントローラー間はセミコロンで区切ります。たとえば、controllerAddr = 127.0.0.1:9877;127.0.0.1:9878;127.0.0.1:9879
  • syncBrokerMetadataPeriod：ブローカーレプリカ情報をコントローラーに同期する時間間隔。デフォルトは5000（5秒）です。
  • checkSyncStateSetPeriod：SyncStateSetをチェックする時間間隔。SyncStateSetをチェックすると、SyncStateが縮小される可能性があります。デフォルトは5000（5秒）です。
  • syncControllerMetadataPeriod：コントローラーメタデータを同期する時間間隔。主にアクティブなコントローラーのアドレスを取得します。デフォルトは10000（10秒）です。
  • haMaxTimeSlaveNotCatchup：スレーブがマスターに追いつかない最大時間間隔。SyncStateSetのスレーブがこの時間間隔を超えると、SyncStateSetから削除されます。デフォルトは15000（15秒）です。
  • storePathEpochFile：エポックファイルの場所。エポックファイルは非常に重要であり、安易に削除することはできません。デフォルトはstoreディレクトリにあります。
  • allAckInSyncStateSet：この値がtrueの場合、メッセージはSyncStateSet内のすべてのレプリカに複製された場合にのみ、クライアントに成功として返されます。これにより、メッセージが失われないことが保証されます。デフォルトはfalseです。
  • syncFromLastFile：スレーブが空のディスクで起動する場合、最後のファイルからレプリケートするかどうか。デフォルトはfalseです。
  • asyncLearner：この値がtrueの場合、レプリカはSyncStateSetに入りません。つまり、マスターとして選出されることはなく、常に学習者レプリカとして機能し、非同期レプリケーションを実行します。デフォルトはfalseです。
  • inSyncReplicas：同期を維持する必要のあるレプリカグループの数。デフォルトは1です。このパラメータはallAckInSyncStateSet=trueの場合には無効です。
  • minInSyncReplicas：同期を維持する必要があるレプリカグループの最小数。SyncStateSetのレプリカ数がminInSyncReplicasより少ない場合、putMessageはPutMessageStatus.IN_SYNC_REPLICASを返します。デフォルトは1です。

コントローラーモードでは、ブローカーの構成でenableControllerMode=trueを設定し、controllerAddrを記述する必要があります。次のコマンドで起動します

$ nohup sh bin/mqbroker -c broker.conf &
注意

自動プライマリ/セカンダリ切り替えモードでは、ブローカーはコントローラーコンポーネントによって割り当てられるbrokerIdとbrokerRoleを指定する必要はありません。

互換性​

このモードでは、クライアントレベルのAPIに変更や修正は行われず、クライアントとの互換性の問題はありません。

NameServer自体は変更されておらず、NameServerとの互換性の問題はありません。enableControllerInNamesrvが有効になっていて、コントローラーパラメータが正しく構成されている場合、コントローラー機能が有効になります。

ブローカーがenableControllerMode=falseに設定されている場合、以前と同じように動作します。enableControllerMode=trueの場合、正常に動作するには、コントローラーをデプロイし、パラメータを正しく構成する必要があります。

具体的な動作を次の表に示します。

旧ネームサーバー旧ネームサーバー+コントローラーを独立してデプロイ新しいネームサーバーでコントローラーを有効にする新しいネームサーバーでコントローラーを無効にする
旧ブローカー正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません
新しいブローカーでコントローラーモードを有効にする正常にオンラインにできません正常に動作し、フェイルオーバーできます正常に動作し、フェイルオーバーできます正常にオンラインにできません
新しいブローカーでコントローラーモードを無効にする正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません正常に動作し、フェイルオーバーできません

アップグレードに関する考慮事項​

上記の互換性のステートメントから、NameServerは互換性の問題なしに正常にアップグレードできることがわかります。NameServerをアップグレードしない場合は、コントローラーコンポーネントを独立してデプロイして、切り替え機能を取得できます。ブローカーのアップグレードには、次の2つのケースがあります

  1. マスター/スレーブのデプロイがコントローラー切り替えアーキテクチャにアップグレードされる

    データを使用したインプレースアップグレードが可能です。ブローカーの各グループについて、プライマリブローカーとセカンダリブローカーを停止し、プライマリとセカンダリのCommitLogsが揃っていることを確認します（アップグレード前にこのブローカーグループへの書き込みを一定期間無効にするか、コピーして一貫性を確保することができます）。パッケージをアップグレードした後、再起動します。

    注意

    プライマリとセカンダリのCommitLogが同期していない場合、プライマリがオンラインになってからセカンダリがオンラインになるようにする必要があります。そうしないと、データ切り捨てによりメッセージが失われる可能性があります。

  2. DLedgerモードからコントローラ切り替えアーキテクチャへのアップグレード

    DLedgerモードとマスター/スレーブモードではメッセージデータの形式が異なるため、データのインプレースアップグレードはできません。複数のブローカーグループをデプロイする場合は、特定の期間（既存のすべてのメッセージが消費されたことを確認できる限り）ブローカーグループへの書き込みを無効にしてから、コントローラと新しいブローカーをアップグレードおよびデプロイすることができます。このようにして、新しいブローカーは既存のブローカーからメッセージを消費し、既存のブローカーは新しいブローカーからメッセージを消費し、消費のバランスが取れるまで続けます。その後、既存のブローカーを廃止することができます。