MySQLで最も重要なログはbinlog（アーカイブログ）、redoログ（redoログ）、undoログです。したがって、この記事に関連する主なログはbinlogであり、Songgeが無料のときに他の2つのログが詳細に紹介されます。未来。
1. binlog
binlogは一般に中国語でアーカイブログと呼ばれます。Songgeが以前に投稿したMySQLマスタースレーブ構造を見たことがあれば、このログの印象を持っているはずです。MySQLマスタースレーブを構築するとき、binlogなしでは実行できません（ポータル：MySQL8マスタースレーブ）ステップバイステップガイドをコピーします）。
binlogは、ストレージエンジンに付属するログではなく、MySQLサーバーレイヤーのログです。すべてのDDLおよびDML（データクエリステートメントを除く）ステートメントを記録し、実行に費やされた時間を含むイベントの形式で記録します。待ってください、次のことに注意することが重要です：
- Binlogは一種の論理ログであり、特定のフィールドの+1など、SQLステートメントの元のロジックを記録します。これはREDOログの物理ログ（データページで行われた変更）とは異なることに注意してください。 。
- binlogファイルがいっぱいになると、自動的に次のログファイルに切り替わり、前のログを上書きせずに書き込みを続行します。これもREDOログとは異なります。REDOログは周期的に書き込まれます。つまり、後の書き込みで前の書き込みが上書きされる場合があります。 。入力しました。
- 一般的に、binlogを設定する場合、binlogファイルの有効期間を指定して、有効期限が切れた後、ログファイルが自動的に削除され、ストレージスペースを占有しないようにすることができます。
MySQLの公式ドキュメントの紹介によると、binlogを開いた後、パフォーマンスが約1％低下しますが、これは許容範囲内です。一般的に、binlogには2つの重要な使用シナリオがあります。
- MySQLマスター/スレーブレプリケーション：ホストでbinlogを有効にし、ホストがbinlogをスレーブに同期し、スレーブがbinlogを介してデータを同期することで、ホストとスレーブ間のデータ同期を実現します。
- MySQLデータリカバリ。mysqlbinlogツールをbinlogファイルと組み合わせて使用することにより、過去の特定の時点までデータをリカバリできます。
2.binlogを構成します
デモンストレーションの便宜のために、SonggeはここでDockerにMySQLをインストールしました。これを例として取り上げて、今日のデモンストレーションを開始しましょう。dockerの使用法がわからない場合は、公式アカウントのバックグラウンドでdockerに返信できます。SongGeによって作成されたチュートリアルがあります。
まず、MySQLをdockerにインストールしてからコンテナーに入り、次のコマンドを使用してbinlogが有効になっているかどうかを確認します。
このOFFは、binlogが開いていない状態で閉じていることを意味します。
binlogログの形式は、次のコマンドで表示できます。
ご覧のとおり、このbinlogの形式はROWです。
ここには、binlogの形式に関する問題があります。
2.1binlogの形式
binlogには3つの形式があります。
- ステートメント（ステートメントベースのレプリケーション、SBR）：データを変更するSQLの各部分は、binlogに記録されます。
- 行（行ベースのレプリケーション、RBR）：SQLステートメントのコンテキスト情報を記録せず、変更されたレコードのみを保存します。
- 混合（混合ベースのレプリケーション、MBR）：ステートメントと行の混合。
2.1.1ステートメント
ステートメントモードは、実行されたSQLのみを記録し、データの各行の変更を記録する必要がないため、binlogのログ量が大幅に削減され、多数のIO操作が回避され、システムのパフォーマンスが向上します。
ただし、ステートメントモードはSQLのみを記録し、一部のSQLに関数が含まれている場合、一貫性のない実行結果が発生する可能性があります。たとえば、uuid()関数は実行されるたびにランダムな文字列を生成し、uuidをマスターに記録します。スレーブに同期して再度実行すると、別の結果が得られます。
したがって、ステートメント形式を使用すると、データの整合性に問題が発生します。
2.2.2行
MySQL 5.1.5以降、binlogはRow形式を導入しました。Row形式はSQLステートメントのコンテキスト関連情報を記録しませんが、特定のレコードがどのように変更されたかを記録するだけで済みます。
行形式のログコンテンツには、データ変更の各行の詳細が明確に記録されるため、ステートメントのデータを正常にコピーできない状況は発生しません。
ただし、Row形式にも大きな問題があります。つまり、特にバッチ更新、テーブル全体の削除、テーブルの変更などの操作では、ログの量が多すぎます。ログにはIOパフォーマンスの問題もあります。
2.2.3混合
MySQL 5.1.8以降、MySQLはMixed形式を導入しました。これは、実際にはステートメントと行の組み合わせです。
混合モードでは、システムはステートメントと行のどちらを使用するかを自動的に決定します。一般的なステートメントの変更には、ステートメント形式を使用してbinlogを保存します。マスタースレーブレプリケーションを正確に完了できない一部のステートメント操作では、行形式を使用してbinlogを保存します。
混合モードでは、MySQLは実行される特定のSQLステートメントごとに異なる方法でログ形式を処理します。つまり、ステートメントと行のどちらかを選択します。
2.2構成
次に、binlogの構成を見てみましょう。
2.2.1binlogを有効にする
binlogを有効にするには、コンテナの/etc/mysql/mysql.conf.dディレクトリ。
この構成ファイルに対して、次の変更を行います。
# 这个参数表示启用 binlog 功能，并指定 binlog 的存储目录
log-bin=javaboy_logbin
# 设置一个 binlog 文件的最大字节
# 设置最大 100MB
max_binlog_size=104857600
# 设置了 binlog 文件的有效期（单位：天）
expire_logs_days = 7
# binlog 日志只记录指定库的更新（配置主从复制的时候会用到）
#binlog-do-db=javaboy_db
# binlog 日志不记录指定库的更新（配置主从复制的时候会用到）
#binlog-ignore-db=javaboy_no_db
# 写缓存多少次，刷一次磁盘，默认 0 表示这个操作由操作系统根据自身负载自行决定多久写一次磁盘
# 1 表示每一条事务提交都会立即写磁盘，n 则表示 n 个事务提交才会写磁盘
sync_binlog=0
# 为当前服务取一个唯一的 id（MySQL5.7 之后需要配置）
server-id=1
Song Geは、彼の視線の中で各構成の意味をすでに説明しています。以下のスクリーンショット：
構成が完了したら、次のコマンドを実行してmysqlコンテナーを再起動します（mysql1はここでのコンテナーの名前です）。
docker restart mysql1
再起動後、再度実行しshow variables like 'log_bin%';て、binlogが開かれていることを確認します。
log_bin変数に加えて、注意に値する2つの変数名があります。
- log_bin_basename：これは、将来生成されるbinlogログファイルの名前プレフィックスです。つまり、これまでに確認した構成に従って、将来生成されるbinlogログファイルの名前は、
javaboy_logbin.xxxすべてのDDLとDMLステートメント。イベント。 - log_bin_index：これはbinlogのインデックスファイルであり、複数のbinlogが存在する可能性があるため、すべてのbinlogディレクトリを保存します。現在の
javaboy_logbin.indexファイル：
ご覧のとおり、現在、logbinファイルは1つだけです。
2.2.2binlog_formatを変更する
binlog_formatを変更するには、いくつかの異なる方法があります。
現在のセッションのbinlog_formatを変更します。この変更は、現在のセッションに対してのみ有効です。
グローバルbinlog_formatを変更することもできます。これは、MySQLの再起動時に無効になります。
これを一度だけ実行したい場合は、/etc/mysql/mysql.conf.d/mysqld.cnf構成ます。構成ファイルに、次のようにbinlog_formatオプションを追加します。
これは永続的な変更です。
3.一般的なbinlog操作
次に、いくつかの一般的なbinlog操作コマンドを紹介します。
- すべてのbinlogログを表示する
binlogログリストは次の方法で表示できます。
show master logs;
ご覧のとおり、現在、ログファイルは1つしかなく、ファイル名はですjavaboy_logbin.000001。File_sizeは、このファイルが占めるバイトサイズが154であることを示しています。
- マスターステータスの表示
このコマンドは、次のようにMySQLマスタースレーブを構築するときによく使用されます。
このとき、最新のbinlogログファイル名と最後の操作イベントのPosition値を確認できます（この値の使用方法については、後で詳しく説明します）。
- binlogを更新
通常、binlogがいっぱいになると、自動的に次のbinlogに切り替わり、書き込みが開始されますが、flush logsコマンド。binlogを手動で更新すると、新しいbinlogログファイルが生成されます。binlogログは新しいファイルに記録されます。次のように：
上図からわかるように、ログを更新した後、ログshow master logsをし、新しいログファイルが作成されていることをshow master status確認し、最新のログファイル情報を確認し、変更されていることを確認しますjavaboy_logbin.000002。
- binlogをリセット
reset masterbinlogログファイルをリセットして000001からログを再開できますが、現在のホストで1つ以上のスレーブが実行されている場合、コマンドは実行されません（スレーブはbinlogを使用してデータベースの同期を行うため、ホストはbinlogを空にします） 、およびbinlogが見つからないというエラーがオポチュニティから報告されます）。
- binlogを表示
binlogはバイナリログファイルであるため、直接開くと、間違いなく読み取ることができません。
有用な情報は見当たりませんでした。
binlogを表示するために、MySQLには2つの公式ツールが用意されています。それらを1つずつ見ていきましょう。最初のツールは、次のようなmysqlbinlogコマンドです。
散らかっているように見えますが、よく見ると実は痕跡があります。ここに新しくインストールしたデータベースなので、javaboyという名前のライブラリを作成し、userという名前のテーブルを作成して2つのデータを追加しましたが、他に何もしなかったので、実際にライブラリのスクリプトを作成しました。さまざまなドキュメントで。
生成されたログファイルには、ログファイルのposポイントであるend_log_posがあります。これは、将来のデータ回復に役立ちます。
ただし、この表示方法は人道的ではありません。binlogはイベントごとにログを記録すると言うので、イベントごとにログを表示できれば、はるかに優れています。次のコマンドを見てみましょう。
show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];
これは、イベントの方法でbinlogを表示することを意味します。これには、いくつかのパラメーターが含まれます。
- log_name：表示するbinlogログファイルの名前を指定できます。指定しない場合は、最も古いbinlogファイルを表示することを意味します。
- pos：表示を開始するposポイントから、binlogに記録されたすべての操作にposポイントがあります。これは、実際には、ログの表示を開始する操作を指定することと同じです。指定しない場合、binlogの最初から表示を開始します。
- オフセット：これはオフセットです。指定されていない場合、デフォルトは0です。
- row_count：表示する行数。指定しない場合は、すべての行を表示します。
簡単な例を見てみましょう。
show binlog events in 'javaboy_logbin.000001';
これははるかに明確で、次のような以前のすべての操作を確認できます。
- ライブラリはPos219-322の間に作成されました。
- Pos387-537の間にテーブルが作成されました。
- Pos677-780の間にレコードが追加されました。
- …
これは実際には行形式のbinlogです。
5.まとめ
さて、今日の記事は主に私の友人とMySQL binlogログを共有することであり、主にいくつかの理論的知識です。次の記事では、Songgeは2つの特定のケースを通して異なるbinlog_formatの問題を示します〜