Mysql主从同步架构图和原理

本文详细阐述了MySQL的异步复制机制,包括从Master节点到Slave节点的数据复制流程、配置步骤以及如何实现双主配置。重点讨论了Replication的基本原理、配置方法、双主设置和应用层的负载均衡策略,旨在帮助开发者理解和实施MySQL的复制解决方案。
架构图



Replication原理   
Mysql 的 Replication 是一个异步的复制过程,从一个MySQL节点(称之为Master)复制到另一个MySQL节点(称之Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(SQL 线程和 I/O 线程)在 Slave 端,另外一个线程(I/O 线程)在 Master 端。 
  
要实现 MySQL 的 Replication ,首先必须打开 Master 端的 Binary Log,因为整个复制过程实际上就是 Slave 从 Master 端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 
  
看上去MySQL的Replication原理非常简单,总结一下: 
     * 每个从仅可以设置一个主。 
    * 主在执行sql之后,记录二进制log文件(bin-log)。 
    * 从连接主,并从主获取binlog,存于本地relay-log,并从上次记住的位置起执行sql,一旦遇到错误则停止同步。 
   
从这几条Replication原理来看,可以有这些推论: 
     * 主从间的数据库不是实时同步,就算网络连接正常,也存在瞬间,主从数据不一致。 
    * 如果主从的网络断开,从会在网络正常后,批量同步。 
    * 如果对从进行修改数据,那么很可能从在执行主的bin-log时出现错误而停止同步,这个是很危险的操作。所以一般情况下,非常小心的修改从上的数据。 
    * 一个衍生的配置是双主,互为主从配置,只要双方的修改不冲突,可以工作良好。 
    * 如果需要多主的话,可以用环形配置,这样任意一个节点的修改都可以同步到所有节点。 
   
主从设置 
  
因为原理比较简单,所以Replication从MySQL 3就支持,并在所有平台下可以工作,多个MySQL节点甚至可以不同平台,不同版本,不同局域网。做Replication配置包括用户和my.ini(linux下为my.cnf)两处设置。 
  
首先在主MySQL节点上,为slave创建一个用户: 
  
GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'192.168.1.10' IDENTIFIED BY 'slave'; 
  
实际上,为支持主从动态同步,或者手动切换,一般都是在所有主从节点上创建好这个用户。然后就是MySQL本身的配置了,这需要修改my.cnf或者my.ini文件。在mysqld这一节下面增加: 
  
server-id=1    
auto-increment-increment=2     
auto-increment-offset=1     
log-bin     
binlog-do-db=mstest     
binlog_format=mixed 
  
master-host=192.168.1.62    
master-user=slave     
master-password=slave     
replicate-do-db=mstest 
  
上面这两段设置,前一段是为主而设置,后一段是为从设置的。也就是说在两个MySQL节点上,各加一段就好。binlog-do-db和 replicate-do-db就是设置相应的需要做同步的数据库了,auto-increment-increment和auto- increment-offset是为了支持双主而设置的(参考下一节),在只做主从的时候,也可以不设置。 
  
双主的设置 
  
从原理论来看MySQL也支持双主的设置,即两个MySQL节点互为主备,不过虽然理论上,双主只要数据不冲突就可以工作的很好,但实际情况中还 是很容发生数据冲突的,比如在同步完成之前,双方都修改同一条记录。因此在实际中,最好不要让两边同时修改。即逻辑上仍按照主从的方式工作。但双主的设置 仍然是有意义的,因为这样做之后,切换主备会变的很简单。因为在出现故障后,如果之前配置了双主,则直接切换主备会很容易。 
  双主在设置时,只需将上面的一段设置复制一份,分别写入两个MySQL节点的配置文件,但要修改相应的server-id,auto- increment-offset和master-host。auto-increment-offset就是为了让双主同时在一张表中进行添加操作时不 会出现id冲突,所以在两个节点上auto-increment-offset设置为不同的值就好。  另:不要忘了,在两个节点上都为对方创建用户。  应用层的负载均衡  本文只介绍了MySQL自身的Repilication配置,在上面的图中也可以看出,有了Replication,还需要应用层(或者中间件)做一个负载均衡,这样才能最大程度发挥MySQL Replication的优势,这些将在以后探讨。


Mysql的 Replication 是一个异步的复制过程,从一个 Mysql instace(我们称之为 Master)复制到另一个 Mysql instance(我们称之 Slave)。在 Master 与 Slave 之间的实现整个复制过程主要由三个线程来完成,其中两个线程(Sql线程和IO线程)在 Slave 端,另外一个线程(IO线程)在 Master 端。
  要实现 MySQL 的 Replication ,首先必须打开 Master 端的Binary Log(mysql-bin.xxxxxx)功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全 顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “—log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。
  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,所以两端的数据是完全一样的。
### MySQL 主从半同步复制的原理与架构 #### 半同步复制概述 MySQL 的主从半同步复制是一种增强型的复制方式,在传统异步复制的基础上引入了更强的一致性保障机制。相比于完全异步复制,半同步复制能够在一定程度上确保主库提交的数据至少被一个从库接收到并写入 relay log 后才返回成功确认给客户端[^1]。 #### 半同步复制的工作流程 以下是半同步复制的主要工作流程: - 当主库(Master)接收到来自客户端的事务提交请求时,它会将该事务的日志事件发送到从库(Slave)。 - 从库接收到日志事件后,将其写入本地的 relay log 中,并向主库反馈已接收到消息的通知。 - 主库只有在收到从库的成功响应之后才会完成事务提交并向客户端返回结果。 - 如果超出了预设的时间阈值而仍未获得任何从库的认可,则退化为普通的异步模式继续运行直到再次满足条件恢复成半同步状态[^4]。 此过程中涉及到了三个关键线程的作用描述如下表所示: | **角色** | **位置** | **职责说明** | |----------------|-------------|------------------------------------------------------------------------------------------------| | IO Thread | Slave端 | 负责连接 Master 并读取其 Binary Log 文件中的更新记录存放到自身的 Relay Logs 中等待后续处理 | | SQL Thread | Slave端 | 将已经保存下来的 Relay Logs 解析出来再依次重放这些操作从而达到最终保持两者之间数据一致性的目的 | | Dump Thread | Master端 | 接收来自 Slaves 发起建立链接后的持续传输 Binlog 给对方直至断开为止 | 以上即构成了整个基于插件形式实现出来的 Semi-Sync Replication 技术框架下的核心组成部分之一[^3]。 #### 原理图与架构图示例 由于无法直接提供图片资源,请参照以下文字表述构建相应的图表结构: ##### 图形元素定义 - 使用矩形框表示各个节点 (Master Slave); - 运用箭头线条展示不同方向上的通信路径以及具体交互内容标签标注清楚每一步骤含义; ##### 示例代码片段用于生成图形工具输入源文件 ```dot digraph G { node [shape=box]; master[label="Master\n(Dump Thread)", color=blue]; slave_io[label="Slave\n(IO Thread)",color=green]; slave_sql[label="Slave\n(SQL Thread)",color=purple]; client -> master [label="Transaction Commit"]; master -> slave_io [label="Send binlog events"]; slave_io -> master [label="Acknowledge receipt"]; slave_io -> slave_sql [label="Write to relay logs"]; } ``` 利用 Graphviz 或其他支持 DOT Language 的绘图软件可渲染出直观形象化的拓扑关系布局效果[^2]。 #### 设计注意事项 当考虑采用此类解决方案时需要注意几个方面的问题包括但不限于网络延迟对于整体性能的影响程度评估分析、灾难恢复策略制定完善等方面因素考量[^1]。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值