MySQL の基本 (36) その他のデータベース ログ

千万不要小看日志。一見奇妙に見える多くの質問に対する答えは、多くの場合ログに隠されています。多くの場合、問題の原因はログを確認することによってのみ発見され、真に解決できます。したがって、ログの確認方法を学び、ログを確認する習慣を身に付けることが、データベース アプリケーションの開発能力を向上させるために重要です。
MySQL8.0公式Webサイトのログアドレス：「https://dev.mysql.com/doc/refman/8.0/en/server-logs.html」

1 MySQL がサポートするログ

1.1 ログの種類

二进制日志MySQL には、さまざまなタイプのログを保存するために使用されるさまざまなタイプのログ ファイルがあり、 、错误日志、通用查询日志およびに分かれており、慢查询日志これらは一般的に使用される 4 つのタイプでもあります。MySQL 8 では、2 つの新しいサポート対象ログが追加されています:中继日志と数据定义语句日志。これらのログ ファイルを使用すると、MySQL の内部で何が起こっているかを確認できます。

これら 6 種類のログは次のとおりです。

• 慢查询日志: クエリを最適化できるように、実行時間がlong_query_timeを超えるすべてのクエリを記録します。
• 通用查询日志: すべての接続の開始時刻と終了時刻、および接続によってデータベース サーバーに送信されたすべての指示を記録します。これは、操作の実際のシナリオを復元したり、問題を発見したり、データベース操作を監査したりするのに非常に役立ちます。 。
• 错误日志: MySQL サービスの開始、実行、停止時に発生した問題を記録します。これにより、サーバーのステータスを理解し、サーバーを保守できるようになります。
• 二进制日志: データを変更するすべてのステートメントを記録します。これは、マスター サーバーとスレーブ サーバー間のデータ同期や、サーバーに障害が発生した場合のデータ損失のない回復に使用できます。
• 中继日志: マスター/スレーブ サーバー アーキテクチャで使用され、マスター サーバーのバイナリ ログの内容を保存するためにスレーブ サーバーが使用する中間ファイル。スレーブ サーバーは、リレー ログの内容を読み取ることでマスター サーバー上の操作を同期します。
• 数据定义语句日志: データ定義ステートメントによって実行されたメタデータ操作を記録します。

バイナリ ログを除くすべてのログ文本文件。デフォルトでは、すべてのログはMySQL数据目录に作成されます。

1.2 ログの欠点

• ログ機能は次のようになります降低MySQL数据库的性能。
• 日記セッション占用大量的磁盘空间。

2. スロークエリログ (スロークエリログ)

前章「MySQLの基礎(27)パフォーマンス解析ツールの使い方」で詳しく説明しました。

3. 一般的なクエリログ

一般的なクエリ ログには记录用户的所有操作、MySQL サービスの開始とシャットダウン、すべてのユーザーの接続開始時刻と終了時刻、MySQL データベース サーバーに送信されたすべての SQL 命令などが含まれます。データに異常が発生した場合、查看通用查询日志，还原操作时的具体场景問題を正確に特定するのに役立ちます。

3.1 問題のシナリオ

3.2 現在のステータスを表示する

mysql> SHOW VARIABLES LIKE '%general%';
+------------------+------------------------------+
| Variable_name | Value |
+------------------+------------------------------+
| general_log | OFF | #通用查询日志处于关闭状态
| general_log_file | /var/lib/mysql/DESKTOP-HD37NRE.log | #通用查询日志文件的名称是DESKTOP-HD37NRE.log
+------------------+------------------------------+
2 rows in set (0.03 sec)

3.3 起動ログ

方法 1: 永続的な方法

my.cnf または my.ini 構成ファイルを変更して設定します。[mysqld] グループの下にログ オプションを追加し、MySQL サービスを再起動します。形式は次のとおりです。

[mysqld]
general_log=ON
general_log_file=[path[filename]] #日志文件所在目录路径，filename为日志文件名

ディレクトリとファイル名を指定しない場合、一般的なクエリ ログはデフォルトで MySQL データ ディレクトリの hostname.log ファイルに保存されます。ここで、hostname はホスト名を表します。

方法 2: 一時的な方法

SET GLOBAL general_log=on; # 开启通用查询日志

SET GLOBAL general_log_file=’path/filename’; # 设置日志文件保存位置

これに対応して、シャットダウン操作の SQL コマンドは次のとおりです。

SET GLOBAL general_log=off; # 关闭通用查询日志

設定後の状況を確認します。

SHOW VARIABLES LIKE 'general_log%';

3.4 ログの表示

一般的なクエリ ログはテキスト ファイルの形式でファイル システムに保存されており、テキスト エディタを使用してログ ファイルを直接開くことができます。一般的なクエリ ログの内容は、MySQL サーバーごとに異なります。

• Windows オペレーティング システムでは、テキスト ファイル ビューアを使用します。
• Linux システムでは、vi ツールまたは gedit ツールを使用して表示できます。
• Mac OSX システムでは、テキスト ファイル ビューアまたは vi などのツールを使用して表示できます。

SHOW VARIABLES LIKE 'general_log%';結果から、一般的なクエリ ログの場所がわかります。

/usr/sbin/mysqld, Version: 8.0.26 (MySQL Community Server - GPL). started with:
Tcp port: 3306 Unix socket: /var/lib/mysql/mysql.sock
Time Id Command Argument
2022-01-04T07:44:58.052890Z 10 Query SHOW VARIABLES LIKE '%general%'
2022-01-04T07:45:15.666672Z 10 Query SHOW VARIABLES LIKE 'general_log%'
2022-01-04T07:45:28.970765Z 10 Query select * from student
2022-01-04T07:47:38.706804Z 11 Connect root@localhost on using Socket
2022-01-04T07:47:38.707435Z 11 Query select @@version_comment limit 1
2022-01-04T07:48:21.384886Z 12 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:21.385253Z 12 Query SET NAMES utf8
2022-01-04T07:48:21.385640Z 12 Query USE `test12`
2022-01-04T07:48:21.386179Z 12 Query SHOW FULL TABLES WHERE Table_Type !=
'VIEW'
2022-01-04T07:48:23.901778Z 13 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:23.902128Z 13 Query SET NAMES utf8
2022-01-04T07:48:23.905179Z 13 Query USE `test`
2022-01-04T07:48:23.905825Z 13 Query SHOW FULL TABLES WHERE Table_Type !=
'VIEW'
2022-01-04T07:48:32.163833Z 14 Connect root@172.16.210.1 on using TCP/IP
2022-01-04T07:48:32.164451Z 14 Query SET NAMES utf8
2022-01-04T07:48:32.164840Z 14 Query USE `test`
2022-01-04T07:48:40.006687Z 14 Query select * from account

一般的なクエリ ログでは、データベースにログインするために新しいクライアントがいつ開かれたか、ログイン後に実行された SQL 操作、どのデータ テーブルが対象となったか、その他の情報が明確にわかります。

3.5 ロギングの停止

方法 1: 永続的な方法

my.cnf または my.ini ファイルを変更し、[mysqld] グループの general_log 値を OFF に設定するか、general_log 項目をコメント化します。変更を保存した後、MySQL サービスを再起動して有効にします。例 1:

[mysqld]
general_log=OFF

例 2:

[mysqld]
#general_log=ON

方法 2: 一時的な方法
SET ステートメントを使用して、MySQL の一般クエリ ログ機能を停止します。

SET GLOBAL general_log=off;

一般的なログ関数のクエリ:

SHOW VARIABLES LIKE 'general_log%';

3.6 ログの削除/更新

データが非常に頻繁に使用される場合、一般的なクエリ ログはサーバー上で非常に大量のディスク領域を占有することになります。データ管理者は、
昔のクエリ ログを削除して、MySQL サーバー上のハード ディスク領域を確保できます。

ファイルを手動で削除する

SHOW VARIABLES LIKE 'general_log%';

一般的なクエリ ログのディレクトリがデフォルトで MySQL データ ディレクトリになっていることがわかります。このディレクトリ内の一般クエリ ログ DESKTOP-HD37NRE.log を手動で削除します
。

クエリ ログ ファイルを再生成するには、次のコマンドを使用します。具体的なコマンドは次のとおりです。MySQL データ ディレクトリを更新すると、新しいログ ファイルが作成されたことがわかります。前提条件として、一般ログをオンにする必要があります。

mysqladmin -uroot -p flush-logs

4. エラーログ

4.1 起動ログ

MySQL データベースでは、エラー ログ機能は です默认开启。また、エラーログ无法被禁止。

デフォルトでは、エラー ログは MySQL データベースのデータ フォルダーに保存され、デフォルト名はmysqld.log(Linux システム) またはhostname.err(Mac システム) です。ファイル名を指定する必要がある場合は、my.cnf または my.ini で次の構成を行う必要があります。

[mysqld]
log-error=[path/[filename]] #path为日志文件所在的目录路径，filename为日志文件名

構成項目を変更した後、有効にするために MySQL サービスを再起動する必要があります。

4.2 ログの表示

MySQL エラー ログはテキスト ファイルに保存され、テキスト エディタを使用して直接表示できます。

エラー ログのストレージ パスをクエリします。

mysql> SHOW VARIABLES LIKE 'log_err%';
+----------------------------+----------------------------------------+
| Variable_name | Value |
+----------------------------+----------------------------------------+
| log_error | /var/log/mysqld.log |
| log_error_services | log_filter_internal; log_sink_internal |
| log_error_suppression_list | |
| log_error_verbosity | 2 |
+----------------------------+----------------------------------------+
4 rows in set (0.01 sec)

実行結果から、エラー ログ ファイルが mysqld.log であり、MySQL のデフォルト データ ディレクトリにあることがわかります。

4.3 ログの削除/更新

古いエラー ログの場合、データベース管理者がこれらのエラー ログを参照する可能性は低いため、MySQL サーバーのセキュリティを確保するためにこれらのエラー ログは削除できます硬盘空间。MySQL エラー ログは、テキスト ファイルの形式でファイル システムに保存されます。はい直接删除。

[root@atguigu01 log]# mysqladmin -uroot -p flush-logs
Enter password:
mysqladmin: refresh failed; error: 'Could not open file '/var/log/mysqld.log' for
error logging.'

公式ウェブサイトのヒント:

追加の操作:

install -omysql -gmysql -m0644 /dev/null /var/log/mysqld.log

5. バイナリログ（bin log）

Binlog は MySQL の中で最もポピュラーなログと言え重要、日々の開発や運用・保守の際によく遭遇します。

binlogとはバイナリログ、バイナリログファイルのことで、変更ログ（アップデートログ）とも呼ばれます。データベースによって実行されたすべてのステートメントDDLおよびその他のデータベース更新イベントが記録されますが、データを変更しないステートメント (データ クエリ ステートメント select、show など) は含まれません。DML

binlog の主なアプリケーション シナリオ:

• 1 つは、数据恢复
• 第二に、それは次の目的で使用されます。数据复制

5.1 デフォルト条件を表示する

バイナリ ログがオンになっているかどうかを確認します。MySQL8 では、デフォルトでバイナリ ファイルがオンになっています。

mysql> show variables like '%log_bin%';
+---------------------------------+----------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/binlog |
| log_bin_index | /var/lib/mysql/binlog.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+----------------------------------+
6 rows in set (0.00 sec)

5.2 ログパラメータの設定

方法 1: 永続的な方法

MySQLmy.cnfまたはmy.iniファイルを変更して、バイナリ ログの関連パラメータを設定します。

[mysqld]
#启用二进制日志
log-bin=atguigu-bin
binlog_expire_logs_seconds=600
max_binlog_size=100M

MySQL サービスを再起動し、バイナリ ログ情報をクエリすると、実行結果は次のようになります。

mysql> show variables like '%log_bin%';
+---------------------------------+----------------------------------+
| Variable_name | Value |
+---------------------------------+----------------------------------+
| log_bin | ON |
| log_bin_basename | /var/lib/mysql/atguigu-bin |
| log_bin_index | /var/lib/mysql/atguigu-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+----------------------------------+
6 rows in set (0.00 sec)

bin-logのログ保存ディレクトリをフォルダで設定する

ログ ファイルのディレクトリと名前を変更する場合は、my.cnf または my.ini の log_bin パラメータを次のように変更できます。

[mysqld]
log-bin="/var/lib/mysql/binlog/atguigu-bin"

注: 新しく作成したフォルダーには mysql ユーザーが必要です。次のコマンドを使用するだけです。

chown -R -v mysql:mysql binlog

方法 2: 一時的な方法
設定ファイルを変更して再起動してバイナリ ログを設定したくない場合は、次の手順を使用することもできます。mysql8 には設定のみがあり、グローバル レベルの設定はないことに注意してください会话级别。

# global 级别
mysql> set global sql_log_bin=0;
ERROR 1228 (HY000): Variable 'sql_log_bin' is a SESSION variable and can`t be used
with SET GLOBAL
# session级别
mysql> SET sql_log_bin=0;
Query OK, 0 rows affected (0.01 秒)

5.3 ログの表示

MySQL がバイナリ ログ ファイルを作成する場合、最初に名前が「filename」、サフィックスが「.index」のファイルが作成され、次に名前が「filename」、サフィックスが「.000001」のファイルが作成されます。

MySQL サービスの場合重新启动一次、サフィックス「.000001」を持つファイルが 1 つ追加され、サフィックス名が 1 ずつ増加します。つまり、ログ ファイルの数は MySQL サービスの起動回数と同じになり、ログの長さが上限max_binlog_size(デフォルトは 1GB) を超えると、新しいログ ファイルが作成されます。

現在のバイナリ ログ ファイルのリストとサイズを表示します。手順は次のとおりです。

mysql> SHOW BINARY LOGS;
+--------------------+-----------+-----------+
| Log_name | File_size | Encrypted |
+--------------------+-----------+-----------+
| atguigu-bin.000001 | 156 | No |
+--------------------+-----------+-----------+
1 行于数据集 (0.02 秒)

次のコマンドは、ライン イベントを次のように伪SQL的形式表示します。

mysqlbinlog -v "/var/lib/mysql/binlog/atguigu-bin.000002"
#220105 9:16:37 server id 1 end_log_pos 324 CRC32 0x6b31978b Query thread_id=10
exec_time=0 error_code=0
SET TIMESTAMP=1641345397/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,
@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb3 *//*!*/;
SET
@@session.character_set_client=33,@@session.collation_connection=33,@@session.collatio
n_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 324
#220105 9:16:37 server id 1 end_log_pos 391 CRC32 0x74f89890 Table_map:
`atguigu14`.`student` mapped to number 85
# at 391
#220105 9:16:37 server id 1 end_log_pos 470 CRC32 0xc9920491 Update_rows: table id
85 flags: STMT_END_F
BINLOG '
dfHUYRMBAAAAQwAAAIcBAAAAAFUAAAAAAAEACWF0Z3VpZ3UxNAAHc3R1ZGVudAADAw8PBDwAHgAG
AQEAAgEhkJj4dA==
dfHUYR8BAAAATwAAANYBAAAAAFUAAAAAAAEAAgAD//8AAQAAAAblvKDkuIkG5LiA54+tAAEAAAAL
5byg5LiJX2JhY2sG5LiA54+tkQSSyQ==
'/*!*/;
### UPDATE `atguigu`.`student`
### WHERE
### @1=1
### @2='张三'
### @3='一班'
### SET
### @1=1
### @2='张三_back'
### @3='一班'
# at 470
#220105 9:16:37 server id 1 end_log_pos 501 CRC32 0xca01d30f Xid = 15
COMMIT/*!*/;

前のコマンドではステートメントも binlog 形式で表示されますが、表示しない場合は次のコマンドを使用します。

mysqlbinlog -v --base64-output=DECODE-ROWS "/var/lib/mysql/binlog/atguigu-bin.000002"
#220105 9:16:37 server id 1 end_log_pos 324 CRC32 0x6b31978b Query thread_id=10
exec_time=0 error_code=0
SET TIMESTAMP=1641345397/*!*/;
SET @@session.pseudo_thread_id=10/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0,
@@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb3 *//*!*/;
SET
@@session.character_set_client=33,@@session.collation_connection=33,@@session.collatio
n_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 324
#220105 9:16:37 server id 1 end_log_pos 391 CRC32 0x74f89890 Table_map:
`atguigu14`.`student` mapped to number 85
# at 391
#220105 9:16:37 server id 1 end_log_pos 470 CRC32 0xc9920491 Update_rows: table id
85 flags: STMT_END_F
### UPDATE `atguigu14`.`student`
### WHERE
### @1=1
### @2='张三'
### @3='一班'
### SET
### @1=1
### @2='张三_back'
### @3='一班'
# at 470
#220105 9:16:37 server id 1 end_log_pos 501 CRC32 0xca01d30f Xid = 15

mysqlbinlog ツールを使用するには、特定のライブラリまたは特定の期間内の操作のみを解析するなど、さまざまなテクニックがあります。よく使用されるステートメントをいくつか紹介します。その他の操作については、公式ドキュメントを参照してください。

# 可查看参数帮助
mysqlbinlog --no-defaults --help
# 查看最后100行
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |tail
-100
# 根据position查找
mysqlbinlog --no-defaults --base64-output=decode-rows -vv atguigu-bin.000002 |grep -A
20 '4939002'

上記の方法では、binlog ログのフルテキスト コンテンツの多くを読み取るため、POS ポイント情報を区別して表示するのは簡単ではありません。より便利なクエリ コマンドを次に示します。

mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];

• IN 'log_name':クエリするbinlogファイルの名前を指定します(指定しない場合、最初のbinlogファイルになります)
• FROM pos: どの位置から検索を開始するかを指定します(指定しない場合は、ファイル全体の最初の位置から開始します)。
• LIMIT [offset]: オフセット(指定しない場合は0)
• row_count: 行の合計数を問い合わせます (指定されていない場合はすべての行)

mysql> show binlog events in 'atguigu-bin.000002';
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info
|
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
| atguigu-bin.000002 | 4 | Format_desc | 1 | 125 | Server ver:
8.0.26, Binlog ver: 4 |
| atguigu-bin.000002 | 125 | Previous_gtids | 1 | 156 |
|
| atguigu-bin.000002 | 156 | Anonymous_Gtid | 1 | 235 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 235 | Query | 1 | 324 | BEGIN
|
| atguigu-bin.000002 | 324 | Table_map | 1 | 391 | table_id: 85
(atguigu14.student) |
| atguigu-bin.000002 | 391 | Update_rows | 1 | 470 | table_id: 85
flags: STMT_END_F |
| atguigu-bin.000002 | 470 | Xid | 1 | 501 | COMMIT /*
xid=15 */ |
| atguigu-bin.000002 | 501 | Anonymous_Gtid | 1 | 578 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 578 | Query | 1 | 721 | use
`atguigu14`; create table test(id int, title varchar(100)) /* xid=19 */ |
| atguigu-bin.000002 | 721 | Anonymous_Gtid | 1 | 800 | SET
@@SESSION.GTID_NEXT= 'ANONYMOUS' |
| atguigu-bin.000002 | 800 | Query | 1 | 880 | BEGIN
|
| atguigu-bin.000002 | 880 | Table_map | 1 | 943 | table_id: 89
(atguigu14.test) |
| atguigu-bin.000002 | 943 | Write_rows | 1 | 992 | table_id: 89
flags: STMT_END_F |
| atguigu-bin.000002 | 992 | Xid | 1 | 1023 | COMMIT /*
xid=21 */ 
+--------------------+-----+----------------+-----------+-------------+---------------
--------------------------------------------------------------+
14 行于数据集 (0.02 秒)

上で述べたことは、binlog のデフォルト形式に基づいています。binlog 形式で表示してください。

mysql> show variables like 'binlog_format';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW |
+---------------+-------+
1 行于数据集 (0.02 秒)

さらに、binlog には 2 つの形式がありますStatement。Mixed

• データを変更するすべての SQLステートメントは
  バイナリログに記録されます。
  利点: 各行の変更を記録する必要がないため、binlog ログの量が削減され、IO が節約され、パフォーマンスが向上します。
• MySQL の行
  5.1.5 バージョンは、行レベルのレプリケーションのサポートを開始したばかりで、SQL ステートメントのコンテキスト関連情報は記録せず、どのレコードが変更されたかを保存するだけです。
  利点: 行レベルのログ内容には、データ変更の各行の詳細が明確に記録されます。また、ストアド プロシージャ、関数、トリガーの呼び出しやトリガーが特定の状況下で正しくコピーされないという問題は発生しません。
• 混合
  バージョン 5.1.8 以降、MySQL は混合フォーマットを提供します。これは実際には Statement と Row の組み合わせです。
  詳細は次章で説明します。

5.4 ログを使用してデータを回復する

データを復元するための mysqlbinlog の構文は次のとおりです。

mysqlbinlog [option] filename|mysql –uuser -ppass;

このコマンドは次のように理解できます。mysqlbinlog コマンドを使用して filename の内容を読み取り、mysql コマンドを使用してその内容をデータベースに復元します。

• filename: はログファイル名です。

• option: オプション。オプション パラメーターの 2 つのより重要なペアは、-start-date、-stop-date、および -start-position、-stop-position です。

  • --start-date 和 --stop-date: データベース回復の開始時点と終了時点を指定できます。
  • --start-position和--stop-position：復元したデータの開始位置と終了位置を指定できます。

  注: mysqlbinlog コマンドを使用してリカバリ操作を実行する場合は、小さい番号を最初に復元する必要があります (たとえば、atguigu-bin.000002 の前に atguigu-bin.000001 を復元する必要があります)。

5.5 バイナリログの削除

MySQL バイナリ ファイルは自動的に削除されるように構成でき、MySQL はバイナリ ファイルを手動で削除する安全な方法も提供します。PURGE MASTER LOGSバイナリログファイルの指定部分のみを削除し、RESET MASTERすべてのバイナリログファイルを削除します。詳細は次のとおりです。

1. マスターログのパージ: 指定したログファイルを削除します。

PURGE MASTER LOGS の構文は次のとおりです。

PURGE {MASTER | BINARY} LOGS TO ‘指定日志文件名’
PURGE {MASTER | BINARY} LOGS BEFORE ‘指定日期’

5.6 その他のシナリオ

バイナリ ログをデータベース全量备份に保存し、バイナリ ログを增量信息作成してデータベースを完成させることができます无损失恢复。ただし、大量のデータと多数のデータベースとデータ テーブルを含むシナリオ (シャーディング データベースとシャーディング テーブルのアプリケーションなど) に遭遇した場合、開始位置と終了位置が異なるため、データ回復にバイナリ ログを使用することは非常に困難です。管理するのは簡単ではありません。

この場合、アーキテクチャ配置主从数据库服务器上であってもバイナリログファイルの内容をリレーログを介してスレーブデータベースサーバに同期することが有効な解決策となり、データベース障害によるデータ異常などの問題を効果的に回避できます。一主多从

6. バイナリログ (binlog) についてもう一度話しましょう

6.1 書き込みの仕組み

binlogの書き込みタイミングも非常にシンプルで、トランザクション実行時に最初にログが書き込まれbinlog cache、トランザクション投入時に
binlogキャッシュがbinlogファイルに書き込まれます。トランザクションのバイナリログは分割できないため、トランザクションがどれほど大きくても
一度に書き込む必要があるため、システムはメモリのブロックをバイナリログキャッシュとして各スレッドに割り当てます。

書き込みと fsync のタイミングはパラメータ sync_binlog で制御でき、デフォルトは 0 です。0 の場合、トランザクションが送信されるたびに書き込みのみが実行され、fsync をいつ実行するかはシステムが決定することを意味します。パフォーマンスは向上しましたが、マシンがダウンすると、ページ キャッシュ内の binglog
が失われます。以下に示すように:セキュリティ上の理由から、同様にトランザクションが送信されるたびに fsync が実行されるように

設定できます。最後に、妥協策があります。N (N>1) に設定できます。これは、トランザクションが送信されるたびに書き込みますが、N 個のトランザクションが蓄積された後でのみ fsync を実行することを意味します。IO ボトルネックが発生するシナリオでは、sync_binlog を比較的大きな値に設定すると、パフォーマンスが向上する可能性があります。同様に、マシンがダウンすると、最後の N 個のトランザクションの binlog ログが失われます。1redo log 刷盘流程

6.2 binlog と redolog の比較

• redo ログ物理日志「特定のデータ ページにどのような変更が加えられたか」を記録し、InnoDB ストレージ エンジン層によって生成されます。
• binlog では逻辑日志、レコードの内容はステートメントの元のロジックであり、「ID=2 の行の c フィールドに 1 を追加する」と同様で、MySQL Server レイヤーに属します。

6.3 2 段階の提出

update ステートメントの実行中に、REDO ログと binlog の 2 つのログが記録されます。基本的なトランザクションに基づいて、REDO ログはトランザクション実行中に継続的に書き込むことができますが、binlog はトランザクションが送信されたときにのみ書き込まれるため、REDO ログはビンログは写入时机異なります。

redo log与binlog两份日志之间的逻辑不一致，会出现什么问题？

バイナリログは完了する前に異常であるため、現時点ではバイナリログに対応する変更レコードはありません。

2 つのログ間の論理一貫性の問題を解決するために、InnoDB ストレージ エンジンは两阶段提交ソリューションを使用します。

useの後两阶段提交、binlog への書き込み時に例外が発生しても影響はありません。

別のシナリオでは、REDO ログ設​​定のコミット段階で例外が発生した場合、トランザクションはロールバックされますか?

トランザクションはロールバックされません, 上の図に示されているロジックが実行されます. REDO ログは準備段階にありますが、対応する binlog ログはトランザクション ID を通じて見つけることができるため、MySQL はそれが完了したと見なし、データを復元するトランザクション。

7. リレーログ

7.1 はじめに

中继日志只在主从服务器架构的从服务器上存在。マスター サーバーとの一貫性を保つために、スレーブ サーバーはマスター サーバーからバイナリ ログの内容を読み取り、読み取った情報を に書き込む必要があります。本地的日志文件このスレーブ サーバーのローカル ログ ファイルは と呼ばれます中继日志。そして、スレーブサーバは中継ログを読み込み、中継ログの内容に従ってスレーブサーバのデータを更新することでマスタスレーブサーバ１０が完成する数据同步。

マスター/スレーブサーバーを設定すると、リレーログはデフォルトでスレーブサーバーのデータディレクトリに保存されます。

ファイル名の形式は次のとおりです从服务器名 -relay-bin.序号。从服务器名 -relaybin.index リレー ログには、現在使用中のリレー ログを見つけるために使用されるインデックス ファイルもあります。

7.2 リレーログの表示

リレー ログはバイナリ ログと同じ形式であり、mysqlbinlogツールを使用して表示できます。以下はリレー ログの抜粋です。

SET TIMESTAMP=1618558728/*!*/;
BEGIN
/*!*/;
# at 950
#210416 15:38:48 server id 1 end_log_pos 832 CRC32 0xcc16d651 Table_map:
`atguigu`.`test` mapped to number 91
# at 1000
#210416 15:38:48 server id 1 end_log_pos 872 CRC32 0x07e4047c Delete_rows: table id
91 flags: STMT_END_F -- server id 1 是主服务器，意思是主服务器删了一行数据
BINLOG '
CD95YBMBAAAAMgAAAEADAAAAAFsAAAAAAAEABGRlbW8ABHRlc3QAAQMAAQEBAFHWFsw=
CD95YCABAAAAKAAAAGgDAAAAAFsAAAAAAAEAAgAB/wABAAAAfATkBw==
'/*!*/;
# at 1040

この段落の意味は、メイン サーバー (「サーバー ID 1」) がテーブル atguigu.test に対して 2 つのステップを実行したことです。

定位到表 atguigu.test 编号是 91 的记录，日志位置是 832；

删除编号是 91 的记录，日志位置是 872。

7.3 リカバリ時の典型的なエラー

服务器名称スレーブ サーバーがクラッシュした場合、システムを回復するためにオペレーティング システムを再インストールする必要がある場合があり、これにより以前とは状況が異なる可能性があります不同。そしてリレーログは です包含从服务器名。この場合、スレーブサーバーを復旧すると、ダウンタイム前にリレーログからデータを読み取れなくなり、ログファイルが破損していると思われるかもしれませんが、実際には名前が間違っています。

解決策も非常に簡単で、スレーブ サーバーの名前を以前の名前に戻すだけです。