首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    MySQL复制性能优化和常见问题分析

    二进制日志文件并不是每次写的时候都会同步到磁盘,当发生宕机的时候,可能会有最后一部分数据没有写入到binlog中,这给恢复和复制带来了问题。当sync_binlog=1表示每写缓冲一次就同步到磁盘,表示同步写磁盘的方式来写binlog。也就是说每当向MySQL提交一次事务,MySQL将进行一次fsync之类的磁盘同步命令来将binlog_cache的数据强制刷到磁盘中sync_binlog的值默认为0,sync_binlog=0时表示采用操作系统机制进行缓冲数据同步。采用sync_binlog=1时,会增加磁盘IO的次数,会影响写入性能。sync_binlog=1时,并不是100%安全,会存在相应的问题。比如说使用Innodb引擎时,在一个事务发出commit前,会将binlog立即刷到磁盘中。如果这时候已经写入到binlog中,但是还没有提交就已经挂了,那么MySQL重启时,会将通过Redo log、Undo log将这个事务回滚掉,但是binlog已经记入了该事务信息,不能回滚掉。所以我们需要设置innodb_support_xa=1确保MySQL服务层的binlog和MySQL存储引擎层的Redo log、Undo log之间的数据一致性。

    02

    MySQL主从复制数据一致性校验和修复方法及自动化实现

    “MySQL主从复制”技术在互联网行业常见高可用架构中应用非常广泛,例如常见的一主一从复制架构、keepalived+MySQL双主(主从)复制架构、MHA+一主两从复制架构等等都应用了MySQL主从复制技术。但因主从复制是基于binlog的逻辑复制,难免出现复制数据不一致的风险,这个风险不但会引起用户数据访问前后不一致的风险,而且会导致后续复制出现1032、1062错误进而引起复制架构停滞的隐患,为了及时发现并解决这个问题,我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作,那么如何实现这项工作呢?又如何实现这项工作的自动化呢?我们来探讨这些问题。

    02
    领券