• 一张图让你牢记MySQL主从复制原理|原创


    本文深入浅出的讲解了MySQL面试中的必考内容——主从同步原理,牢记文中的主从同步流程图即可!

    点击上方“后端开发技术”,选择“设为星标” ,优质资源及时送达

    为什么需要主从复制

    1、读写分离,增强MySQL数据库的可用性。

    2、做数据的热备。

    3、架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问的频率,提高单个机器的I/O性能。

    什么是mysql的主从复制?

    MySQL 主从复制是指数据可以从一个MySQL数据库服务器主节点复制到一个或多个从节点。MySQL 默认采用异步复制方式,这样从节点不用一直访问主服务器来更新自己的数据,数据的更新可以在远程连接上进行,从节点可以复制主数据库中的所有数据库或者特定的数据库,或者特定的表。

    f72c63328fe0b3c10263c5a68523ed83.png

    主从复制搭建

    主从复制的搭建我已经写过了,详细可以看这篇文章:

    da2553d86d6ae69565b545736ae83275.jpeg

    快速入门Mycat及主从搭建指南


    MySQL 主从复制原理

    在多个源的复制中,每一个复制源都会打开一个复制通道,这是一个长链接。并且每个复制源都有自己的 IO线程、一个或者多个点 SQL 线程以及 realy log。复制源接收到事务时会将其添加到relay log 中,然后通过SQL thread执行。相关官方文档如下:

    In MySQL multi-source replication, a replica opens multiple replication channels, one for each replication source server. The replication channels represent the path of transactions flowing from a source to the replica. Each replication channel has its own receiver (I/O) thread, one or more applier (SQL) threads, and relay log. When transactions from a source are received by a channel's receiver thread, they are added to the channel's relay log file and passed through to the channel's applier threads. This enables each channel to function independently.

    主从复制应该是分为第一次建立连接增量数据同步过程。

    第一次建立连接

    备库 B 跟主库 A 之间维持了一个长连接。主库 A 内部有一个io_thread线程,专门用于服务备库 B 的这个长连接。一个事务日志同步的完整过程是这样的:

    1.在备库 B 上通过 change master 命令,设置主库 A 的 IP、端口、用户名、密码,以及要从哪个位置开始请求 binlog,这个位置包含文件名和日志偏移量。

    CHANGE MASTER TO MASTER_HOST='192.168.56.104',MASTER_USER='root',MASTER_PASSWORD='qwer_123',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;

    2.在备库 B 上执行 start slave 命令,这时候备库会启动两个线程,就是图中的 io_thread 和 sql_thread。其中 io_thread 负责与主库建立连接。

    3.主库 A 校验完用户名、密码后,开始按照备库 B 传过来的位置,从本地读取 binlog,发给备库 B。

    4.备库 B 拿到 binlog 后,写到relay log(中继日志)中。

    5.备库的 sql_thread 读取 relay log,解析出日志里的命令,并且回放执行。

    增量同步详细流程

    详细过程如下:158c9efb18bb79733764f7da7f06e91c.png

    1.客户端发起 update 请求,MySQL server 端收到请求。

    2.生成被修改数据行对应的 unodo log。

    3.执行update成功写入内存。

    4.InnboDB 生成 redo log ,此时处于 prepare阶段。

    5.server 层生成binlog,事务提交时binlog做持久化,此时binlog便可以开始被同步到从库了。

    6.redo log 做磁盘持久化,同时向客户端返回update的执行新结果(默认异步复制,以后会讲)。

    7.主库发送生成的 binlog 数据。

    8.从库的io_thread处理Maste传输过来的数据,保存为relay log。从库服务器会在一定时间间隔内对master二进制日志进行探测其是否发生改变,如果发生改变,则开始一个I/OThread请求master二进制事件

    9.SQL thread 读取relay log,解析并且在从库中重放执行,数据同步完成。最后I/OThread和SQLThread将进入睡眠状态,等待下一次被唤醒。

    MySQL 如何知道 binlog 是完整的?

    从库在解析的时候如何知道一个事务是完整的?因为一个事务的 binlog 是有完整格式的:statement 格式的 binlog,最后会有 COMMIT 标记;row 格式的 binlog,最后会有一个 XID event。

    如果觉得对你有帮助,欢迎评论分享,感谢阅读!

  • 相关阅读:
    Pytorch CPU版本安装教程
    labelme 使用笔记
    【网页设计】基于LayUI的N站新闻门户页面
    [备忘.Linux]服务部署管理常用命令|systemd
    C语言中的虚拟地址
    vscode提取扩展出错xhr
    为裁员做准备的7个有用步骤(简单)
    生物制剂\化工\化妆品等质检损耗、制造误差处理作业流程图(ODOO15/16)
    Word2010入门
    KMP算法
  • 原文地址:https://blog.csdn.net/sinat_32873711/article/details/128213248