すべてのプロダクト
Search
ドキュメントセンター

PolarDB:Paxosマルチレプリカ

最終更新日:Jun 04, 2024

このトピックでは、PolarDB-X Standard EditionのPaxosマルチレプリカの概念とO&Mについて説明します。

展開モード

PolarDB-Xは、複数の展開モードとディザスタリカバリアーキテクチャをサポートしています。 たとえば、PolarDB-Xインスタンスでは、ノードを1つのゾーン、3つのゾーン、または2つのリージョンにまたがる3つのデータセンターにデプロイできます。

作業原理と利点

作業原理

image.pngPaxosは、先駆的なコンセンサスアルゴリズムの1つです。 リーダーベースのアプローチで動作します。 PolarDB-X Standard Editionクラスターでは、1つのノードのみがリーダーとして機能し、書き込み操作を担当し、他のノードはフォロワーとして機能し、多数決とデータ同期を担当します。

  • Paxosのコンセンサスログは、MySQLのバイナリログコンテンツを統合します。 リーダーノードは、コンセンサス関連のバイナリログイベントをバイナリログプロトコルに追加しますが、フォロワノードは従来のリレーログを置き換えます。 salveデータベースは、SQLスレッドを介してログコンテンツをデータファイルに再生します。 本質的に、PaxosコンセンサスログはMySQLバイナリログに似ています。

  • Paxosは、動的リーダーノードの選択にハートビート /選択タイムアウトメカニズムを使用します。 リーダーノードが利用不可能になったことを検出すると、フォロワノードは新しいリーダーノードを選択する。 新しいリーダーノードは、SQLスレッドが既存のログをデータファイルに中継するまでサービスを提供しません。

のメリット

Paxosベースのマルチノードアーキテクチャには、次の利点があります。

  • 高性能: シングルリーダーモードは、MySQLの半同期レプリケーションモードと同等のパフォーマンスを提供します。

  • ゼロRPO: PaxosプロトコルログはMySQLバイナリログの内容を統合し、多数決ベースの同期メカニズムによりデータの損失がなくなります。

  • 自動HA: リーダー選択のためのハートビートメカニズムに基づいて、フォロワーノードはリーダーノードが生きているかどうかを自動的に検出し、必要に応じてHA切り替えを実行します。 自動HAを使用して、MySQLのアクティブ /スタンバイHAを置き換えることができます。

メタデータ

Paxosのレプリカに関する情報を照会する

次のステートメントを実行して、Paxosのレプリカに関する情報を照会します。 リーダーノードのみがデータを返し、非リーダーノードは結果を返しません。

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_グローバル

結果

---------- ------------------ -----------------------------------------------------------------------------------
| SERVER_ID | IP_PORT | MATCH_INDEX | NEXT_INDEX | ROLE | HAS_VOTED | FORCE_SYNC | ELECTION_WEIGHT | LEARNER_SOURCE | APPLIED_INDEX | PIPELINING | SEND_APPLIED |
----------------------------------------------------------------------------------------------------------------
| 1 | 10.0.3.244:14886 | 1 | 0 | リーダー | はい | いいえ | 5 | 0 | 0 | いいえ | いいえ |
| 2 | 10.0.3.245:14886 | 1 | 2 | フォロワー | はい | いいえ | 5 | 0 | 1 | はい | いいえ
| 3 | 10.0.3.246:14886 | 1 | 2 | フォロワー | いいえ | いいえ | 5 | 0 | 1 | はい | いいえ
----------------------------------------------------------------------------------------------------------------
セットの3列 (0.00秒) 

Parameters

  • IP_PORT: レプリカのIPアドレスとポート番号を示します。

  • ROLE: リーダー、フォロワー、学習者など、Paxosのレプリカの役割を示します。

  • ELECTION_WEIGHT: 選挙の重みを示します。 一般に、クロスデータセンターのディザスタリカバリシナリオに適用できます。 同じデータセンター内のレプリカの重みを高く設定して、選出に勝つ可能性を高めることができます。

  • MATCH_INDEX/NEXT_INDEX/APPLIED_INDEX: コンセンサスログのインデックスを示します。

ローカルシステムのPaxosステータスの照会

次のステートメントを実行して、ローカルシステムのPaxosステータスを照会します。

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL

結果

MySQL [(なし)]> SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_LOCAL \G
*************************** 1。 行 ***************************
          SERVER_ID: 1
       CURRENT_TERM: 6
     CURRENT_LEADER: 10.0.3.244:14886
       COMMIT_INDEX: 1
      LAST_LOG_TERM: 6
     LAST_LOG_INDEX: 1
               役割: リーダー
          VOTED_FOR: 1
   LAST_APPLY_INDEX: 0
SERVER_READY_FOR_RW: はい
      INSTANCE_TYPE: 通常 

Parameters

  • CURRENT_LEADER: 現在のリーダーノードのIPアドレスとポート番号を示します。

  • ROLE: リーダー、フォロワー、学習者など、Paxosのレプリカの役割を示します。

  • INSTANCE_TYPE:: はレプリカのタイプを示します。 有効な値: NormalとLog。

Paxosのレプリカ間のクエリデータ同期

次のステートメントを実行して、Paxosのレプリカ間のデータ同期を照会します (リーダーノードのみがデータを返し、非リーダーノードは結果を返しません) 。

SELECT * FROM INFORMATION_SCHEMA.ALISQL_CLUSTER_HEALTH

結果

---------- ------------------ ---------------------------------------------------- ----------------- +
| SERVER_ID | IP_PORT | ROLE | CONNECTED | LOG_DELAY_NUM | APPLY_DELAY_NUM |
----------- ------------------ --------------------------------------------------- ----------------- +
| 1 | 10.0.3.244:14886 | フォロワー | はい | 0 | 22 |
| 2 | 10.0.3.245:14886 | リーダー | はい | 0 | 0 |
| 3 | 10.0.3.246:14886 | フォロワー | はい | 0 | 11 |
----------- ------------------ ---------------------------------------------------- ----------------- + 

Parameters

  • CONNECTED: ノードが正常かどうかを示します。

  • LOG_DELAY_NUM: Paxosでのコンセンサスログ同期のレイテンシを示します。これは、MySQLでのリレーログ同期のレイテンシと同様です。

  • APPLY_DELAY_NUM: フォロワーノードでのPaxosコンセンサスログの再生遅延を示します。これは、MySQLのSQLリレースレッドの再生遅延と同様です。