复制类型:
异步复制:主库执行完DDL/DML操作后发送给从库,此时主库认为此次操作成功,无论从库是否完成复制。
主库写完binlog后从库还没有开始或完成复制,导致主从数据暂时不一致。若此时主库宕机则从库将丢失部分数据;若此时从库被升为新的主库则整个数据库将永久丢失部分数据。
半同步复制:主库执行完DDL/DML操作后发送给从库,当其中一个从库完成复制并返回成功信息后,主库才认为此次操作成功。
主库只需等待一个从库的回应,且超时时间可以设置,超时后自动降级为异步复制。
同步复制:主库执行完DDL/DML操作后发送给从库,当所有从库都完成复制并返回成功信息后,主库才认为此次操作成功。
主库必须等待所有从库,延迟较大。
延迟复制:从库延迟一段时间再从主库复制。
组复制:
复制方式:
基于行的复制(ROW):主库直接记录数据并复制到从库
基于语句的复制(STATEMENT):主库记录造成数据更改的语句,从库读取并执行这些语句 → 通过在主库上记录二进制日志,在从库重放日志
基于GTID的复制:使用全局事务ID(GTID)
复制故障
与I/O线程相关的问题:
从服务器无法连接主服务器 → 检查网络能否访问
从服务器能连接到主服务器,但不断地断开连接 → 检查网络状况
从服务器延迟 → 中继日志损坏
检查复制用户的权限是否正确
需要replication slave权限
检查网络
使用ping检查能否连接
使用tcpdump查看网络状况
检查中继日志是否损坏
查看SQL线程错误,使用mysqlbinlog进行检查
在从库上执行SHOW SLAVE STATUS,查看Relay_Master_Log_File和Exec_Master_Log_Pos,执行CHANGE MASTER TO
或在从库的配置文件中添加参数relay_log_recovery=1
检查表是否一致
查询表的校验和,比较主从库上的表是否一致
CHECKSUM TABLE tbl_name
与SQL线程相关的问题:
从库收到SQL错误 → 查看错误信息
主从数据不一致 →
主从错误不一致 → slave_skip_counter
从库落后于主库(Seconds_Behind_Master增大) → 从库执行速度慢于主库
主库使用多线程并行执行语句,从库使用单线程串行执行binlog事件
提升硬件
调整性能选项
RESET语句
RESET MASTER
清除所有binlog.index文件中包含的binlog文件,并将binlog.index文件清空,然后从.000001开始创建一个新的binlog文件
此外还会将gtid_purged和gtid_executed这两个变量清除
与 PURGE BINARY LOG 语句的区别在于,PURGE 语句不会清空binlog.index文件,因此还会接着编号继续创建binlog文件;当slave正在复制时,使用 RESET MASTER 语句是不安全的
RESET SLAVE
清空slave_master_info,slave_relay_log_info两个表中数据,并清空relay log目录(删除所有的relay log),使slave忘记在master上进行复制对应的binlog文件position。在执行前需要使用 STOP SLAVE 停止slave的复制
MySQL同步机制
标签:忘记 半同步复制 停止 区别 manual 指定位置 stop str 是否一致
本条技术文章来源于互联网,如果无意侵犯您的权益请点击此处反馈版权投诉
本文系统来源:https://www.cnblogs.com/albert32/p/13404172.html