MySQL主从复制架构如图:
MySQL主从复制原理:
master服务器将数据的改变记录二进制日志,当master上的数据发生改变时,则将其改变写入二进制日志中,salve服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/OThread请求master二进制事件,同时主节点为每个I/O线程启动一个dump线程,用于向其发送二进制事件,并保存至从节点本地的中继日志中,从节点将启动SQL线程从中继日志中读取二进制日志,在本地重放,使得其数据和主节点的保持一致,最后I/OThread和SQLThread将进入睡眠状态,等待下一次被唤醒。
MySQL Replication 复制过程:
- Slave 服务器上执行start slave,开启主从复制开关。 此时,Slave 服务器上的 IO 线程会通过 Master 服务器上授权的有复制权限的用户请求连接 Master 服务器,并请求从指定 binlog 日志文件的指定位置之后发送 binlog 日志内容。(日志文件名和位置就是在配置主从复制任务时执行change master命令时指定的)
- Master 服务器接收到来自 Slave 服务器的 IO 线程的请求后,Master 服务器上的 IO 线程根据 Slave 服务器的 IO 线程请求的信息,读取指定 binlog 日志文件指定位置之后的 binlog 日志信息,然后返回给 Slave 端的 IO 线程。返回的信息中除了 binlog 日志内容外,还有本次返回日志内容后在 Master 服务器端的新的 binlog 文件名以及在 binlog 中的下一个指定更新位置。
- 当 Slave 服务器的 IO 线程获取来自 Master 服务器上 IO 线程发送的日志内容及日志文件和位置点后,将 binlog 日志内容依次写入到 Slave 端自身的 relay log(即中继日志)文件(mysql-relay-bin.xxxxxx)的最末端,并将新的 binlog 文件名和位置记录到 master-info 文件中,以便下一次读取 Master 端新 binlog 日志时,能告诉 Master 服务器需要从新 binlog 日志的哪个文件哪个位置开始请求新的 binlog 日志内容。
- Slave 服务器端的 SQL 线程会实时检测本地 relay log 中新增加的日志内容,然后及时的把 relay log 文件中的内容解析成在 Master 端曾经执行的 SQL 语句的内容,并在自身 Slave 服务器上按语句的顺序执行应用这些 SQL 语句,应用完毕后清理应用过的日志。
- 经过了上面的过程,就可以确保在 Master 端和 Slave 端执行了同样的 SQL 语句。当复制状态正常的情况下,Master 端和 Slave 端的数据是完全一样的。
发表评论
共 0 条评论
暂无评论