2019の9日目の記事です。serverで実行した更新をイベントという形式で出力したログ。トランザクションのコミット時に出力され、コミットの順番で1トランザクションの変更がシーケンシャルに出力されている。log)も使われている)。threadがrelay_logとして保存する。threadが読み出して適用することでMasterとSlaveのデータが同期されるという仕組みになっている。Slave間のデータ同期のためによく使われるのは準同期レプリケーションでしょう。log自体の中身に注目するので、説明は省略します。Replicationを使っている場合はこの限りではないです。statementとrowのいいところどりすべてstatementで書いても良いのではないか?と思うかもしれないが、実行時に結果が決まるようなクエリが実行される場合masterとslaveで結果が異なる可能性がある。実はnow()やrand()といった関数はreplicationのために対応されているが、推奨されないformatとなっている。rowベースでは更新された内容を記述するため、MasterとSlaveのデータが同じならば、replicationによる変更も同じ結果になるが、例えば1つのupdate文で10万行を変更した場合10万行すべての変更を1イベントとしてreplicationするため、実行が遅くなったりreplication遅延の原因になる。そこで同じ結果になることが保証される場合はstatement形式で送るなどうまくstatementとrow形式を使い分けてくれるのがmixedとなっている。baseがdefaultになっていて、今後はrowが推奨されるのかもしれない。rowで出力される場合に有効な設定となっている。imageとして記録することでレプリケーションができるようになっている。mysqlbinlogでbinlogの中身をみるbinlogの中身はMySQL標準のmysqlbinlogコマンドを利用することで確認できる。mysqlbinlogで必要な特定時間の変更分を確認したり、それらをSQLファイルとして抽出してPITRに利用したりする。binlog.000009と適当なbinlogを指定して中を確認すると以下のような出力を得ることができた。56行目あたりを見ると、DECODE-ROWSを指定しているため、コメントアウトされた状態でSQLとして復元されたINSERTクエリを確認することができる。MySQLを利用している人なら一度は使ったことがあると思うので、省略するが、詳しく知りたい人はドキュメントを参照してください。bin)という文字列から始めて、それ以降はイベント(events)という形式で更新データやメタデータを保持している。versionなら構造は一定)でheaderに含まれるtypeコードによって指定されるtypeごとにdata部の中身が変化する。5.0以降はversion4となっている。version4として変更がないのはおそらくformatの構造で、新しいeventや使われなくなったeventもあるという状態。現時点で30個以上のeventがあるがここではいくつかのイベントを紹介する。binlogのフォーマットを規定するeventbinlog自体のフォーマットはbinlogの先頭4byteの次に最初のeventとして出力されるformat_description_eventによって規定される。このeventを読むことでそのbinlogファイルのeventをパースすることができるようになる。このformat_description_eventに変更が加わるときにbinlogのversionが変更されるのだと思う。format_description_eventには以下の5つのデータが記述されている。binlog_versionserver_versioncreate_timestampheader_lengthpost_header_length実際中身をparseするにはformatされた各値を読み取る必要があるのだが、ここでは割愛する。codeから理解しながら読むしかないです。binlog_formatに関わらずDDLはSBLで出力されるので、DDLはこのeventで出力される実行自体には不要と思えるメタデータもあるが以下のような形式で最後の値として生のsql_statementが入っている。intvar_eventquery_log_eventではauto_incrementの値やlast_insert_id()を利用している場合にこれらの情報が含まれない、そこで、query_log_eventの前にintvar_eventによってこれらの値を指定する。Manualから確認できたのはこの2つの値でした。binlog_formatがrowとして出力されるログイベント)の場合に更新分が行単位で出力されるevent。deleteがそれぞれ、{write,update,delete}_rows_eventとして出力される。imageがないので、この部分がなくなる。table_map_eventRBLの場合に、table情報を適用時にマッピングするためのevent。上記の{write,update,delete}_rows_eventの前に出力され、このイベントを利用することでmasterとslaveのテーブル定義が異なる場合でもreplicationを行えるようにする役割がある。slave間でのレプリケーションについては(参考2)を参照すると理解が深まると思います。vol.12で話した、binlogの内部構造調査の内容を改めてまとめたものです。serverを実装しようかと思っていましたが、予想以上にbinlogのすべてを理解するのは難しそうだとわかりました。back(binlowを遡ることでロールバックする)を試そうとbinlogのparaserであるmybinlogを作ったりしていました。codeから必要な情報を理解することも大変です。いくつかbinlogをparseしているツールを見つけたり紹介してもらったりしたのでまた戻ってくると思います。engineの仕組みのほうが気になってしまっていて、放置気味担ってしまっていますが、この内容を読んで興味を持ってくれた方がいたらぜひ声をかけてください。2019に参加してきました。indexesMySQL8.0の機能を調べてまとめている。BY関連の新機能MySQL8.0の機能を調べてまとめている。Entriesはてなブログをはじめよう!tom__boさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。