注册 登录
  • 欢迎访问"运维那点事",推荐使用Google浏览器访问,可以扫码关注本站的"微信公众号"。
  • 如果您觉得本站对你有帮助,那么可以扫码捐助以帮助本站更好地发展。

MySQL 5.7新特性:新增gtid_executed,避免GTID复制必须开启log_slave_updates

MySQL 5.7 彭东稳 5710次浏览 已收录 0个评论

MySQL 5.6版本开启GTID模式,必须打开参数log_slave_updates,简单来说就是必须在从机上再记录一份二进制日志。这样的无论对性能还是存储的开销,无疑会相应的增大。而MySQL 5.7版本开始无需在GTID模式下启用参数log_slave_updates,其中最重要的原因在于5.7在mysql库下引入了新的表gtid_executed,其表结构如下所示:

简单来说,该表会记录当前执行的GTID。列source对应UUID,列interval_start/interval_end表示的是事务号。在MySQL 5.6中必须配置参数log_slave_updates的最重要原因在于当slave重启后,无法得知当前slave已经运行到的GTID位置,因为变量gtid_executed是一个内存值:

所以MySQL 5.6的处理方法就是启动时扫描最后一个二进制日志,获取当前执行到的GTID位置信息。当然,如果DBA不小心将二进制日志删除了,那么这又会带来灾难性的问题。

因此,MySQL 5.7将gtid_executed这个值给持久化了。采用的技巧与MySQL 5.6处理SQL thread保存位置的方式一样,即将GTID值持久化保存在一张InnoDB表中,并与用户事务一起进行提交,从而实现数据的一致性:

需要注意的是表mysql.gtid_executed是在主服务器和从服务器上有进行更新的,而表slave_relay_log_info仅在从服务器上更新。

MySQL 5.7对于表mysql.gtid_executed的更新策略也有些不同,如果没有主服务器没有开启log_bin或者从服务器没有开启log_slave_updates,其会每一个事物更新表gtid_executed,这样服务器重启后可以快速知道当前服务器执行到的GTID位置。因此,用户可能在服务器上看到类似如下的内容:

那这样岂不是表gtid_executed中的记录会疯狂增长。为此,MySQL 5.7又引入了新的线程,用来对此表进行压缩,该线程如下所示:

参数gtid_executed_compression_period用来控制每执行多少个事务,对此表进行压缩,默认值为1000。因此,过一段时间后,上述的表mysql.gtid_executed会压缩成如下的内容:

若MySQL服务器启用了二进制日志,则表mysql.gtid_executed的更新仅在二进制rotation时发生,因为发生重启等情况依旧可以通过扫描二进制日志判断得知当前运行的GTID位置。

开启log_slave_updates后,主从服务器性能有多少的差异,这是一个蛮有意思的问题。


如果您觉得本站对你有帮助,那么可以支付宝扫码捐助以帮助本站更好地发展,在此谢过。
喜欢 (1)or分享 (0)
关于作者:

您必须 登录 才能发表评论!