zoukankan      html  css  js  c++  java
  • MySQL主从复制什么原因会造成不一致,如何预防及解决?

    MySQL主从复制什么原因会造成不一致,如何预防及解决?
    
    
    一、导致主从不一致的原因主要有:
        1、人为原因导致从库与主库数据不一致(从库写入)。
        2、主从复制过程中,主库异常宕机。
        3、设置了ignore/do/rewrite等replication等规则。
        4、binlog非row格式。
        5、异步复制本身不保证,半同步存在提交读的问题,增强半同步起来比较完美。 但对于异常重启(Replication Crash Safe),从库写数据(GTID)的防范,还需要策略来保证。
        6、从库中断很久,binlog应用不连续,监控并及时修复主从。
        7、从库启用了诸如存储过程,从库禁用存储过程等。
        8、数据库大小版本/分支版本导致数据不一致?,主从版本统一。
        9、备份的时候没有指定参数 例如mysqldump --master-data=2等。
        10、主从sql_mode不一致。
        11、一主二从环境,二从的server id一致。
        12、MySQL自增列 主从不一致。
        13、主从信息保存在文件里面,文件本身的刷新是非事务的,导致从库重启后开始执行点大于实际执行点。
        14、采用5.6的after_commit方式半同步,主库当机可能会引起主从不一致,要看binlog是否传到了从库。
        15、启用增强半同步了(5.7的after_sync方式),但是从库延迟超时自动切换成异步复制。
    
    
    二、预防和解决的方案有:
        1、master:innodb_flush_log_at_trx_commit=1&sync_binlog=1
        2、slave:master_info_repository="TABLE"&relay_log_info_repository="TABLE"&relay_log_recovery=1
        3、设置从库库为只读模式。
        4、可以使用5.7增强半同步避免数据丢失等。
        5、binlog row格式
        6、必须引定期的数据校验机制。
        7、当使用延迟复制的时候,此时主从数据也是不一致的(计划内),但在切换中,不要把延迟从提升为主库哦~8、mha在主从切换的过程中,因主库系统宕机,可能造成主从不一致(mha本身机制导致这个问题)。
  • 相关阅读:
    centOS7 安装docker
    go中json的tag使用
    secureCRT操作redis-cli时, 不断追加ip:port
    golang gorm框架的默认时区问题
    java Date 转mysql timestamp 秒数不一致
    golang sqlx查询时, struct字段冲突
    golang入门time与string转换, time加减时间, 两个时间差
    idea设置每次打开手动选择工作空间
    panic: reflect.Value.Interface: cannot return value obtained from unexported field or method
    Render函数(4):开发可进行排序的表格组件
  • 原文地址:https://www.cnblogs.com/zhouwanchun/p/13159125.html
Copyright © 2011-2022 走看看