MySQL中的事务并行复制优化

发布时间:2024年01月23日

MySQL 8.0.35版本之前,数据库管理员可以通过binlog_transaction_dependency_tracking系统变量来配置如何生成二进制日志(binary log)中的依赖信息。这对于具有多线程副本(即replica_parallel_workersslave_parallel_workers大于0的情况)的复制源服务器而言尤为重要,因为它帮助副本确定哪些事务可以并行执行。

事务依赖信息的表示

所谓依赖信息是指复制源服务器写入二进制日志的逻辑时间戳。每个事务都有两个逻辑时间戳:

  • sequence_number:在给定的二进制日志文件中,第一个事务此值为1,第二个为2,以此类推。每个新的日志文件序列号重新开始计数。

  • last_committed:指与当前事务发生冲突的最近提交事务的序列号。此值始终小于sequence_number。

设置binlog_transaction_dependency_tracking变量实际上是选择用于计算这些逻辑时间戳方案的方式。MySQL提供了以下几种方案:

  1. COMMIT_ORDER(默认值):如果第一个事务的提交时间窗口与第二个事务的提交时间窗口重叠,则认为这两个事务是独立的。提交时间窗口从事务的最后一条语句执行完毕直到存储引擎提交结束之后立即开始和结束。

  2. WRITESET:在COMMIT_ORDER的基础上,结合第二种基于事务写集的方案来计算逻辑时间戳。每个事务中的行会增加一组哈希值到事务的写集中,这组哈希值对应于行中唯一键的每一个。如果存在写集的重叠,即同一数字(哈希)出现在两个事务的写集中,则这两个事务被认为是有冲突的。

  3. WRITESET_SESSION:如果满足以下任一条件,则认为两个事务是依赖的:

    • 根据WRITESET,事务是依赖的。
    • 事务在同一个用户会话中提交。

WRITESETWRITESET_SESSION模式下,如果事务的写集为空或部分空,或者更新没有主键或唯一键的表,或者更新外键关系中的父表,则源使用COMMIT_ORDER来生成依赖信息。

配置考虑

要将binlog_transaction_dependency_tracking设置为WRITESETWRITESET_SESSIONtransaction_write_set_extraction必须设置为非OFF的值(默认值XXHASH64就足够)。而当binlog_transaction_dependency_tracking的值为WRITESETWRITESET_SESSION时,不能改变transaction_write_set_extraction的值。任何改变只有在副本停止并重新启动后才会生效。

binlog_transaction_dependency_history_size的值决定了保留和检查的行哈希数量,这些哈希用于标识最近更改了给定行的事务。

群组复制和性能优化

MySQL的群组复制(Group Replication)在证书授权后的应用阶段进行自己的并行化处理,这个过程与binlog_transaction_dependency_tracking的设置值无关。然而,该变量确实影响了群组复制成员如何编写二进制日志中的事务。这些日志中的依赖信息用于协助从捐赠者的二进制日志进行状态传输的分布式恢复过程,即当成员加入或重新加入群组时进行的过程。对于群组成员而言,根据群组工作负载的不同,将binlog_transaction_dependency_tracking设置为WRITESET可能会提高性能。

结论

虽然binlog_transaction_dependency_tracking在MySQL 8.0.35版本已经被弃用,但在此之前,它为MySQL的复制架构提供了灵活性,并允许管理员优化多线程副本的并行处理能力。了解这一机制及其影响可以帮助管理员更好地理解MySQL复制背后的工作原理,以及如何针对特定的系统和需求进行调整。

文章来源:https://blog.csdn.net/jkzyx123/article/details/135778132
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。