MySQL-正しい解析行イベント

行の事件は全部で3種類あります:TALBE_MAP_EVENT、ROWS_EVENT、ROWS_QUERY_EVENT.その中のROWS_EVENTはWRITE_に分かれていますROWS_EVENT、UPDATE_ROWS_EVENT、DELETE_ROWS_EVENT.この3つは、v 0 v 1 v 2の3つのバージョンに分けられます.ロー・イベントは、データベース・ローがどのように変化しているかを示します.では、シーケンス化されたバイナリ・データによって変化した情報を解析するにはどうすればいいのでしょうか.
同期が開始されるたびに、MySQLはROTATEイベントを送信します.これは本当のROTATEイベントではありません.彼は現在のプライマリ・ライブラリのbinlogイベントのオフセット量を指摘するために使用されます.真偽ROTATEイベントを区別する方法は、0以外のフィールドを設定すべきであり、その値は0、例えばtimestampである.
ROTATEの後にFormat_が続くdescriptionイベント.この2つのフィールドは、同期されたバージョン、すべてのイベント(UNKNOWN_EVENTを除く)のヘッダ長を示す重要なフィールドです.
一度行データが変更された場合(insert,update,delete)、まずQUERYイベントが送信され、ROWS_QUERYイベント.違いは後者がMySQL 5であることである.6に導入されたばかりで、QUERYの内容が記録され、前者は「BEGIN」が記録されています(奇妙ですね).具体的にはROWSを送信するかどうかQUERYは、まずこれがROWイベントであることを確認し、次にMySQLの設定に依存します.このようなイベントは、MySQLの起動時に--binlog-rows-query-log-events， binlog_rows_query_log_events，が設定されている場合に発生します.このオプションが設定されていると5.5を使用するか、以前のライブラリから同期できないため、一般的にOFFになります.
次のイベントはTABLE_MAP.各ROWS_EVENTはテーブルの基本情報を記録しないので、データとテーブルをマッピングする必要があります.TABLE_MAPは主にこのようなマッピング関係を記録し、データベース名、テーブル名、テーブルIDを指摘し、ROWS_EVENT内のテーブルIDは、具体的なデータベース名に対応しています.もう1つの重要なフィールドは、カラムがビットマップを使用することです.いくつかのバイトで表され、どのカラムが使用されるかが示されます.各列は1ビットに対応し、0は使用されず、1は使用されます.これはもう一つの理解できない設定で、少なくとも私が見たのはすべて全1です.また、TypeとMetadataというフィールドもあり、各列のタイプ、各クラスのデータの基本情報(各クラスのデータ定義メタデータが表す意味が異なり、例えば代表長さなど)を記録します.
1つまたは複数のROWSに続くEVENT.各EVENTにはnull-bit-mapがあり、各フィールドがNULLであるかどうかを示します.NULLであれば最後の行データフィールドに記録されないからです.フィールドごとに1つで表されます.データフィールドには、特定の行データが記録されます.WRITEの場合、追加されたローが記録されます.DELETEの場合、削除されたローのIDが記録されます.UPDATEの場合は、削除したローのIDを記録してから、新しいローデータを記録します.デフォルトでは、ローIDはロー全体のデータですが、実際には、一部のデータは、プライマリ・キーのあるローがプライマリ・キーを記録すれば識別できるなど、ローを識別できる場合があります.-binlog-row-p_をオンにするとw_picpathオプションがenumerationか、セッションにbinlog_が設定されています.row_p_w_picpath
enumerationのために、全行は記録されません.このオプションは5.5以降のバージョンではサポートされていません.
最後にXIDイベントです.