zoukankan      html  css  js  c++  java
  • mysql Replication机制

     

    从上图可以看见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,所以两端的数据是完全一样的。
    注意:要实现主从同步,master必 须打开Binary Log功能,否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。打 开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用 “--log-bin” 参数选项,或者在 my.cnf 配置文件中的 mysqld 参数组([mysqld]标识后的参数部分)增加 “log-bin” 参数项。
     

    主从同步延迟的主要原因是因为主库采用多线程更新,而从库采用单线程更新。看起来解决问题很简单,只要从库也采用多线程更新即可。

    但这样做会带来一个新问题,当从relay_log读到对同一个条记录的多条操作时(比如先后insert和update 了同一个记录),此时如果这两个操作分配给了2个sql 线程并发去更新从库,那就不能保证它们的执行顺序了。

    解决这个问题的方法是,当有多个sql_thread线程来更新从库的时候,必须让每个sql_thread对应一张表,如果从库有10张表,那么就使用10个sql_thread分别更新,这样就解决了并发带引起的乱序的问题;
     

    改进的主从同步方案:

    1、在io_thread接收主库日之后,分成N份relay-log存放;
    2、再用N个sql_thread分别读取日志分发;
    3、确保同一个表的更新语句顺序与主库binlog相同;

     

    事实上,淘宝工程师丁奇已经实现了上述改造方案,并创造了一个叫transfer的工具来完成这个功能,如何获取和使用transfer工具可以自行google之。 

  • 相关阅读:
    (原)Lazarus 异构平台下多层架构思路、DataSet转换核心代码
    (学)新版动态表单研发,阶段成果3
    (学) 如何将 Oracle 序列 重置 清零 How to reset an Oracle sequence
    (学)XtraReport WebService Print 报错
    (原)三星 i6410 刷机 短信 无法 保存 解决 办法
    (原) Devexpress 汉化包 制作工具、测试程序
    linux下网络配置
    apache自带ab.exe小工具使用小结
    Yii::app()用法小结
    PDO使用小结
  • 原文地址:https://www.cnblogs.com/tangchuanyang/p/5992945.html
Copyright © 2011-2022 走看看