分散型 MySQL Binlog ストレージシステムのアーキテクチャ設計

1. キングバスの紹介

1.1 Kingbusとは何ですか?

kingbus は、raft の強力なコンセンサスプロトコルに基づく分散 MySQL binlog ストレージシステムです。これは MySQL スレーブとして機能し、実際のマスターから binglog を同期し、分散クラスターに保存できます。同時に、MySQL マスターとして機能し、クラスター内のバイナリログを他のスレーブと同期します。 Kingbus には次の機能があります。

MySQL レプリケーションプロトコルと互換性があり、Gtid を介してマスター上の binlog を同期し、Gtid を介して kingbus から binlog をプルするスレーブをサポートします。
クロスリージョンデータレプリケーション、Kingbus は Raft プロトコルを通じてクロスリージョンデータレプリケーションをサポートします。クラスターに書き込まれたバイナリログデータは、複数のノード間で強力な一貫性が保証され、バイナリログの順序はマスターとまったく同じであることが保証されます。
高可用性: Kingbus は Raft の強力な一貫性プロトコルに基づいて構築されているため、クラスター内のノードの半分以上が稼働している場合、binlog プルおよびプッシュサービス全体の可用性が高くなります。

1.2 kingbus はどのような問題を解決できますか?

kingbus はマスターのネットワーク伝送トラフィックを削減できます。 1 つのマスターと複数のスレーブのレプリケーショントポロジでは、マスターは各スレーブに binlog を送信する必要があります。スレーブが多すぎると、ネットワークトラフィックがマスターのネットワークカードの上限に達する可能性があります。たとえば、マスターが大きなテーブルの削除やオンライン DDL の実行などの操作を実行すると、大量の binlog イベントが瞬時に生成される可能性があります。マスターの下にスレーブが 10 台ある場合、マスター上のネットワークカードトラフィックは 10 倍に増幅されます。マスターがギガビットネットワークカードを使用し、10MB/秒を超えるトラフィックを生成する場合、ネットワークカードが完全に使用される可能性があります。マスターを Kingbus 経由で接続することで、スレーブを複数のマシンに分散し、送信トラフィックのバランスをとることができます。
マスターフェイルオーバープロセスを簡素化するには、キングバスに接続されたスレーブをマスターに昇格し、キングバスを新しいマスターにリダイレクトするだけです。他のスレーブは引き続きキングバスに接続されており、レプリケーショントポロジは変更されません。
マスターが binlog ファイルを保存するためのスペースを確保します。通常、MySQL は高価な SSD に保存されます。 binlog ファイルが占めるスペースが大きすぎる場合は、MySQL に保存されるデータを削減する必要があります。すべてのバイナリログを Kingbus に保存すると、マスターに保存されるバイナリログファイルの数を減らすことができます。
異種レプリケーションをサポートします。 Alibaba のオープンソースチャネルを通じて、Kingbus は Canal に接続されます。 Kingbus は継続的にバイナリログを Canal にプッシュします。 Canal は、バイナリログを受信した後、それを Kafka メッセージキューにプッシュし、最終的に HBase に保存します。ビジネス部門は、Hive を通じて SQL を直接記述し、リアルタイムのビジネス分析を実現します。

2. キングバスの全体アーキテクチャ

kingbus の全体的なアーキテクチャを下図に示します。

ストレージは、raft ログエントリとメタデータを保存する役割を担います。 Kingbus では、raft ログと MySQL binlog が統合されています。 raft ログのデータ部分は、異なるヘッダー情報によって区別される binlog イベントです。この方法では、2 種類のログを別々に保存する必要がないため、ストレージスペースを節約できます。 kingbus は、ラフトノードの投票情報やいくつかの特別な binlog イベント (FORMAT_DESCRIPTION_EVENT) の特定のコンテンツなどのメタ情報を保存する必要があるためです。
Raft は、etcd raft ライブラリを使用して、リーダー選出、ログ複製、および kingbus クラスターのその他の機能を複製します。
binlog syncer は、Raft クラスターのリーダーノードでのみ実行されます。クラスター全体に同期者は 1 つだけ存在します。 Syncer はスレーブのふりをして、マスターとのマスター-スレーブレプリケーション接続を確立します。マスターは、syncer によって送信された execute_gtid_set に従って、syncer がすでに受信した binlog イベントをフィルタリングし、syncer が受信していない binlog イベントのみを送信します。このレプリケーションプロトコルは、MySQL マスタースレーブレプリケーションメカニズムと完全に互換性があります。 binlog イベントを受信すると、syncer は binlog イベントの種類に応じていくつかの処理を実行し、binlog イベントをメッセージにカプセル化して raft クラスターに送信します。ラフトアルゴリズムにより、この binlog イベントは複数のノードに保存され、強力な一貫性を実現できます。
binlog サーバーは、レプリケーションプロトコルを実装するマスターです。実際のスレーブは、binlog サーバーがリッスンするポートに接続できます。 binlog サーバーは binlog イベントをスレーブに送信します。 binlog イベントを送信するプロセス全体は、MySQL レプリケーションプロトコルに従って実装されます。バイナリログイベントがスレーブに送信されない場合、バイナリログサーバーは定期的にハートビートイベントをスレーブに送信して、レプリケーション接続を維持します。
API サーバーは、次のものを含む Kingbus クラスター全体の管理を担当します。
- Raft クラスターのメンバーシップ操作、クラスターのステータスの確認、ノードの追加、ノードの削除、ノード情報の更新など。
- Binlog syncer 関連の操作: Binlog syncer の開始、Binlog syncer の停止、Binlog syncer のステータスの確認。
- Binlog サーバー関連の操作: Binlog サーバーの起動、Binlog サーバーの停止、Binlog サーバーのステータスの確認。サーバー層でのさまざまな例外は、ラフト層には影響しません。サーバーは、必要に応じて起動および停止できるプラグインとして理解できます。将来的に Kingbus を拡張する際には、関連するロジックのサーバーを実装するだけで済みます。たとえば、Kafka プロトコルサーバーを実装すると、Kafka クライアントを介して Kingbus でメッセージを消費できます。

3. Kingbusコア実装

3.1 ストレージのコア実装

ストレージには 2 種類のログが存在します。 1つはラフトアルゴリズムによって生成され使用されるラフトログ（以下、ラフトログと呼ぶ）である。もう 1 つは、ユーザータイプのログ (つまり、MySQL binlog イベント) です。ストレージの設計では、2 つのログフォームが 1 つのログエントリに結合されます。これらは異なるヘッダー情報によってのみ区別されます。ストレージは、次の図に示すように、データファイルとインデックスファイルで構成されます。

セグメントのサイズは固定 (1GB) であり、追加モードでのみ書き込むことができます。名前は first_raft_index-last_raft_index で、セグメントのラフトインデックス範囲を示します。
最初のセグメントのみが書き込み可能で、そのファイル名は first_raft_index-inprogress です。その他のセグメントは読み取り専用です。
読み取り専用セグメントと対応するインデックスファイルは、mmap を介して書き込まれ、読み取られます。
***セグメントのインデックスコンテンツは、ディスクとメモリに同時に保存されます。インデックスを読み取るには、メモリから読み取るだけで済みます。

3.2 etcd raftライブラリの使用

Etcd raft ライブラリは、適用されたログ、コミットされたエントリ、およびその他のコンテンツを単一のスレッドで処理します。具体的な機能についてはリンク先をご参照ください。この機能の処理時間はできる限り短くする必要があります。処理時間がラフト選出時間を超えると、クラスターは再選出されます。この点には特別な注意が必要です。

3.3 Binlog Syncer のコア実装

binlog syncer の主なタスクは次のとおりです。

バイナリログイベントのプル
バイナリログイベントを解析して処理する
binlog イベントを raft クラスターに送信します。明らかに、パイプライン機構を使用すると、プロセス全体の処理速度を向上させることができます。 Kingbus は、各ステージを処理するために個別の goroutine を使用し、パイプラインを通じて異なるステージを接続します。 binlog syncer は binlog イベントを 1 つずつ受信するため、トランザクションの整合性を保証することはできません。 Syncer が切断された後、マスターに再接続する必要がある可能性があります。現時点では、最後の取引が未完了である可能性があります。 Binlog syncer には、トランザクションの整合性を検出する機能が必要です。 Kingbus は、MySQL ソースコードを参照して完全に実装されたトランザクション整合性解析機能を実装します。

3.4 Binlogサーバーのコア実装

binlog サーバーはマスターの機能を実装します。スレーブが binlog サーバーとのレプリケーション接続を確立すると、スレーブは関連するコマンドを送信し、binlog サーバーはこれらのコマンドに応答する必要があります。最後に、binlog イベントがスレーブに送信されます。各スレーブに対して、binlog サーバーは goroutine を開始し、raft ログを継続的に読み取り、関連するヘッダー情報を削除し、それを binlog イベントに変換して、スレーブに送信します。