MySQL Binlog ストレージ システムのアーキテクチャを設計する方法

1. キングバスの紹介

1.1 キングバスとは何ですか?

Kingbus は、raft の強力な整合性プロトコルに基づいた分散 MySQL バイログ ストレージ システムです。 MySQL スレーブとして機能して、実際のマスターからバイナリログを同期し、分散クラスターに保存できます。同時に、クラスター内のバイナリログを他のスレーブに同期するための MySQL マスターとしても機能します。 kingbus には次の特徴があります:

MySQL レプリケーション プロトコルと互換性があり、Gtid を介してマスター上のバイナリ ログを同期し、スレーブが Gtid を介してキングバスからバイナリ ログを取得することをサポートします。

リージョン間のデータ レプリケーション。Kingbus は、raft プロトコルを介したリージョン間のデータ レプリケーションをサポートします。クラスターに書き込まれるバイナリログ データは、複数のノード間で強い一貫性があることが保証され、バイナリログの順序はマスター上の順序と完全に一致します。

高可用性。Kingbus は Raft の強力なコンセンサス プロトコルに基づいて構築されているため、クラスター内のノードの半分以上が存続している場合、ビンログのプルおよびプッシュ サービス全体の高可用性を実現できます。

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

Kingbus はマスターのネットワーク送信トラフィックを削減できます。 1 つのマスターと複数のスレーブを持つレプリケーション トポロジでは、マスターは各スレーブに binlog を送信する必要があります。スレーブが多すぎると、ネットワーク トラフィックがマスターのネットワーク カードの上限に達する可能性があります。たとえば、マスターが大きなテーブルやオンライン DDL の削除などの操作を実行すると、大量のバイナリログ イベントが瞬時に生成される可能性があり、10 台のスレーブがマスターに接続されている場合、マスター上のネットワーク カード トラフィックは 10 倍に増幅されます。 。マスターがギガビット ネットワーク カードを使用している場合、10MB/秒を超えるトラフィックが生成されると、ネットワーク カードがいっぱいになる可能性があります。 kingbus 経由でマスターに接続すると、スレーブを複数のマシンに分散して送信トラフィックのバランスをとることができます。

マスター フェイルオーバー プロセスを簡素化するには、キングバスに接続されているスレーブをマスターに昇格させ、キングバスを新しいマスターにリダイレクトするだけで済みます。他のスレーブは引き続きキングバスに接続されており、レプリケーション トポロジは変更されません。

マスターがバイナリログファイルを保存するために使用するスペースを節約します。一般に、MySQL はより高価な SSD を使用するため、binlog ファイルが多くのスペースを占有する場合は、MySQL に保存されるデータを減らす必要があります。すべてのビンログを kingbus

に保存することで、マスターに保存されるビンログ ファイルの数を減らすことができます。 異種レプリケーションをサポートします。 Alibaba のオープンソース Canal を介して kingbus に接続します。kingbus は継続的に binlog を canal にプッシュします。canal は binlog を受信し、それを Kafka メッセージ キューにプッシュし、最後に HBase に保存します。ビジネス部門は Hive を介して SQL を直接記述し、リアルタイムを実現します。ビジネスの分析。

2. Kingbus の全体的なアーキテクチャ

kingbus の全体的な構造を次の図に示します。 ストレージは raft ログ エントリとメタデータの保存を担当します。Kingbus では、raft ログと mysql binlog は統合されています。これらは異なるヘッダー情報によって区別されます。raft ログのデータ部分は binlog イベントであるため、2 つのタイプを保存する必要はありませんログを個別に保存できるので、保管スペースを節約できます。なぜなら、kingbus は、raft ノードの投票情報やいくつかの特別な binlog イベント (FORMAT_DESCRIPTION_EVENT) の特定の内容など、いくつかのメタ情報を保存する必要があるからです。

Raft は、etcd raft ライブラリを使用して、kingbus クラスターのリード選出、ログ レプリケーション、およびその他の機能を複製します。

Binlog syncer は Raft クラスターの Lead ノードでのみ実行され、クラスター全体で 1 つのみの syncer が存在します。シンサーはスレーブであるふりをして、マスターへのマスター/スレーブ レプリケーション接続を確立します。マスターは、シンサーによって送信された Executed_gtid_set に基づいて、シンサーが受け入れた binlog イベントをフィルターし、シンサーが受け入れていない binlog イベントのみを送信します。このレプリケーション プロトコルは、MySQL のマスター/スレーブ レプリケーション メカニズムと完全な互換性があります。 syncer は binlog イベントを受信すると、binlog イベント タイプに従っていくつかの処理を実行し、binlog イベントをメッセージにカプセル化して raft クラスターに送信します。 raft アルゴリズムを使用すると、このバイナリログ イベントを複数のノードに保存し、強い一貫性を実現できます。

binlog サーバーは、レプリケーション プロトコルを実装するマスターです。実際のスレーブは、binlog サーバーによって監視されているポートに接続できます。binlog サーバーは、binlog イベントをスレーブに送信します。binlog イベントの送信プロセス全体は、MySQL を参照して実装されます。レプリケーションプロトコル。 binlog イベントがスレーブに送信されない場合、binlog サーバーは定期的にハートビート イベントをスレーブに送信して、レプリケーション接続を維持します。

API サーバーは、以下を含む kingbus クラスター全体の管理を担当します:

Raft クラスターのメンバーシップ操作、クラスターのステータスの表示、ノードの追加、ノードの削除、ノード情報の更新など。

binlog syncer 関連の操作: binlog syncer を開始し、binlog syncer を停止し、binlog syncer のステータスを確認します。

binlog サーバー関連の操作、binlog サーバーの開始、binlog サーバーの停止、および binlog サーバーのステータスの確認。サーバー層の各種異常はraft層には影響せず、サーバーはオンデマンドで起動・停止できるプラグインとして捉えることができます。将来的に KingBus を拡張する場合は、関連するロジックを備えたサーバーを実装するだけで済みます。たとえば、kafka プロトコル サーバーを実装すると、kafka クライアントを介して kingbus 内のメッセージを消費できます。

3.kingbus コアの実装

3.1 ストレージのコア実装

ストレージには 2 つのログ形式があり、1 つは raft アルゴリズムによって生成および使用される raft ログ (以下、raft ログと呼びます)、もう 1 つはユーザー形式のログ (つまり、mysql binlog イベント) です。 。ストレージの設計では、2 つのログ フォームが 1 つのログ エントリに結合されます。ヘッダー情報の違いによってのみ区別されます。次の図に示すように、ストレージはデータ ファイルとインデックス ファイルで構成されます。 セグメントは固定サイズ(1GB)で追加書き込みのみ可能で、名前はfirst_raft_index-last_raft_indexとなり、セグメントのraftインデックスの範囲を示します。

最後のセグメントのみ書き込み可能で、そのファイル名は first_raft_index-inprogress であり、他のセグメントは読み取り専用です。

読み取り専用セグメントと対応するインデックス ファイルは、mmap を通じて書き込みおよび読み取りが行われます。

最後のセグメントのインデックス コンテンツは、ディスクとメモリの両方に保存されます。インデックスの読み取りには、メモリからの読み取りのみが必要です。

3.2 etcd raft ライブラリの使用

Etcd raft ライブラリは、適用されたログ、コミットされたエントリなどを処理するときはシングルスレッドです。特定の関数については、リンクを参照してください。この関数の処理時間は、できるだけ短くする必要があります。処理時間がラフト選出時間を超えると、クラスターが再選出されます。この点は特に注意が必要です。

3.3 binlog syncerのコア実装

binlog syncer の主なジョブは次のとおりです:

バイナリログイベントをプルします

バイナリログイベントを解析して処理します

binlog イベントを raft クラスターに送信します。パイプライン機構を使用することでプロセス全体の処理速度を向上させることができるのは当然ですが、Kingbus では各ステージの処理に別個のゴルーチンを使用し、異なるステージをパイプラインで接続します。 binlog syncer は binlog イベントを 1 つずつ受信するため、syncer はトランザクションの整合性を保証できません。syncer がハングした後、マスターに再接続する必要がある可能性があります。この時点で、最後のトランザクションが不完全である可能性があります。binlog syncer は、トランザクションが完了していないことを確認する必要があります。 kingbus は、独自の機能を備えたトランザクション整合性分析機能を実装しており、これは MySQL ソース コードを参照して完全に実装されています。

3.4 binlog サーバーのコア実装

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

以上がMySQL Binlog ストレージ システムのアーキテクチャを設計する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。