MySQL の binlog ログファイルの詳細な紹介-mysql チュートリアル-php.cn

ホームページ

データベース

mysql チュートリアル

MySQL の binlog ログファイルの詳細な紹介

不言

Oct 17, 2018 pm 05:06 PM

binlogmysql

この記事では、MySQL の binlog ログファイルについて詳しく説明します。必要な方は参考にしていただければ幸いです。

MySQL の binlog ログファイルには、データベーステーブルのすべての変更操作が記録されます。この記事では、MySQL binlog に関連する知識と、binlog を使用してデータベースデータを復元またはフラッシュバックする方法を簡単にまとめます。

STATEMENT 形式の binlog

binlog を有効にするには、MySQL の起動時に --log-bin パラメータを渡す必要があります。または、MySQL 構成ファイル /etc/my.cnf で log_bin を設定して、binlog を有効にすることもできます。 MySQL 5.7 以降では、binlog を有効にした後、 --server-id パラメータも指定する必要があります。指定しないと、MySQL サーバーは起動に失敗します。

binlog_format は、STATEMENT、ROW、および MIXED の 3 つの形式をサポートします。MySQL 5.5 および 5.6 はデフォルトで STATEMENT になり、MySQL 5.7.7 ではデフォルトで ROW が始まります。のように SQL は、UUID()、RAND()、VERSION() およびその他の関数を使用するか、STATEMENT に基づいてストアドプロシージャ、カスタム関数を使用します。マスターとスレーブがレプリケートされると安全ではありません (多くの人は NOW()、CURRENT_TIMESTAMP、およびこれらの関数も安全ではないと考えているかもしれませんが、実際には安全です) [doc1, ドキュメント2]。 ROW に基づくマスター/スレーブレプリケーションは、最も安全なレプリケーション方法です。

次に、STATEMENT 形式の binlog を見てみましょう。/etc/my.cnf ファイルの変更された内容は次のとおりです。

server_id = 1
log_bin = mysql-bin
binlog_format = STATEMENT
binlog_row_image=FULL

MySQL を再起動した後、データディレクトリ datadir の下にあります。 /var/lib /mysql/ など、対応する binlog ファイル mysql-bin.index および mysql-bin.000001 が生成されます。 .index 接尾辞が付いたファイルには、すべての binlog ファイル名が保存されます。 mysql-bin.000001 ファイルには、binlog コンテンツが記録されます。 MySQL が起動またはログをフラッシュするたびに、シーケンス番号に従って新しいログファイルが作成されます。さらに、ログファイルのサイズが max_binlog_size を超えると、新しいログファイルも作成されます。

次に、binlog 関数を試してみましょう。 testdb ライブラリに hello テーブルがあり、特定の行が変更されたとします。

mysql> select * from hello;
+----+-------+
| id | name  |
+----+-------+
|  1 | Andy  |
|  2 | Bill  |
|  3 | Candy |
+----+-------+
4 rows in set (0.00 sec)

mysql> update hello set name = 'Will' where id = 3;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

binlog はバイナリファイルであり、これを表示するには mysqlbinlog (doc, man) コマンドを使用する必要があります。

$ sudo mysqlbinlog /var/lib/mysql/mysql-bin.000001  # 直接在 mysql 服务器上读取 binlog 文件
$ mysqlbinlog -R -h192.168.2.107 -uroot -p123456 mysql-bin.000001  # 或者，远程读取 binlog 文件

更新の実行新しく追加された binlog ファイルの内容は次のとおりです。

# at 154
#180617 22:47:49 server id 1  end_log_pos 219 CRC32 0x4bd9d69b     Anonymous_GTID    last_committed=0    sequence_number=1    rbr_only=no
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
#180617 22:47:49 server id 1  end_log_pos 302 CRC32 0x476fafc9     Query    thread_id=2    exec_time=0    error_code=0
SET TIMESTAMP=1529246869/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 302
#180617 22:47:49 server id 1  end_log_pos 423 CRC32 0x7f2c2c7a     Query    thread_id=2    exec_time=0    error_code=0
use `testdb`/*!*/;
SET TIMESTAMP=1529246869/*!*/;
update hello set name = 'Will' where id = 3
/*!*/;
# at 423
#180617 22:47:49 server id 1  end_log_pos 454 CRC32 0x68da744a     Xid = 12
COMMIT/*!*/;

ROW 形式の binlog

/etc/my の binlog_format を変更します。 cnf を ROW にコピーし、MySQL を再起動します。形式が変更されると、新しい binlog ファイル mysql-bin.000002 が生成されます。

mysql> show create table hello;
+-------+-------------------------------------------------------------------------+
| Table | Create Table
+-------+-------------------------------------------------------------------------+
| hello | CREATE TABLE `hello` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8mb4 |
+-------+-------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> select * from hello where id;
+----+------+
| id | name |
+----+------+
|  1 | Andy |
|  2 | Lily |
|  3 | Will |
+----+------+
1 row in set (0.00 sec)

mysql> update hello set name = 'David' where id = 3;
Query OK, 1 row affected (0.02 sec)
Rows matched: 1  Changed: 1  Warnings: 0

ROW 形式でバイナリログを表示するには、 sudo mysqlbinlog -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000002 コマンドを使用する必要があります。更新実行後に新しく追加された対応するバイナリコンテンツ:

# at 154
#180617 22:54:13 server id 1  end_log_pos 219 CRC32 0x2ce70d4d     Anonymous_GTID    last_committed=0    sequence_number=1    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 219
#180617 22:54:13 server id 1  end_log_pos 293 CRC32 0x8183fddf     Query    thread_id=2    exec_time=0    error_code=0
SET TIMESTAMP=1529247253/*!*/;
SET @@session.pseudo_thread_id=2/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8 *//*!*/;
SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
BEGIN
/*!*/;
# at 293
#180617 22:54:13 server id 1  end_log_pos 346 CRC32 0x0fc7e1a4     Table_map: `testdb`.`hello` mapped to number 110
# at 346
#180617 22:54:13 server id 1  end_log_pos 411 CRC32 0xb58e729d     Update_rows: table id 110 flags: STMT_END_F
### UPDATE `testdb`.`hello`
### WHERE
###   @1=3
###   @2='Will'
### SET
###   @1=3
###   @2='David'
# at 411
#180617 22:54:13 server id 1  end_log_pos 442 CRC32 0xef964db8     Xid = 13
COMMIT/*!*/;

次の SQL が実行された場合:

mysql> insert hello (name) values ('Frank');
Query OK, 1 row affected (0.02 sec)

対応する生成されたバイナリコンテンツ:

# at 442
#180617 22:55:47 server id 1  end_log_pos 507 CRC32 0x79de08a7     Anonymous_GTID    last_committed=1    sequence_number=2    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 507
#180617 22:55:47 server id 1  end_log_pos 581 CRC32 0x56f9eb6a     Query    thread_id=2    exec_time=0    error_code=0
SET TIMESTAMP=1529247347/*!*/;
BEGIN
/*!*/;
# at 581
#180617 22:55:47 server id 1  end_log_pos 634 CRC32 0xedb73620     Table_map: `testdb`.`hello` mapped to number 110
# at 634
#180617 22:55:47 server id 1  end_log_pos 684 CRC32 0x525a6a70     Write_rows: table id 110 flags: STMT_END_F
### INSERT INTO `testdb`.`hello`
### SET
###   @1=4
###   @2='Frank'
# at 684
#180617 22:55:47 server id 1  end_log_pos 715 CRC32 0x09a0d4de     Xid = 14
COMMIT/*!*/;

次の SQL が実行された場合:

mysql> delete from hello where id = 2;
Query OK, 1 row affected (0.02 sec)

対応する生成された binlog コンテンツ:

# at 715
#180617 22:56:44 server id 1  end_log_pos 780 CRC32 0x9f52450e     Anonymous_GTID    last_committed=2    sequence_number=3    rbr_only=yes
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 780
#180617 22:56:44 server id 1  end_log_pos 854 CRC32 0x0959bc8d     Query    thread_id=2    exec_time=0    error_code=0
SET TIMESTAMP=1529247404/*!*/;
BEGIN
/*!*/;
# at 854
#180617 22:56:44 server id 1  end_log_pos 907 CRC32 0x2945260f     Table_map: `testdb`.`hello` mapped to number 110
# at 907
#180617 22:56:44 server id 1  end_log_pos 956 CRC32 0xc70df255     Delete_rows: table id 110 flags: STMT_END_F
### DELETE FROM `testdb`.`hello`
### WHERE
###   @1=2
###   @2='Bill'
# at 956
#180617 22:56:44 server id 1  end_log_pos 987 CRC32 0x0c98f18e     Xid = 15
COMMIT/*!*/;

binlog 増分リカバリを使用する

MySQL 論理バックアップは、通常、完全バックアップと増分バックアップを組み合わせて使用します。 mysqldump 定期的にデータベースを完全にバックアップし、binlog を使用して増分データを保存します。データを復元する場合、mysqldump によってバックアップされたデータはバックアップ時点に復元されます。データベースがバックアップ時点から現在までに増分変更された場合、binlog 内の増分データは mysqlbinlog を通じてデータベースに復元されます。次に、mysqldump を使用してデータベースを次の場所に復元したと仮定します。

mysql> select * from hello;
+----+------+
| id | name |
+----+------+
|  1 | Andy |
|  2 | Lily |
|  3 | Will |
+----+------+
3 rows in set (0.00 sec)

その後に実行された SQL:

update hello set name = 'David' where id = 3;
insert hello (name) values ('Frank');
delete from hello where id = 2;

STATEMENT または ROW のいずれを使用しても、mysqlbinlog コマンドはデータベースに binlog を段階的に復元できます [doc] ] 。

binlog を観察すると、最初の更新 hello set name = 'David' where id = 3; から最後の delete from hello where id = 2; までの時間が「2018-06」から始まっていることがわかります。 -17 22:54:13」から「2018-06-17 22:56:44」に変更するため、リカバリ時点に基づくと、コマンドは次のようになります:

$ sudo mysqlbinlog --start-datetime="2018-06-17 22:54:13" --stop-datetime="2018-06-17 22:56:44" mysql-bin.000002 | mysql -uroot -p123456

binlog'イベント位置番号は「154」から「956」までですが、位置ポイントの指定には --start-position と --stop-position が使用されることに注意してください。 range は論理的に start に対応するため、ポイントインタイムリカバリに基づくと、コマンドは次のようになります。

$ sudo mysqlbinlog --start-position=154 --stop-position=957 mysql-bin.000002 | mysql -uroot -p123456

いずれかの方法で実行すると、データは次の場所に復元できます。

mysql> select * from hello;
+----+-------+
| id | name  |
+----+-------+
|  1 | Andy  |
|  3 | David |
|  4 | Frank |
+----+-------+
3 rows in set (0.00 sec)

binlog2sql

binlog2sql を使用したフラッシュバック (Dianping.com の DBA である Cao Danfeng が作成)。 binlog2sql は、MySQL binlog から必要な SQL を解析します。オプションに応じて、元の SQL、ロールバック SQL、主キーを削除した INSERT SQL などを取得できます。 binlog2sql では、基礎となる実装は python-mysql-replication に依存しており、これにより MySQL レプリケーションプロトコルと binlog 形式の解析が完了します。

$ python binlog2sql/binlog2sql.py -h192.168.2.107 -uroot -p123456 --start-position=154 --stop-position=957 --start-file='mysql-bin.000002'
UPDATE `testdb`.`hello` SET `id`=3, `name`='David' WHERE `id`=3 AND `name`='Will' LIMIT 1; #start 4 end 411 time 2018-06-17 22:54:13
INSERT INTO `testdb`.`hello`(`id`, `name`) VALUES (4, 'Frank'); #start 442 end 684 time 2018-06-17 22:55:47
DELETE FROM `testdb`.`hello` WHERE `id`=2 AND `name`='Bill' LIMIT 1; #start 715 end 956 time 2018-06-17 22:56:44

Generate rollback SQL:

$ python binlog2sql/binlog2sql.py --flashback -h192.168.2.107 -uroot -p123456 --start-position=154 --stop-position=956 --start-file='mysql-bin.000002'
INSERT INTO `testdb`.`hello`(`id`, `name`) VALUES (2, 'Bill'); #start 715 end 956 time 2018-06-17 22:56:44
DELETE FROM `testdb`.`hello` WHERE `id`=4 AND `name`='Frank' LIMIT 1; #start 442 end 684 time 2018-06-17 22:55:47
UPDATE `testdb`.`hello` SET `id`=3, `name`='Will' WHERE `id`=3 AND `name`='David' LIMIT 1; #start 154 end 411 time 2018-06-17 22:54:13

フラッシュバックの実際の原理は、まず MySQL レプリケーションプロトコルの com-binlog-dump コマンドを使用してバイナリログをダンプし、次にバイナリログを追跡します。形式仕様に従ってバイナリログを解析し、バイナリログを SQL に変換し、これらの SQL を逆論理 SQL に変換し、最後に逆の順序で実行します。

Java 解析バイナリログ

上文中的 binlog2sql 其实底层依赖 python-mysql-replication 库，这是 Python 库。如果想使用 Java 解析 binlog 可以使用 mysql-binlog-connector-java（github）库。目前开源的 CDC 工具，如 Zendesk maxwell、Redhat debezium、LinkedIn Databus 等都底层依赖 mysql-binlog-connector-java 或者其前身 open-replicator。使用 mysql-binlog-connector-java 的示例代码如下：

BinaryLogClient client = new BinaryLogClient("192.168.2.107", 3306, "root", "123456");
client.setBinlogFilename("mysql-bin.000001");
client.setBinlogPosition(4);
client.setBlocking(false);
client.registerEventListener(event -> {
    System.out.println(event);
});
client.connect();

输出（省略部分内容）：

...
Event{header=EventHeaderV4{timestamp=1529247253000, eventType=TABLE_MAP, serverId=1, headerLength=19, dataLength=34, nextPosition=346, flags=0}, data=TableMapEventData{tableId=110, database='testdb', table='hello', columnTypes=8, 15, columnMetadata=0, 40, columnNullability={1}}}
Event{header=EventHeaderV4{timestamp=1529247253000, eventType=EXT_UPDATE_ROWS, serverId=1, headerLength=19, dataLength=46, nextPosition=411, flags=0}, data=UpdateRowsEventData{tableId=110, includedColumnsBeforeUpdate={0, 1}, includedColumns={0, 1}, rows=[
    {before=[3, Will], after=[3, David]}
]}}
...
Event{header=EventHeaderV4{timestamp=1529247347000, eventType=TABLE_MAP, serverId=1, headerLength=19, dataLength=34, nextPosition=634, flags=0}, data=TableMapEventData{tableId=110, database='testdb', table='hello', columnTypes=8, 15, columnMetadata=0, 40, columnNullability={1}}}
Event{header=EventHeaderV4{timestamp=1529247347000, eventType=EXT_WRITE_ROWS, serverId=1, headerLength=19, dataLength=31, nextPosition=684, flags=0}, data=WriteRowsEventData{tableId=110, includedColumns={0, 1}, rows=[
    [4, Frank]
]}}
...
Event{header=EventHeaderV4{timestamp=1529247404000, eventType=TABLE_MAP, serverId=1, headerLength=19, dataLength=34, nextPosition=907, flags=0}, data=TableMapEventData{tableId=110, database='testdb', table='hello', columnTypes=8, 15, columnMetadata=0, 40, columnNullability={1}}}
Event{header=EventHeaderV4{timestamp=1529247404000, eventType=EXT_DELETE_ROWS, serverId=1, headerLength=19, dataLength=30, nextPosition=956, flags=0}, data=DeleteRowsEventData{tableId=110, includedColumns={0, 1}, rows=[
    [2, Bill]
]}}

以上がMySQL の binlog ログファイルの詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明

この記事はsegmentfault思否で複製されています。侵害がある場合は、admin@php.cn までご連絡ください。

MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか？Apr 14, 2025 am 12:18 AM

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL：新規ユーザー向けのリソースとチュートリアルApr 14, 2025 am 12:16 AM

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1）テーブル、行、列、SQLクエリなどの基本概念を理解します。 2）MySQLの定義、作業原則、および利点を学びます。 3）インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4）インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

実際のmysql：例とユースケースApr 14, 2025 am 12:15 AM

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1）基本的な使用法：ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2）高度な使用法：eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3）パフォーマンスの最適化：インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。

MySQLのSQLコマンド：実用的な例Apr 14, 2025 am 12:09 AM

MySQLのSQLコマンドは、DDL、DML、DQL、DCLなどのカテゴリに分割でき、データベースとテーブルの作成、変更、削除、データの挿入、更新、削除、複雑なクエリ操作の実行に使用できます。 1.基本的な使用には、作成可能な作成テーブル、INSERTINTO INSERTデータ、クエリデータの選択が含まれます。 2。高度な使用法には、テーブル結合、サブQueries、およびデータ集約のためのグループに参加します。 3.構文エラー、データ型の不一致、許可の問題などの一般的なエラーは、構文チェック、データ型変換、許可管理を介してデバッグできます。 4.パフォーマンス最適化の提案には、インデックスの使用、フルテーブルスキャンの回避、参加操作の最適化、およびデータの一貫性を確保するためのトランザクションの使用が含まれます。

InnoDBは酸コンプライアンスをどのように処理しますか？Apr 14, 2025 am 12:03 AM

INNODBは、ロックメカニズムとMVCCを通じて、非論的、一貫性、および分離を通じて原子性を達成し、レッドログを介した持続性を達成します。 1）原子性：Undologを使用して元のデータを記録して、トランザクションをロールバックできることを確認します。 2）一貫性：行レベルのロックとMVCCを介してデータの一貫性を確保します。 3）分離：複数の分離レベルをサポートし、デフォルトでrepeatable -readが使用されます。 4）持続性：Redologを使用して修正を記録し、データが長時間保存されるようにします。

MySQLの場所：データベースとプログラミングApr 13, 2025 am 12:18 AM

データベースとプログラミングにおけるMySQLの位置は非常に重要です。これは、さまざまなアプリケーションシナリオで広く使用されているオープンソースのリレーショナルデータベース管理システムです。 1）MySQLは、効率的なデータストレージ、組織、および検索機能を提供し、Web、モバイル、およびエンタープライズレベルのシステムをサポートします。 2）クライアントサーバーアーキテクチャを使用し、複数のストレージエンジンとインデックスの最適化をサポートします。 3）基本的な使用には、テーブルの作成とデータの挿入が含まれ、高度な使用法にはマルチテーブル結合と複雑なクエリが含まれます。 4）SQL構文エラーやパフォーマンスの問題などのよくある質問は、説明コマンドとスロークエリログを介してデバッグできます。 5）パフォーマンス最適化方法には、インデックスの合理的な使用、最適化されたクエリ、およびキャッシュの使用が含まれます。ベストプラクティスには、トランザクションと準備された星の使用が含まれます

MySQL：中小企業から大企業までApr 13, 2025 am 12:17 AM

MySQLは、中小企業に適しています。 1）中小企業は、顧客情報の保存など、基本的なデータ管理にMySQLを使用できます。 2）大企業はMySQLを使用して、大規模なデータと複雑なビジネスロジックを処理して、クエリのパフォーマンスとトランザクション処理を最適化できます。

Phantomの読み取りとは何ですか？Innodbはどのようにそれらを防ぐ（次のキーロック）？Apr 13, 2025 am 12:16 AM

INNODBは、次のキーロックメカニズムを通じてファントムの読み取りを効果的に防止します。 1）Next-KeyLockingは、Row LockとGap Lockを組み合わせてレコードとギャップをロックして、新しいレコードが挿入されないようにします。 2）実際のアプリケーションでは、クエリを最適化して分離レベルを調整することにより、ロック競争を削減し、並行性パフォーマンスを改善できます。

See all articles