MySQL8.0 binlog进阶

MySQL8.0经过这几年的操揉磨治,已经上升到海平面了。其中binlog也悄然无声带来了不一样的变化。高可用核心复制基础binlog变化更应该进一步了解。从参数入手,了解带来的变化。

slave回放算法

slave_rows_search_algorithms
当使用基于 row-based复制格式的副本应用UPDATE或DELETE操作时,它必须在相关表中搜索匹配的行。用于执行此过程的算法使用表的一个索引作为首选执行搜索,如果没有合适的索引则

  • 5.7使用表扫描(默认值:TABLE_SCAN,INDEX_SCAN)
  • 8.0使用哈希表(默认值:INDEX_SCAN,HASH_SCAN)。

    MySQL8.0 binlog进阶_第1张图片

该算法首先评估表定义中的可用索引,以确定是否有任何合适的索引可以使用,如果有多种可能性,则判断哪个索引最适合操作。该算法忽略以下类型的索引:

1.全文索引
2.隐藏索引
3.计算索引
4.多值索引
5.包含的event语句中,不包含索引字段(跟记录binlog内容有关,参数对应binlog_row_image)

记录语句引用如果有合适的索引,则从候选索引中选择一个索引,其优先级顺序如下:

1.主键。
2.唯一的索引,其中索引中的每一列都有一个NOT NULL属性。如果有多个这样的索引可用,
  算法将选择这些索引中最左边的一个。
3.其他指数。如果有多个这样的索引可用,算法将选择这些索引中最左边的一个。

如算法无法找到合适的索引,或者只能找到非唯一的索引或包含空值的索引,则使用哈希表来帮助识别表记录。

该算法创建一个哈希表,其中包含UPDATE或DELETE操作中的行,键作为行的完整前图像。然后,算法遍历目标表中的所有记录。对于目标表中的每条记录,它确定该行是否存在于散列表中。如果在哈希表中找到该行,则更新目标表中的记录,并从哈希表中删除该行。当目标表中的所有记录都被检查后,算法验证哈希表现在是否为空。如果哈希表中还有任何不匹配的行,算法返回错误ER_KEY_NOT_FOUND并停止复制应用程序线程。

可以说到主从复制架构下从库回放机制中,存在唯一性质的键,保持之前一致。如无主键的情况,8.0版本已经脱离全表扫描的范围。这种情况利和弊两者兼容,不用说hash算法,对性能来说是最优的,并且在所有场景下都能正确工作。

binlog清除机制

  • binlog_expire_logs_seconds
    binlog可以以秒为单位进行清理,之前参数是按照expire_logs_days天为删除,有时因1天当中,可能会生成几百G的binlog日志,导致空间不够用,手动或脚本清理。现在不需要那麻烦。更贴合现状的解决方案。

  • binlog_expire_logs_auto_purge
    binlog用于控制日志自动清理机制,MySQL 8.0.29开始,可以通过将binlog_expire_logs_auto_purge系统变量设置为OFF来禁用binlog的自动清除。这优先于binlog_expire_logs_seconds的任何设置。

按照代码注释记录:expire_logs_days准备废弃,binlog_expire_logs_auto_purge 和binlog_expire_logs_seconds 需要配合使用。

    3  Warning	1287	'@@expire_logs_days' is deprecated and will be removed 
    in a future release. Please use binlog_expire_logs_seconds instead.


# ASSERT: If binlog_expire_logs_auto_purge is set to ON, then the server
#         MUST purge automatically binary log files according to the
#         binlog_expire_logs_seconds setting.
#

#
# ASSERT: If binlog_expire_logs_auto_purge is set to ON and both
#         binlog_expire_logs_seconds and expire_logs_days are set to 0,
#         then binary log files SHALL NOT be automatically purged.
#

binlog加密

  • binlog_encryption
    为此服务器上的binlog和relay文件启用加密,必须安装并配置一个密匙环插件来提供MySQL服务器的密匙环服务。MySQL Keyring

  • binlog_rotate_encryption_master_key_at_startup

     ON:每当服务重新启动时,将生成一个新的加密密钥,并将其用作所有后续binlog文件和relay的主密钥。
     OFF:将再次使用现有的binlog主密钥
    

binlog记录事件大小

  • binlog_row_event_max_size
    对于binlog记录的事件,最大大小的软限制(以字节为单位)。普遍情况,将存储在binlog中的行分组为大小不超过此设置默认值8192字节的事件。如果不能拆分事件,则可以超过最大大小(64bit:17179869184GB,32bit:4GB)。

binlog列字段记录

  • binlog_row_metadata
    配置在使用基于行的日志记录时向binlog添加的表元数据的数量。当设置为默认值MINIMAL时,只记录与SIGNED标志、列字符集和 地理空间类型Geometry类型相关的元数据。当设置为FULL时,将记录表的完整元数据,如列名、ENUM或set字符串值、PRIMARY KEY信息等。

扩展metadata的目的:

1.当元数据的表结构与源的表结构不同时,副本使用元数据来传输数据。
2.外部软件可以使用元数据解码行事件并将数据存储到外部数据库(如数据仓库)。

binlog对于JSON处理

  • binlog_row_value_options
    binlog记录修改JSON文档的一小部分内容,而不是写入完整的JSON值。适用于UPDATE语句,它使用JSON_SET()、JSON_REPLACE()和JSON_REMOVE()的任意序列修改JSON列。如果服务器无法生成部分更新,则使用完整文档。
    默认值是一个空字符串,这禁止使用该格式。
    还是对MySQL支持JSON数据做了一定的改善。

binlog压缩

  • binlog_transaction_compression
    binlog启用压缩机制。主节点压缩的binlog信息,传输到从节点将以压缩状态写入relay log,因此它们间接受益于复制拓扑中其他服务器执行的压缩。

  • binlog_transaction_compression_level_zstd
    binlog内容的压缩级别,随着压缩级别的增加,数据压缩比也会增加,这将减少事务有效负载所需的存储空间和网络带宽。但是,数据压缩所需的工作量也会增加,会占用原始服务器上的时间、CPU和内存资源。压缩工作量的增加与数据压缩比的增加没有线性关系。

binlog精准时间记录

  • original_commit_timestamp
    供内部复制使用。当在副本上重新执行事务时,这将被设置为事务在原始源上提交的时间,以自epoch以来的微秒为单位。这允许在整个复制拓扑中传播原始提交时间戳。复制延时的测量。

original_commit_timestamp: 事务在 master 提交 binlog 的时间戳(微秒),该时间戳每个节点都是一样的。
immediate_commit_timestamp: 事务在 slave(包括中继节点)提交 binlog 的时间戳(微秒),该时间戳在 relay log 中与 original_commit_timestamp 一样,在 slave 的 binlog 是完成回放的时间戳。

binlog事件解析内容:

#221028  8:58:55 server id 129  end_log_pos 276 CRC32 0x17f79afd        GTID    last_committed=0        sequence_number=1       rbr_
only=yes    original_committed_timestamp=1666918735086611   immediate_commit_timestamp=1666918735086611     transaction_length=390
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1666918735086611 (2022-10-28 08:58:55.086611 CST)
# immediate_commit_timestamp=1666918735086611 (2022-10-28 08:58:55.086611 CST)
/*!80001 SET @@session.original_commit_timestamp=1666918735086611*//*!*/;
/*!80014 SET @@session.original_server_version=80031*//*!*/;
/*!80014 SET @@session.immediate_server_version=80031*//*!*/;
SET @@SESSION.GTID_NEXT= '22228e8c-b0ee-11ec-a2d1-00163e23e2cc:70'/*!*/;

总结来说 就是将事务原始提交时间写在binlog 中,提交时间在复制链路上传递,使得 slave 可以计算事务延迟,更全面更精准

总结

从上述MySQL8.0的binlog变化中,选择最受益的项的话,必然是以下这3个:

1.slave_rows_search_algorithms:hash替代 table scan
2.binlog_expire_logs_seconds:秒级别清理机制
3.original_commit_timestamp:复制延迟观测新方式,更全面更精准binlog记录。

对于这些日常运维和解决问题提供的更好的助力。

 

你可能感兴趣的:(MySQL,算法,数据结构,java)