MySQLを監視するためのbinlogログ解析ツールの詳しい説明:Canal

Canal は、Java を使用して開発された Alibaba のオープンソース プロジェクトです。主な目的は、MySQL データベースの増分ログ分析に基づいて、増分データのサブスクリプションと消費を提供することです。現在は主に MySQL をサポートしています。

GitHub アドレス: https://github.com/alibaba/canal

Canal の内部原理を紹介する前に、まず MySQL マスター/スレーブ同期の原理を理解しましょう。

MySQL マスターは、バイナリログ メカニズムを開始し、データの変更をバイナリ ログに書き込みます (これはバイナリ ログ イベントと呼ばれ、show binlog events を使用して表示できます)。MySQL スレーブ (I/O スレッド) は、マスターのバイナリ ログ イベントをリレー ログにコピーします。MySQL スレーブ (SQL スレッド) は、リレー ログ内のイベントを再生して、データの変更を自身のデータに反映します。

Canal の仕組み:

Canal は MySQL スレーブのインタラクション プロトコルをシミュレートし、MySQL スレーブのふりをして、ダンプ プロトコルを MySQL マスターに送信します。MySQL マスターはダンプ要求を受信し、バイナリ ログをスレーブ (つまり、Canal) にプッシュし始めます。Canal はバイナリ ログ オブジェクト (元々はバイト ストリーム) を解析します。

つまり、Canal は MySQL スレーブになることをシミュレートし、MySQL binlog ログをリッスンすることでデータを取得します。 MySQL binlog を行モードに設定すると、実行された各挿入/更新/削除スクリプトと、変更前後のデータを取得できます。この機能に基づいて、Canal は MySQL データの変更を効率的に取得できます。運河建築:

注: サーバーは、JVM インスタンスとデータ キューに対応する Canal 実行インスタンスを表します (1 つのサーバーは 1..n 個のインスタンスに対応します)

EventParser: データソースへのアクセス、スレーブプロトコルのシミュレート、マスターとの対話、プロトコル解析

EventSink: 主にデータのフィルタリング、処理、配信のためのパーサーおよびストアコネクタ

EventStore: ストレージを担当

MemoryMetaManager: 増分サブスクリプションおよび消費情報マネージャー

イベントパーサーの設計:

パーサープロセス全体は、おおよそ次の手順に分けられます。

接続は、最後に成功した解析のログの位置を取得します (最初の起動の場合は、最初に指定された位置または現在のデータベースの binlog ログの位置を取得します)。接続は接続を確立し、MySQL マスターに BINLOG_DUMP 要求を送信します。MySQL はバイナリ ログのプッシュを開始します。受信したバイナリ ログは BinlogParser を通じて解析され、特定の情報が追加されます。たとえば、フィールド名、フィールドタイプ、主キー情報、符号なしタイプの処理などを追加します。解析されたデータをEventSinkコンポーネントに渡してデータを保存します（保存が成功するまでこれはブロック操作です）。再起動後も増分サブスクリプションを続行できるように、バイナリログの位置を定期的に記録します。

同期する必要があるマスター ノードがクラッシュした場合でも、単一点障害を回避するために、他のスレーブ ノードからの binlog ログを引き続き同期できます。イベントシンクの設計:

EventSink の主な機能は次のとおりです。

データ フィルタリング: ワイルドカード フィルタリング モード、テーブル名、フィールド コンテンツなどをサポートします。

データルーティング/配布: 1:n を解決します (1 つのパーサーが複数のストアに対応)

データのマージ: n:1 を解決 (複数のパーサーが 1 つのストアに対応)

データ処理：店舗に入る前の追加処理、例えば1：nビジネスへのデータ結合など

データベースリソースを合理的に使用するために、一般的には共通業務をスキーマに従って分離し、MySQL上位層またはDAO層でデータソースルーティングを実行して、データベースの物理的な場所が開発に与える影響を遮断します。Alibabaは主にcobar/tddlを使用してデータソースルーティングの問題を解決します。したがって、通常、データベース インスタンスには複数のスキーマがデプロイされ、各スキーマは 1 つ以上のビジネス パーティによって監視されます。

データn:1サービス

同様に、ビジネスのデータ規模が一定レベルに達すると、水平分割と垂直分割の問題が必然的に発生します。これらの分割されたデータを処理する必要がある場合、処理のために複数のストアをリンクする必要があります。消費サイトが複数になり、データ消費の進行が可能な限り秩序正しくなることを保証できなくなります。したがって、特定のビジネス シナリオでは、タイムスタンプ/グローバル ID に従って並べ替えやマージするなど、分割された増分データをマージする必要があります。イベントストアデザイン:

メモリ モードなどの複数のストレージ モードをサポートします。メッセージの保存にはメモリ リング設計が使用され、これは Disruptor の RingBuffer の実装アイデアに基づいています。リングバッファ設計:

3 つのカーソルが定義されています。

put: データ保存用のシンクモジュールの最後の書き込み位置（同期的にデータを書き込むカーソル）

get: データサブスクリプションによって取得された最後の抽出位置（同期取得されたデータのカーソル）

ack: 成功したデータ消費の最後の消費場所

Disruptor の RingBuffer の実装を参考にして、RingBuffer を整理してみましょう。

実装に関する注意:

put/get/ack カーソルは増分に使用され、long 型で保存されます。 3 つの関係は、モジュロまたは & 演算を介して、put>=get>=ackbuffer get 演算になります。 (& 演算: cusor & (size - 1)、size は 2 の指数である必要があり、より効率的です)

インスタンス設計:

インスタンスは、EventPaser、EventSink、EventStore などのコンポーネントを含む、実際に実行されているデータ キューを表します。 CanalInstanceGenerator は、主に構成管理方法を考慮して抽象化されています。

マネージャー方式: 独自の内部 Web コンソール/マネージャー システムに接続します。 （現在は主に社内で使用）

Spring メソッド: Spring XML + プロパティに基づいて定義し、Spring 構成を構築します。サーバー設計:

サーバーは Canal の実行インスタンスを表します。コンポーネントベースの使用を容易にするために、Embeded (埋め込み) と Netty (ネットワーク アクセス) の 2 つの実装が抽象化されています。

増分サブスクリプション/消費設計:

具体的なプロトコル形式については、CanalProtocol.proto を参照してください。データオブジェクト形式: EntryProtocol.proto

エントリ
  ヘッダ
    logfileName [binlogファイル名]
    logfileOffset [binlog の位置]
    executeTime [binlog に記録された変更のタイムスタンプ]
    schemaName [データベースインスタンス]
    tableName [テーブル名]
    eventType [挿入/更新/削除タイプ]
  entryType [トランザクション ヘッダー BEGIN/トランザクション テール END/データ ROWDATA]
  storeValue [バイトデータ、拡張可能、対応する型はRowChange]

行変更
isDdl [テーブルの作成/削除などのDDL変更操作であるかどうか]
sql [特定の ddl sql]
rowDatas [特定の挿入/更新/削除変更データ、複数可能、1 つの binlog イベントはバッチ処理などの複数の変更に対応できます]
beforeColumns [列タイプの配列]
afterColumns [列タイプの配列]

カラム
インデックス [列番号]
sqlType [JDBCタイプ]
名前 [列名]
isKey [主キーかどうか]
更新しました [何か変更がありましたか?]
isNull [値はnullか]
値 [具体的な内容、テキストであることに注意]

上記についての補足説明：

1. データベース変更前後のフィールド内容を提供し、binlogにない名前、isKeyなどの情報を補完します。

2. DDL変更ステートメントを提供できる

管状HAメカニズム:

Canal の HA 実装メカニズムは Zookeeper に依存しており、主に Canal サーバーと Canal クライアントの HA に分かれています。 Canal サーバー: MySQL ダンプのリクエスト数を減らすために、各サーバー上のインスタンスのうち 1 つだけが同時に実行状態になり、他のインスタンスはスタンバイ状態になります。

キャナル クライアント: 順序を保証するために、インスタンスは一度に 1 つのキャナル クライアントによってのみ取得/確認/ロールバックできます。そうでない場合、クライアントによる受信順序は保証されません。 Canal Server HA アーキテクチャ図:

一般的な手順:

• Canal サーバーが Canal インスタンスを起動する場合、最初に Zookeeper で判定を開始しようとします (実装: EPHEMERAL ノードを作成し、それを正常に作成したユーザーが起動できます)
• Zookeeper ノードが正常に作成されると、対応する Canal サーバーは対応する Canal インスタンスを起動します。正常に作成されなかった Canal インスタンスはスタンバイ状態になります。
• Zookeeper は、Canal サーバー A によって作成されたノードが消えたことを検出すると、すぐに他の Canal サーバーに通知して手順 1 を再度実行し、インスタンスを起動する Canal サーバーを再選択します。
• Canal クライアントが接続するたびに、最初に現在 Canal インスタンスを開始している Zookeeper を尋ね、次にその Zookeeper とのリンクを確立します。リンクが利用できない場合は、再度接続を試みます。

Canal クライアント方式は Canal サーバー方式に似ており、制御のために EPHEMERAL ノードを優先する Zookeeper 方式も使用します。

MySQLを監視するためのbinlogログツールCanalの詳細な分析に関するこの記事はこれで終わりです。より関連性の高いMySQL binlogログコンテンツについては、123WORDPRESS.COMの以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも123WORDPRESS.COMを応援してください。