我的编程空间,编程开发者的网络收藏夹
学习永远不晚

MySQL同步机制

短信预约 信息系统项目管理师 报名、考试、查分时间动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

MySQL同步机制


	MySQL同步机制
[数据库教程]

复制步骤:

  1. Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容
  2. Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外,还包括本次返回的信息在 Master 端的Binary Log 文件的名称以及在 Binary Log 中的位置
  3. Slave 的 IO 线程接收到信息后,将接收到的日志内容依次写入到 Slave 端的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端,并将读取到的Master端的bin-log的文件名和位置记录到master- info文件中,以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容,请发给我”
  4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后,会马上解析该 Log 文件中的内容成为在 Master 端真实执行时候的那些可执行的 Query 语句,并在自身执行这些 Query。这样,实际上就是在 Master 端和 Slave 端执行了同样的 Query,所以两端的数据是完全一样的

技术图片

复制类型:

异步复制:主库执行完DDL/DML操作后发送给从库,此时主库认为此次操作成功,无论从库是否完成复制。

  主库写完binlog后从库还没有开始或完成复制,导致主从数据暂时不一致。若此时主库宕机则从库将丢失部分数据;若此时从库被升为新的主库则整个数据库将永久丢失部分数据。

半同步复制:主库执行完DDL/DML操作后发送给从库,当其中一个从库完成复制并返回成功信息后,主库才认为此次操作成功。

      主库只需等待一个从库的回应,且超时时间可以设置,超时后自动降级为异步复制。

同步复制:主库执行完DDL/DML操作后发送给从库,当所有从库都完成复制并返回成功信息后,主库才认为此次操作成功。

          主库必须等待所有从库,延迟较大。

延迟复制:从库延迟一段时间再从主库复制。

组复制:

技术图片

复制方式:

  1. 基于行的复制(ROW):主库直接记录数据并复制到从库
  2. 基于语句的复制(STATEMENT):主库记录造成数据更改的语句,从库读取并执行这些语句 → 通过在主库上记录二进制日志,在从库重放日志
  3. 基于GTID的复制:使用全局事务ID(GTID)

复制故障

与I/O线程相关的问题:

  • 从服务器无法连接主服务器 → 检查网络能否访问
  • 从服务器能连接到主服务器,但不断地断开连接 → 检查网络状况
  • 从服务器延迟 → 中继日志损坏
  1. 检查复制用户的权限是否正确
    需要replication slave权限
  2. 检查网络
    使用ping检查能否连接
    使用tcpdump查看网络状况
  3. 检查中继日志是否损坏
    查看SQL线程错误,使用mysqlbinlog进行检查
    在从库上执行SHOW SLAVE STATUS,查看Relay_Master_Log_File和Exec_Master_Log_Pos,执行CHANGE MASTER TO
    或在从库的配置文件中添加参数relay_log_recovery=1
  4. 检查表是否一致
    查询表的校验和,比较主从库上的表是否一致
    CHECKSUM TABLE tbl_name

与SQL线程相关的问题:

  1. 从库收到SQL错误 → 查看错误信息
  2. 主从数据不一致 → 
  3. 主从错误不一致 → slave_skip_counter
  4. 从库落后于主库(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同步机制

原文地址:https://www.cnblogs.com/albert32/p/13404172.html

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

MySQL同步机制

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

MySQL同步机制

复制步骤:Slave 上面的IO线程连接上 Master,并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容Master 接收到来自 Slave 的 IO 线程的请求后,通过负责复制的 IO 线程根据请求信息读取指定日志指定位置之后的日志信息,
MySQL同步机制
2015-09-09

OpenCL-3-同步机制

由于OpenCL在异构系统上进行计算,需要管理并调度多个设备,就需要在设备之间内部或外部进行数据交互以及同步。  根据同步的类型,同步分为两部分:宿主机端同步和设备端同步。  设备端同步主要指同一个内核内不同线程之前的同步,主要用于保证数据
2023-01-31

MySQL主从半同步复制

目录一、半同步复制1.半同步复制概念2.配置半同步1)主库操作2)从库操作3)额外参数一、半同步复制1.半同步复制概念从MYSQL5.5开始,支持半自动复制。之前版本的MySQL Replication都是异步(asynchronous)的,主库在执行完一些事
MySQL主从半同步复制
2022-01-18

AndroidNTP时间同步机制详解

这篇文章主要为大家介绍了AndroidNTP时间同步机制实例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
2022-11-13

MySQL 半同步复制的实现

目录一、半同步复制介绍二、搭建半同步复制2.1 安装半同步插件2.2 启用半同步复制三、配置半同步复制四、监控半同步复制一、半同步复制介绍mysql基础复制有三种模式:异步复制/同步复制/半同步复制,3种模式各有利弊,下面对各种复制模式的
MySQL 半同步复制的实现
2024-09-04

kafka副本同步机制是什么

Kafka副本同步机制是指Kafka集群中的副本之间的数据同步方式。在Kafka中,每个分区都有多个副本,其中一个被选为leader副本,其余副本为follower副本。副本同步机制保证了数据在分区的所有副本之间的一致性。Kafka使用的是
2023-10-12

编程热搜

目录