深入剖析：如何指定数据库解析binlog (解析binlog 指定数据库)
在MySQL数据库中，binlog是一种用于记录所有数据库更改的二进制日志文件。它重要的功能之一是用于数据库的备份、恢复和数据迁移。在处理这些任务时，你可能会遇到需要指定数据库解析binlog的情况。本文将为你介绍如何在不同场景下指定数据库解析binlog。
1. 使用mysqlbinlog命令解析binlog文件
mysqlbinlog是MySQL自带的解析binlog的工具，它可以将binlog文件的内容还原成原始的SQL语句。你可以用以下命令来使用mysqlbinlog：
“`mysqlbinlog [options] [–] binlog-file…“`
其中，[options]是mysqlbinlog的选项，binlog-file是你要解析的binlog文件。例如，如果你要解析名为mysql-bin.000001的binlog文件，可以运行以下命令：
“`mysqlbinlog mysql-bin.000001“`
如果你的服务器上有多个binlog文件，你可以指定多个文件，例如：
“`mysqlbinlog mysql-bin.000001 mysql-bin.000002 mysql-bin.000003“`
由于mysqlbinlog能够解析所有的binlog文件，而不管这些文件来自哪个数据库，因此在解析binlog的时候，你需要指定要解析的数据库。你可以使用”–database”选项指定，例如：
“`mysqlbinlog –database=mydatabase mysql-bin.000001“`
这将只显示”mydatabase”数据库中的更新。
2. 使用pt-query-digest解析binlog事件
如果你需要对binlog更深入地进行分析，例如统计SQL执行次数、执行时间、慢查询等信息，可以使用Percona Toolkit中的pt-query-digest工具来解析binlog事件。pt-query-digest是一种基于命令行的工具，它可以从多个来源获取二进制日志，如文件、管道和数据库等。你可以使用以下命令使用pt-query-digest解析binlog事件：
“`pt-query-digest –type=binlog binlog-file“`
其中，binlog-file是你要解析的binlog文件名。使用”–type”选项指定解析类型（默认是general）。
在使用pt-query-digest解析binlog事件时，需要指定一到多个连接到MySQL服务器的选项，例如MySQL用户名、密码、主机名和端口号等等。你可以使用”–user”、”–password”、”–host”、”–port”选项指定相应的值。例如：
“`pt-query-digest –type=binlog –user=root –password=password –host=localhost –port=3306 mysql-bin.000001“`
在解析binlog事件时，pt-query-digest会将二进制日志还原成SQL语句，并将其打印到终端中。你可以使用”–output”选项来指定输出方式，如输出到文件或数据库等。例如：
“`pt-query-digest –type=binlog –user=root –password=password –host=localhost –port=3306 mysql-bin.000001 –output=/path/to/output“`
这将将pt-query-digest的输出保存到指定的文件中。
3. 使用MySQL Enterprise Monitor解析binlog事件
如果你使用的是MySQL Enterprise数据库，你可以使用MySQL Enterprise Monitor来解析binlog事件。MySQL Enterprise Monitor是一款商业软件，它提供了丰富的功能，包括性能管理、监控、报告和警报等。你可以使用它来解析binlog，并查看二进制日志的详细信息。使用MySQL Enterprise Monitor解析binlog事件需要执行以下步骤：
（1）打开MySQL Enterprise Monitor的GUI界面，进入”Event Analysis”菜单，并选择”Binary Log Events”选项卡。
（2）在”Binary Log Events”选项卡中，你可以浏览所有可用的binlog文件，并选择你要解析的binlog文件。
（3）在选择了binlog文件之后，你可以选择要解析的事件类型，并设置其他筛选条件。
（4）点击”Analyze”按钮，MySQL Enterprise Monitor会解析binlog事件并显示其详细信息。
MySQL Enterprise Monitor的优点在于它能够对MySQL数据库进行全面监控，包括性能、安全和可用性等方面。因此，如果你需要全面了解你的MySQL数据库，它可能是一个不错的选择。
结论
在不同的场景下，你可以使用不同的方式来指定数据库解析binlog。如果你只需要还原SQL语句，可以使用mysqlbinlog；如果你需要更深入地分析binlog事件，可以使用pt-query-digest；如果你使用MySQL Enterprise数据库并需要全面监控，可以使用MySQL Enterprise Monitor。但无论你使用哪种方法，你都需要指定要解析的binlog文件和要解析的数据库。
相关问题拓展阅读：
跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 绿色版软件百度云资源
链接:
提取码:a2vh
软件名称:MySQLBinlogDigger(日志挖掘分析工具)V4.4绿色版
语言:英文软件
大小:13.14MB
类别:系统工具
介绍:MySQLBinlogDigger基于图形界面，绿色免安装，能对在线binlog与离线binlog进行分析，在选定在线binlog或离线binlog日志后，可对数据库、表、binlog开始时间、binlog结束时间、误操作的重做类型进行信息分析。
XtraBackup 备份指定库
Percona XtraBackup的功能之一“部分备份（partial backups）”，即让用户可以备份指定的表或数据库。要注意的是：你希望备份的表必须是在独立的表空间中，即该表在创建以前，你的MySQL开启了innodb_file_per_table设置。
还一点要注意的是：不要将prepared backup备份的东西拷贝回去。部分备份使用的是导入表（importing the tables），而不是全库备份的–copy-back参数。尽管有时简单的拷贝备份文件可以成功，但是这种方法很容易导致数据库的不一致，因此不推荐大家这么做。
创建部分备份（Creating Partial Backups）
部分备份共有三种方式，分别是：1. 用正则表达式表示要备份的库名及表名（参数为–include）；2. 将要备份的表名或库名都写在一个文本文件中（参数为–tables-file）以及 3. 将要备份表名或库名完整的写在命令行中（参数为：–databases）。（译者注：不管你备份哪个库或是哪张表，强烈推荐把mysql库也一起备份，恢复的时候要用。）
方式一：使用–include参数
这种方式通过正则表达式来匹配数据库名和表名，你需要写完整的数据库名及表名，如果数据库有用户名密码请使用–user和–password指定相关信息。，格式如下：databasename.tablename。下面是一个例子：
$ innobackupex –include=’^mydatabasemytable’ /path/to/backup –user=backup –password=backup
上面的方式会和其他使用innobackupex命令的备份方式一样，创建一个时间戳命名的文件夹，不同的是，最终只包括那些正则表达式匹配的表。
要注意的是，这个命令最后会传给xtrabackup –tables命令执行，并且会为每个数据库（包括不需要备份的数据库）创建一个对应的文件夹。
方式二：使用–tables-file参数
这种方式是将所有要颤桐备份的完整表名都写在一个文本文件中，每行一个完整表名，然后程序读取这个文本文件进行备份。完整表名即：databasename.tablename。如果数据库有用户名密码请使用–user和–password指定相关信息。下面是一个例子：
$ echo “mydatabase.mytable” > /tmp/tables.txt$ innobackupex –tables-file=/tmp/tables.txt /path/清洞尺to/backup –user=backup –password=backup
上面的方式会和其他使用innobackupex命令的备份方式一样，创建一个时间戳命名的文件夹，不同的是，最终只包括那些文件中指定的表名。
这个命令最后会传给xtrabackup –tables-file命令执行，而不是–tables，因答高此这个命令只会创建那些需要备份的数据库文件夹。
Xtrabackup 是由 percona 开源的免费数据库热备份软件，它能对 InnoDB 和 XtraDB 存储引擎的数据库非阻塞地备份。
为了方便建立从库，Xtrabackup 在备份完成后会将 binlog position 与 GTID 的相关信息保存于 xtrabackup_binlog_info 文件中。但是当你使用 Xtrabackup 生成的备份建立一个从库时，会发现恢复后的实例执行 show master status，显示的 Executed_Gtid_Set 与 xtrabackup_binlog_info 文件中记录的信息并不一致，而且使用 Xtrabackup 2.4 与 8.0（对 MySQL 8.0 进行备份）生成的备份在恢复后，信息不一致的表现又不相同。本篇文章主要针对该现象进行简单的分析。
一、Xtrabackup 2.4.18 for MySQL 5.7.26
现象
1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：\# cat xtrabackup_binlog_infomysql-bin.d3d9b9-4d49-11ea-932c-02023aba3fa6:
2. 将该备份恢复至一个新实例并启动该实例，执行 show master status; 查看信息：mysql> show master status\G*************************** 1. row ***************************File: mysql-bin. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 55d3d9b9-4d49-11ea-932c-02023aba3fa6:row in set (0.00 sec)
此时会发现使用备份恢复的实例显示已执行过的 GTID 是，而备份文件显示的是，这是否表示两者相差的 GTID:代表的事务丢失了？通过对原实例（进行备份的实例）的 binlog 进行解析，来查询 GTID:这部分事务所生成的数据在新实例（通过备份恢复的实例）上是否存在。可以发现 GTID:这部分事务的数据都存在于新实例上，也就是说数据与 xtrabackup_binlog_info 文件记录的是一致的，只不过与 show master status 命令获取的信息的不一致。
原因分析
首先我们要清楚 Xtrabackup 2.4 的备份流程悔孝，大致如下：
1. start backup
2. copy ibdata1 / copy .ibd file
3. Excuted ftwrl
4. backup non-InnoDB tables and files
5. Writing xtrabackup_binlog_info
6. Executed FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS
7. Executed UNLOCK TABLES
8. Copying ib_buffer_pool
9. completed OK!
结合备份时的 general log 可知，Xtrabackup 在执行 ftwrl 并备份完所有非 InnoDB 表格的文件后通过 show master status 获取了 binlog position 和 GTID 的信息，将其记录到 xtrabackup_binlog_info 文件中。
那么 show master status 获取的是哪些信息？
该命令提供本实例的 binlog 文件的状态信息，显示正在写入的 binlog 文件，以及当前的binlog position，并且 MySQL 5.7 在 MySQL 库下引入了 gtid_executed 表，该表会记录当前执行过的 GTID。
那么目前看来问题可能就出桐档在 gtid_executed 表格碧轮稿上，通过测试和官方文档提供的信息可知，该表格虽然是 InnoDB 表，但是其中的数据并非是实时更新的，且该表格记录信息的方式存在以下两个情况：1. 如果禁用了 log_bin，实例不会在该表格记录任何信息；若从库的 log_slave_updates 为 OFF，那么从库会在应用 relay-log 中的每个事务时执行一次 insert mysql.gtid_executed 的操作。2. 如果启用了 log_bin，则该表格记录的是在 binlog 发生切换（rotate）的时候直到上一个 binlog 文件执行过的全部 GTID，而此时 show master status 获取的 Gtid 信息不再由 mysql.gtid_executed 表提供，而是由全局系统变量 gtid_exected 提供；如果服务器意外停止，则当前 binlog 文件中的 Gtid 不会保存在 mysql.gtid_executed 表中，在实例恢复期间，这些 Gtid 从 binlog 文件中读取并添加到表中。
小结
所以当备份恢复时，实际 show master status 可能会出现以下情况：1. 当 log_bin 禁用或者 log_slave_updates 为 OFF 时，备份恢复后的实例 show master status 显示为空。2. 当开启了 log_bin，但是该实例并未发生过 binlog 的切换时，备份恢复后的实例 show master status 显示也为空。3. 当开启了 log_bin，其该实例的 binlog 发生过切换时，备份恢复后的实例 show master status 显示的信息会比 xtrabackup_binlog_info 文件中记录的 GTID 缺失一部分，这一部分就是 mysql.gtid_executed 表格未记录的部分。
二、Xtrabackup 8.0.8 for MySQL 8.0.18现象1. 使用 Xtrabackup 工具备份后，xtrabackup_binlog_info 文件记录的信息如下：# # cat xtrabackup_binlog_infobinlog. 70ec927f-4c6d-11ea-b88c-02023aba3fb1:
2. 查看备份实例相对应的 binlog 解析后的内容：
# mysqlbinlog -vv binlog.| less
定位至 70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683
# at 508
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=07 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=07 (:46:47.CST)
# immediate_commit_timestamp=07 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=07*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621683’/*!*/;
# at 583
#:46:47 server idend_log_posQuery thread_id=214 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 659
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 708
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 758
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAMQCAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAPYCAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAB4DAAAAADoBAAAAAAEAAgAC/wCKAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65674 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 798
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
可以发现该文件提供的 binlog position 与 GTID 并不对应。而 binlog.000033:1459 对应的 GTID 是 70ec927f-4c6d-11ea-b88c-02023aba3fb1:提交后的下一个位置：
# at 1142
#:46:47 server idend_log_posGTID last_committed=sequence_number=rbr_only=yes original_committed_timestamp=46 immediate_commit_timestamp=
transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=46 (:46:47.CST)
# immediate_commit_timestamp=46 (:46:47.CST)
/*!80001 SET @@session.original_commit_timestamp=46*//*!*/;
/*!80014 SET @@session.original_server_version=80018*//*!*/;
/*!80014 SET @@session.immediate_server_version=80018*//*!*/;
SET @@SESSION.GTID_NEXT= ’70ec927f-4c6d-11ea-b88c-02023aba3fb1:621685’/*!*/;
# at 1217
#:46:47 server idend_log_posQuery thread_id=215 exec_time=0 error_code=0
SET TIMESTAMP=/*!*/;
BEGIN
/*!*/;
# at 1293
#:46:47 server idend_log_posRows_query
# insert into t1 values(null,2)
# at 1342
#:46:47 server idend_log_posTable_map: `mysqlslap`.`t1` mapped to number 314
# at 1392
#:46:47 server idend_log_posWrite_rows: table id 314 flags: STMT_END_F
BINLOG ‘
x+JEXh2wIAoAMQAAAD4FAACAAB1pbnNlcnQgaW50byB0MSB2YWx1ZXMobnVCwyKQ==
x+JEXhOwIAoAMgAAAHAFAAAAADoBAAAAAAEACW15c3Fsc2xhcAACdDEAAgMDAAIBAQA=
x+JEXh6wIAoAKAAAAJgFAAAAADoBAAAAAAEAAgAC/wCMAAEAAgAAAA==
‘/*!*/;
### INSERT INTO `mysqlslap`.`t1`
### SET
### @1=65676 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 1432
#:46:47 server idend_log_posXid =
COMMIT/*!*/;
# at 1459
3. 再看将备份恢复到一个新实例并启动后，执行 show master status 显示的信息：mysql> show master status\G*************************** 1. row ***************************File: binlog. Position:Binlog_Do_DB:Binlog_Ignore_DB:Executed_Gtid_Set: 70ec927f-4c6d-11ea-b88c-02023aba3fb1:row in set (0.00 sec)
可以发现与 Xtrabackup 2.4 不同的是，该备份的 xtrabackup_binlog_info 文件记录的信息并不准确，而备份恢复后显示的信息却是准确的。
原因
首先我们来看一下 Xtrabackup 8.0 针对 MySQL 8.0 备份的大致过程：1. start backup2. copy .ibd file3. backup non-InnoDB tables and files4. Executed FLUSH NO_WRITE_TO_BINLOG BINARY LOGS5. Selecting LSN and binary log position from p_s.log_status6. copy last binlog file7. Writing /mysql/backup/backup/binlog.index8. Writing xtrabackup_binlog_info9. Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS10. copy ib_buffer_pool11. completed OK!由以上步骤可知，Xtrabackup 8.0 对 MySQL 8.0 的备份与 Xtrabackup 2.4 略有不同，根据 percona 官方文档的信息，当 MySQL 8.0 中仅存在 InnoDB 引擎的表格时，不再执行ftwrl（当存在非 InnoDB 的表格或者使用 –slave-info 选项时会执行），而是根据上述步骤的第 5 步，Xtrabackup 8.0 会通过SELECT server_uuid, local, replication, storage_engines FROM performance_schema.log_status
来获取 LSN 、binlog position and Gtid。1. performance_schema.log_status 是 MySQL 8.0 提供给在线备份工具获取复制日志文件信息的表格。查询 log_status 表时，服务器将阻止日志的记录和相关的更改来获取足够的时间以填充该表，然后释放资源。Log_status 表通知在线备份工具应记录主库的 binlog 的哪个位点和 gtid_executed 的值，还有每个复制通道的 relay log。它还为各个存储引擎提供了相关信息，例如 InnoDB 存储引擎使用的最后一个日志序列号（LSN）和最后一个检查点的 LSN。2. 经过测试发现，当无数据写入时， performance_schema.log_status 提供的 binlog position 与 GTID 是一致的，但是当有大量数据持续写入时，该表格提供的 binlog position 与 GTID 信息将不再一致，如下图：
3. 既然 performance_schema.log_status 提供的信息不一致，那么为什么备份恢复后，GTID 没有缺失？这是因为 Xtrabackup 8.0 在备份过程中多了两步操作，FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 和 copy binlog，Xtrabackup 8.0 在备份完非 InnoDB 表格的文件时会先切换 binlog，然后将切换后的 binlog 也进行备份，这样使用该备份恢复的新实例在启动后不仅会读取 gtid_executed 表，也会读取 binlog 文件来更新 GTID，就可以保持与备份时 xtrabackup_binlog_info 文件记录的 binlog position 保持一致（需要注意的是 MySQL 8.0 的 gtid_executed 表格不再是当 binlog 切换时更新，而是会不断的实时更新，但需要注意在有大量数据写入时也不能做到和全局变量 gtid_exeuted 保持严格一致）。4. 当 MySQL 8.0 中存在非 InnoDB 的表格，比如 MyISAM 表时，Xtrabackup 8.0 会在执行完 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 后执行 ftwrl，此时查询 performance_schema.log_status 得到的 binlog position 与 GTID 是一致的，且备份恢复后 show master status 显示的信息也与 xtrabackup_binlog_info 文件记录的信息一致。
总结1. Xtrabackup 2.4 备份后生成的 xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，但是备份恢复后 show master status 显示的 GTID 是不准确的。2. Xtrabackup 8.0 在备份只有 InnoDB 表的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息不一定是准确的，但是备份恢复后 show master status 显示的 GTID 是准确的。3. Xtrabackup 8.0 在备份有非 InnoDB 表格的实例时，xtrabackup_binlog_info 文件记录的 GTID 信息是准确的，备份恢复后 show master status 显示的 GTID 也是准确的。
注意：此处的“准确”主要指 xtrabackup_binlog_info 文件中记录的 GTID 与备份中实际的 binlog position & 数据是否一致。
xtrabackup可以进行远程备份，答液不过有些麻烦。
解析binlog 指定数据库的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于解析binlog 指定数据库,深入剖析：如何指定数据库解析binlog,跪求MySQL Binlog Digger(日志挖掘分析工具) V4.4 绿色版软件百度云资源,XtraBackup 备份指定库的信息别忘了在本站进行查找喔。
