MySQL的二进制日志（binary log，简称binlog）是MySQL数据库中的一个重要特性，它记录了所有对数据库执行更改的SQL语句（如INSERT、UPDATE、DELETE等），以及每个语句执行的确切时间。二进制日志是MySQL数据复制、数据恢复和审计分析的基础。
一、作用
-
数据复制：二进制日志是MySQL主从复制的基础。主服务器上的二进制日志包含了所有更改数据的语句，这些语句可以被复制到从服务器并重新执行，从而实现数据的同步。
-
数据恢复：在数据丢失或损坏的情况下，可以使用二进制日志来恢复数据。通过回放二进制日志中的操作，可以将数据库恢复到特定的时间点。
-
审计：二进制日志记录了所有对数据库执行更改的操作，因此可以用于审计和分析数据库的更改历史。
二、使用方法
-
启用二进制日志：要启用二进制日志，需要在MySQL的配置文件（通常是my.cnf或my.ini）中设置log_bin变量。例如：
[mysqld] log_bin=mysql-bin
这会在MySQL的数据目录中创建以mysql-bin为前缀的二进制日志文件。
-
查看二进制日志：可以使用SHOW BINARY LOGS;命令查看当前的二进制日志文件列表，以及每个文件的大小。
-
查看二进制日志内容：可以使用mysqlbinlog工具来查看二进制日志文件的内容。例如：
mysqlbinlog mysql-bin.000001
这会显示名为mysql-bin.000001的二进制日志文件的内容。
-
设置过期时间：为了防止二进制日志占用过多的磁盘空间，可以设置二进制日志的过期时间。例如，要设置日志保留7天，可以在配置文件中添加：
[mysqld] expire_logs_days=7
-
日志刷新：可以使用FLUSH LOGS;命令来关闭当前的二进制日志文件并开启一个新文件，这在进行日志管理时很有用。
-
日志恢复：在数据恢复场景下，可以使用mysqlbinlog工具将二进制日志的内容应用到数据库中。例如：
mysqlbinlog mysql-bin.000001 | mysql -u root -p
三、注意事项
- 启用二进制日志会对性能产生一定影响，因为每个数据更改操作都需要写入日志。
- 需要定期检查和管理二进制日志文件，以避免磁盘空间被耗尽。
- 在使用二进制日志进行数据恢复时，需要确保按照日志记录的顺序应用更改。
二进制日志是MySQL数据库管理中的一个强大工具，合理使用可以极大地提高数据的可靠性和安全性。
四、bin_log)的几种记录格式
支持三种不同的记录格式，分别是：语句级复制（Statement-Based Replication, SBR）、行级复制（Row-Based Replication, RBR）和混合模式复制（Mixed-Based Replication, MBR）。每种格式都有其特定的用途和优缺点。
1. 语句级复制（SBR）
在语句级复制模式下，二进制日志记录的是对数据库进行更改的SQL语句。这意味着，复制过程中，从服务器会重新执行主服务器上执行的相同SQL语句。
优点：
- 日志文件较小，因为只记录了SQL语句。
- 对于某些操作，如大批量插入，性能较好。
缺点：
- 在某些情况下可能导致数据不一致，特别是当SQL语句的结果依赖于数据库的当前状态时（例如，依赖于非确定性函数的结果）。
- 并不是所有的语句都可以安全地复制，如带有UUID()或NOW()等函数的语句。
2. 行级复制（RBR）
在行级复制模式下，二进制日志记录的是数据更改前后的行的具体内容。这意味着，复制过程中，从服务器会对每一行数据进行相应的插入、更新或删除操作。
优点：
- 可以确保数据的一致性，因为复制的是实际更改的数据，而不是执行的SQL语句。
- 避免了SBR模式下可能出现的非确定性问题。
缺点：
- 日志文件可能会非常大，特别是在进行大量数据更改的操作时。
- 对于某些类型的查询（如大批量插入），性能可能不如SBR。
3. 混合模式复制（MBR）
混合模式复制结合了SBR和RBR的优点。在这种模式下，MySQL会根据操作的类型和内容自动选择使用SBR还是RBR。对于大多数操作，它会使用SBR，但在可能导致数据不一致的情况下，它会切换到RBR。
优点：
- 结合了SBR和RBR的优点，能够在保证数据一致性的同时，尽可能地减小日志文件的大小。
- 自动选择最适合的复制方式，减少了管理员的配置和管理工作。
缺点：
- 在某些复杂的场景下，可能会因为频繁切换复制模式而影响性能。
五、设置二进制日志格式
可以通过在MySQL的配置文件中设置binlog_format选项来指定二进制日志的格式，例如：
[mysqld] binlog_format = ROW # 设置为行级复制
可用的值有STATEMENT（SBR）、ROW（RBR）和MIXED（MBR）。更改此设置需要重启MySQL服务。
选择哪种格式取决于具体的应用场景、性能要求和数据一致性需求。在实际应用中，混合模式因其灵活性和平衡性，被广泛用于各种场景。
会话级别动态修改：
全局动态修改：
六、二进制日志（binlog)解析方法
解析MySQL二进制日志（binlog）内容可以根据不同的需求采用不同的方法，包括基于位点（log position）、基于时间、基于全局事务标识符（GTID）解析，以及如何处理加密的binlog。下面分别介绍这些方法及其应用示例。
基于位点解析
位点（log position）是指在二进制日志文件中的位置，可以用来指定从哪个位置开始解析日志。
示例：
假设你想从位点12345开始解析名为mysql-bin.000001的日志文件：
mysqlbinlog --start-position=12345 /path/to/mysql-bin.000001
基于时间解析
基于时间解析允许你指定一个时间范围，只解析该时间范围内的日志事件。
示例：
假设你想解析2023-04-01 10:00:00到2023-04-01 10:59:59之间的日志事件：
mysqlbinlog --start-datetime="2023-04-01 10:00:00" --stop-datetime="2023-04-01 10:59:59" /path/to/mysql-bin.000001
基于GTID解析
GTID（全局事务标识符）是MySQL 5.6及更高版本中引入的，用于唯一标识每个事务。基于GTID解析可以精确地定位到特定的事务。
示例：
假设你想解析GTID为3E11FA47-71CA-11E1-9E33-C80AA9429562:23的事务：
mysqlbinlog --start-gtid-set="3E11FA47-71CA-11E1-9E33-C80AA9429562:23" /path/to/mysql-bin.000001
加密binlog日志
MySQL提供了binlog加密功能，以保护敏感数据不被未授权访问。
启用binlog加密：
- 在MySQL配置文件（通常是my.cnf或my.ini）中设置binlog_encryption = ON。
- 设置master_verify_checksum和binlog_checksum为CRC32以启用校验和。
- 为加密提供密钥，通过keyring插件管理。
解析加密的binlog
要解析加密的binlog，你需要确保mysqlbinlog工具可以访问用于加密的密钥。这通常意味着你需要在同一台服务器上或者配置有相同keyring插件和密钥的服务器上进行解析。
示例：
mysqlbinlog /path/to/mysql-bin.000001
只要mysqlbinlog工具可以访问密钥，使用方法与解析未加密的binlog相同。
直接解析某个库的binlog
mysqlbinlog工具本身不支持直接过滤特定数据库的事件，但你可以通过管道（pipe）和文本处理工具（如grep）组合使用来实现这一目的。
示例：
假设你想解析名为mydatabase的数据库相关的日志事件：
mysqlbinlog /path/to/mysql-bin.000001 | grep -i 'mydatabase'
这将输出所有提到mydatabase的日志行，但请注意，这种方法可能不会完全准确，因为它依赖于文本匹配，可能会匹配到注释或其他非目标内容中的数据库名。
通过上述方法，你可以根据不同的需求灵活地解析MySQL的二进制日志内容。
七、MySQL二进制日志清除
MySQL二进制日志（binlog）是MySQL数据库的重要组成部分，用于记录所有修改数据库数据或结构的语句。随着时间的推移，binlog文件可能会占用大量磁盘空间，因此需要定期清理。以下是自动清除和手动删除指定binlog之前的文件的方法，以及进行清除时的注意事项。
自动清除binlog（尽量采用自动清除）
MySQL提供了自动清除旧binlog文件的机制，通过设置expire_logs_days参数来实现。这个参数定义了binlog文件在被自动删除前可以保留的天数。
示例：
假设你想让binlog文件保留7天，可以在MySQL的配置文件（通常是my.cnf或my.ini）中设置如下：
[mysqld] expire_logs_days = 7
修改配置后，需要重启MySQL服务使设置生效。MySQL将自动删除超过7天的binlog文件。
手动删除指定binlog之前的文件
如果需要手动删除某个时间点之前的所有binlog文件，可以使用PURGE BINARY LOGS语句。
示例：
-
按文件名删除：删除文件名小于或等于mysql-bin.000010的所有binlog文件。
PURGE BINARY LOGS TO 'mysql-bin.000010';
-
按日期删除：删除2023-04-01 00:00:00之前的所有binlog文件。
PURGE BINARY LOGS BEFORE '2023-04-01 00:00:00';
binlog清除注意事项
-
备份：在执行清除操作之前，确保已经备份了需要保留的binlog文件，以防万一需要恢复数据。
-
复制延迟：如果在主从复制环境中，确保从服务器已经应用了要删除的binlog中的所有更改。删除尚未应用到从服务器的binlog文件，可能会导致复制中断。
-
GTID模式下的注意事项：在GTID模式下，尽量避免使用基于文件名的清除方法，因为这可能会导致GTID序列中出现间隙，影响数据的一致性和恢复。
-
监控磁盘空间：定期监控MySQL服务器的磁盘空间使用情况，以便及时调整expire_logs_days参数或手动清理binlog，防止磁盘空间耗尽。
通过合理设置自动清除策略并注意手动清除的细节，可以有效管理binlog文件的生命周期，确保数据库的稳定运行和数据的安全。
八、binlog落盘频率
对于数据恢复和复制非常重要。binlog的落盘频率，即binlog数据写入磁盘的频率，是由几个系统变量控制的，主要包括sync_binlog和innodb_flush_log_at_trx_commit。
sync_binlog
sync_binlog变量控制每多少次事务提交后，MySQL将binlog缓冲刷新到磁盘。这个设置直接影响了数据的持久性和性能。
- 当sync_binlog=0时，MySQL不会主动将binlog缓冲区的数据同步到磁盘。系统会根据操作系统的缓冲策略来决定何时写入磁盘，这可能会导致MySQL崩溃时数据丢失。
- 当sync_binlog=1时，每次事务提交都会同步binlog到磁盘。这提供了最高级别的数据安全性，但可能会对性能产生影响，因为每次事务提交都需要磁盘I/O操作。
- 当sync_binlog=N（N>1）时，每N次事务提交会同步一次binlog到磁盘。这是一种折中方案，可以在数据安全性和性能之间取得平衡。
innodb_flush_log_at_trx_commit
对于使用InnoDB存储引擎的表，innodb_flush_log_at_trx_commit变量也会影响数据的落盘频率。这个变量控制InnoDB事务日志的写入和刷新行为。
- 当innodb_flush_log_at_trx_commit=1时，每次事务提交都会将日志写入并刷新到磁盘，确保了事务的ACID属性，但可能会影响性能。
- 当innodb_flush_log_at_trx_commit=0时，日志每秒写入和刷新到磁盘一次，提高了性能，但在发生崩溃时可能会丢失最近一秒的事务。
- 当innodb_flush_log_at_trx_commit=2时，日志每次事务提交时写入到磁盘，但只在每秒刷新一次。这种方式在性能和数据安全性之间提供了一个折中选择。
总结
binlog的落盘频率是通过sync_binlog和innodb_flush_log_at_trx_commit这两个变量来控制的，它们决定了数据安全性与系统性能之间的平衡。在设置这些参数时，需要根据具体的业务需求和系统环境来做出合理的选择。高频的落盘操作可以提高数据的安全性，但可能会降低系统的整体性能；而较低的落盘频率虽然可以提升性能，但在发生系统崩溃时可能会导致数据丢失。
- 在某些复杂的场景下，可能会因为频繁切换复制模式而影响性能。
![[工业自动化-1]：PLC架构与工作原理](https://img-blog.csdnimg.cn/ce10a1471ed14382bc58364cf8bd5209.png)
还没有评论，来说两句吧...