gpt4 book ai didi

mysql - MariaDB 复制 - 由于中继日志中的 gtid 语句导致从属滞后

转载 作者:行者123 更新时间:2023-11-29 10:18:16 24 4
gpt4 key购买 nike

我正在进行从 MySql 到 MariaDB 的迁移工作,其中涉及复制,一切正常,并且主 MySql (5.5.59) 到从属 MariaDB (10.1.26) 的兼容性很好。

当我启用从 MariaDB master 到 MariaDB Slave 的复制(相同版本:10.1.26)时,会出现问题。在某些情况下,在大量更新时,从属设备开始滞后。如果我将主服务器恢复到 MySql (5.5.59) 并复制到 MariaDB 中的同一个从服务器,则同一组更新永远不会出现滞后。

我检查了滞后的MariaDB从站中的中继日志,比较了MySql作为master时收到的日志和MariaDB作为master时收到的日志,唯一的区别是当master是MariaDB时我可以看到相关的语句到gtid。

当主服务器是 MariaDB 时,我想禁用中继日志上 gtid 语句的存在,并进行类似于没有 gtid 的“旧式”MySql 复制的复制,但我还没有找到是否可以这样做那个。

最佳答案

复制延迟是由于从服务器中的表 mysql.gtid_slave_pos 中设置的引擎造成的,默认情况下该表是 InnoDB,并且接收复制更新的表不是 InnoDB。

正如下面的链接所解释的,从服务器执行的每个事务也会导致 mysql.gtid_slave_pos 的更新,如果表的引擎不同,这可能会导致性能不佳(在我的情况下,服务器滞后 4000+)秒,更改 mysql.gtid_slave_pos 中的引擎,现在可以立即复制)。

https://mariadb.com/kb/en/library/mysqlgtid_slave_pos-table/

从 MariaDB 10.3.1 开始,引入了一个新参数来帮助解决此问题:gtid_pos_auto_engines 该参数将为复制涉及的每个引擎创建一个不同的表 mysql.gtid_slave_pos。不幸的是,使用以前版本的 MariaDB 似乎不可能实现这一点,表 mysql.gtid_slave_pos 必须是唯一的,其引擎的选择取决于 DBA 以及复制中涉及的表/查询

关于mysql - MariaDB 复制 - 由于中继日志中的 gtid 语句导致从属滞后,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49780059/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com