Mysql主从

Centos装置mysql#查看零碎中是否已装置mysql软件yum list installed | grep mysql#删除yum -y remove mysql-libs.x86_64#下载mysql包wget http://cdn.mysql.com//Downloads/MySQL-5.7/mysql-5.7.16-linux-glibc2.5-x86_64.tar.gz#解压tar -zxvf mysql-5.7.16-linux-glibc2.5-x86_64.tar.gz#批改目录名mv mysql-5.7.16-linux-glibc2.5-x86_64 mysql-5.7.16#创立数据保留目录mkdir -p /data/datas/mysql/data #查看mysql用户组cat /etc/group |grep mysql #查看mysql用户 cat /etc/passwd |grep mysql #创立mysql用户组groupadd mysql#创立mysql并增加到mysql用户组useradd mysql -g mysql#给mysql用户没有登录权限usermod -s /sbin/nologin mysql#批改目录的权限为mysql用户chown -R mysql:mysql /data/apps/mysql-5.7.16chown -R mysql:mysql /data/datas/mysql#进入目录cd /data/app/mysql-5.7.16/bin/#初始化装置mysql./mysqld --user=mysql --basedir=/data/app/mysql-5.7.16/ --datadir=/data/datas/mysql/data --initialize#如果报libaio.so错：yum -y install libaio#初始化mysql 胜利之后记住明码 root@localhost: LIFt4H-lrZQ+#批改配置文件cd /data/app/mysql-5.7.16/support-files/vim mysql.serverbasedir=/data/app/mysql-5.7.16datadir=/data/datas/mysql/data#将默认生成的my.cnf备份mv /etc/my.cnf /etc/my.cnf.bak# 启动mysql胜利./mysql.server start # 进行mysql./mysql.server stop配置mysql#创立软链接ln -s /data/app/mysql-5.7.16/bin/mysql /usr/bin/mysql#查看mysql版本mysql --version#复制配置文件cp my-default.cnf /data/app/mysql-5.7.16/my.cnfcd /data/app/mysql-5.7.16/#批改配置文件vim my.cnf [client]default-character-set = utf8mb4[mysql]default-character-set = utf8mb4[mysqld]character-set-client-handshake = FALSEcharacter-set-server = utf8mb4collation-server = utf8mb4_unicode_ciinit_connect='SET NAMES utf8mb4'basedir = /data/app/mysql-5.7.16datadir = /data/datas/mysql/data#设置开机启动cp /data/app/mysql-5.7.16/support-files/mysql.server /etc/init.d/mysqld#可执行权限chmod 755 /etc/init.d/mysqld # 确认MySQL自启动chkconfig --list mysqld　#设置MySQL开启自启动chkconfig mysqld on # 再查看MySQL自启动chkconfig --list mysqld mysqld 0:off 1:off 2:on 3:on 4:on 5:on 6:off　# 如果2--5为on的状态就OKroot明码与近程连贯#启动mysql服务service mysqld start#初始化mysql用户root的明码./bin/mysqladmin -uroot -p'4cSM((-qlNz-' password 'root' #4cSM((-qlNz-为下面初始化mysql生成的随机明码#输出明码进入mysql -uroot -p #mysql近程受权#输出明码进入mysql -uroot -p grant all privileges on *.* to 'root'@'%' identified by 'root';FLUSH PRIVILEGES;#凋谢端口vim /etc/sysconfig/iptables-A INPUT -p tcp -m multiport --dports 3306 -j ACCEPTservice iptables restart主从配置主配置cd /data/app/mysql-5.7.16/#批改配置vim my.cnfport = 3306server_id = 1 #服务id，个别为ip后三位binlog-do-db = beyond #要同步的数据库#binlog-ignore-db = mysql,sys,information_schema,performance_schema #不必同步的数据库,多个以逗号分隔log-bin = mysql-bin #开启log-bin#其余配置优化max_binlog_size = 500Mbinlog_cache_size = 2Mmax_binlog_cache_size = 4Mexpire_logs_days = 30max_connections = 500max_connect_errors = 10000table_open_cache = 256long_query_time = 1slow-query-log#慢sql打印slow_query_log_file = /data/datas/mysql/data/slow_query_log_file.log#重启service mysqld restart #创立一个主从同步的用户mysql -uroot -pcreate user 'repl'@'%' identified by '123456'; #受权grant replication slave on *.* to 'repl'@'%' identified by '123456'; flush privileges;show master status; #查看状态从配置cd /data/app/mysql-5.7.16/#批改配置vim my.cnfport = 3306server_id = 2 #服务id，个别为ip后三位read_only = 1 #只读#其余配置优化log-bin = mysql-binmax_binlog_size = 500Mbinlog_cache_size = 2Mmax_binlog_cache_size = 4Mexpire_logs_days = 30max_connections = 500max_connect_errors = 10000table_open_cache = 256long_query_time = 1slow-query-log#慢sql打印slow_query_log_file = /data/datas/mysql/data/slow_query_log_file.logrelay_log = /data/datas/mysql/data/mysqld-relay-bin relay_log-index = /data/datas/mysql/data/mysqld-relay-bin.index#重启服务service mysqld restart mysql -uroot -p#设置同步change master to master_host='主的ip', master_port=3306, master_user='repl', master_password='123456', master_log_file='mysql-bin.000002', master_log_pos=780; #mysql-bin.000002和780是从主里查的，show master status;命令查看#启动从库复制线程start slave; #查看状态show slave status; #次要查看两个参数：Slave_IO_Running和Slave_Sql_Running。这两个值为Yes，OK从库配置好了#接下来在 beyond数据库的操作都会同步到从数据库

应用Docker Compose搭建MySQL主从复制架构 环境筹备docker 装置MySQL数据库 docker pull mysql运行MySQL容器 docker run --name mysql mysql -e MYSQL_ROOT_PASSWORD=123456应用命令将MySQL配置文件my.cnf 复制出主机上 docker cp mysql:/var/lib/mysql/ D:/docker/mysql_cluster/my.cnf拿到my.cnf原配置文件，加以革新就能够实现数据库主从同步了 配置文件创立文件夹在主机创立mysql_cluster 文件夹 mysql_cluster master/ my.cnf mysql/ slave/ my.cnf mysql/ docker-compose.yml 将从容器内复制进去my.cnf别离放入 master、slave 下 文件配置设置 master my.cnf # 上面配置为主节点设置 #开启二进制日志log_bin=mysql-bin #为以后节点设置一个全局惟一的ID号server_id=95 # 不须要同步数据库binlog-ignore-db = mysqlbinlog_cache_size = 1M# 二级制主动删除的天数，默认为0，表白没有主动删除，启动时和二级制日志循环可能删除工夫expire_logs_days = 7log_bin_trust_function_creators = 1binlog_format=mixed# MySQL 8.x，须要如下配置default_authentication_plugin=mysql_native_passwordcharacter-set-server=utf8mb4collation-server=utf8mb4_unicode_ci配置 slave my.cnf server_id = 102log-bin = mysql-binrelay_log = relicas-mysql-relay-bin log-slave-updates = 1binlog-ignore-db = mysqllog_bin_trust_function_creators = 1binlog_format=mixedread_only = 1# MySQL 8.x，须要如下配置default_authentication_plugin=mysql_native_passwordcharacter-set-server=utf8mb4collation-server=utf8mb4_unicode_cidocker-compose.yml 配置 ...

mysql 主从复制笔记本地测试采纳 docker 模仿部署docker pull mysql:5.7# 启动masterdocker run -itd --name=mysql-master -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql:5.7 # 启动 slavedocker run -itd --name=mysql-slave -p 3308:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql:5.7 这样两台mysql主机曾经部署实现，查看详情master : docker inspect mysql-master进入master主机批改配置docker exec -it mysql-master /bin/bash # 批改位于 /etc/mysql/my.cnf 的配置，退出一下内容。须要装置一下 vi 或者 vim[mysqld]server-id=1 #惟一IDlog-bin=mysql-bin #开启二进制日志性能创立从主机连贯用户mysql -uroot -p123456# 创立用户CREATE USER 'slave'@'%' IDENTIFIED BY '123456';# 受权GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'slave'@'%';# 退出重启容器docker restart mysql-master进入slave主机批改配置# 批改位于 /etc/mysql/my.cnf 的配置，退出一下内容。须要装置一下 vi 或者 vim[mysqld]server-id=2 # 留神这里的id 不能反复，必须惟一log-bin=mysql-slave-bin # 开启二进制日志性能，可作为其余 slave主机的masterrelay_log=edu-mysql-relay-bin# 退出重启容器docker restart mysql-slave连贯 master 主机mysql -uroot -p123456# 执行上面语句 其中 master_host 能够通过下面 docker命令查看 master主机的 IPAddresschange master to master_host='172.17.0.2', master_user='slave', master_password='123456', master_port=3306, master_log_file='mysql-bin.000001', master_log_pos=0;#启动start slave;# 而后输出命令查看详情show slave status \G;# 如果这两个我的项目是 Yes 阐明万事okSlave_IO_Running: YesSlave_SQL_Running: Yes往 master 写入数据，通过 slave 查问数据。的确是否同步。奉上一份php测试伪代码$master = new PDO('mysql:host=localhost:3307;dbname=test', 'root', '123456');$master->exec("INSERT test (name) VALUES ('master')");$slave = new PDO('mysql:host=localhost:3308;dbname=test', 'root', '123456');$data = $slave->exec("select * from test");var_dump($data);其余命令参考# 查看状态show slave status \G;show master status \G;# 进行启动IO线程STOP SLAVE IO_THREAD;START SLAVE IO_THREAD;以上内容仅供学习参考，实在场景下请参考mysql官网文档！下一篇文章主从复制中常见谬误，以及解决形式！

主从数据库特点主从模式（一主多从，多主一从，级联复制）读写拆散主从复制主从复制模式异步模式主数据库增删改数据过程中，不会被动告诉 Dump 线程去同步从库半同步模式主数据库增删改数据过程中，会被动告诉 Dump 线程去同步从库，并收到一台从库的返回信息后，才会 commit全同步模式主数据库增删改数据过程中，会被动告诉 Dump 线程，并期待所有从库返回信息后才 commitbin log 记录格局（实现粒度）SBR（sql base replication）mysql5 之前版本，bin log 只记录会批改数据的 sql 语句，很大水平上缩小日志文件的大小，节约 IO 读写和升高网络传输工夫，进步性能。但从库同步时须要从新执行 sql；一些状况下，还会导致主从库数据不统一。比方一个SQL语句调用了用户定义的函数，调用了返回随机值的函数，在数据表中应用了自增列，以及应用了上下文数据（context data, 比方用一个表的行数作为某个插入字段值，或者在update/delete语句中应用了limit子句）RBR（row base replication）bin log 只记录批改的行，批改成什么。从库同步间接调用存储引擎的接口进行增删改，不须要残缺地进行 sql 语句的执行。但毛病在于日志文件会比拟大， 并且批改数据量大时，同步须要的工夫比拟长MBR（mixed base replication）mysql 会依据执行的 sql 语句来决定采纳以上两种的哪种形式来保留日志长处读写拆散，进步查问效率程度扩大数据库的负载，容错，保障高可用实时容灾，可故障切换数据备份

1 Docker 搭建 mysql 主从下载 docker 镜像 docker pull mysql 2 创立网络驱动docker network create {网络名称} 创立专门用于容器之间通信的网络 作用: 创立 docker 容器的时候 通过 --network {网络名称} 能够不便在外部应用容器名称进行通信docker network create cusnet 3 主服务器搭建3.1 启动主服务器docker run -dit  --network cusnet --name mysql_master -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql3.2 批改主服务器的配置进入容器中docker exec -it mysql_master /bin/bash批改配置文件cd /etc/mysqlecho "[mysqld]" > my.cnfecho "pid-file = /var/run/mysqld/mysqld.pid" >> my.cnfecho "socket = /var/run/mysqld/mysqld.sock" >> my.cnfecho "datadir = /var/lib/mysql" >> my.cnfecho "secure-file-priv= NULL" >> my.cnfecho "secure-file-priv= NULL" >> my.cnfecho "log-bin=/var/run/mysqld/mysql-bin" >> my.cnf # [必须]启用二进制日志echo "server-id=1" >> my.cnf # [必须]服务器惟一IDset +Hecho "!includedir /etc/mysql/conf.d/" >> my.cnf创立用于复制的账号$ mysql -uroot -p123456mysql> CREATE USER 'slave'@'%' IDENTIFIED BY '123456';mysql> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON . TO 'slave'@'%';敞开容器重启 docker container stop mysql_master && docker container start mysql_master4 从服务器搭建4.1 启动从服务器docker run -dit  --network cusnet --name mysql_slave -p 3307:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql4.2 批改从服务器的配置进入容器中docker exec -it mysql_slave /bin/bash批改配置文件cd /etc/mysqlecho "[mysqld]" > my.cnfecho "pid-file = /var/run/mysqld/mysqld.pid" >> my.cnfecho "socket = /var/run/mysqld/mysqld.sock" >> my.cnfecho "datadir = /var/lib/mysql" >> my.cnfecho "secure-file-priv= NULL" >> my.cnfecho "secure-file-priv= NULL" >> my.cnfecho "log-bin=/var/run/mysqld/mysql-bin" >> my.cnf # [必须]启用二进制日志echo "relay_log=/var/run/mysqld/mysql-relay-bin" >> my.cnfecho "server-id=2" >> my.cnf # [必须]服务器惟一IDset +Hecho "!includedir /etc/mysql/conf.d/" >> my.cnf敞开容器重启 docker container stop mysql_slave && docker container start mysql_slave连贯到 master$ mysql -uroot -p123456mysql> show master status G; ;; 这句话是查看 master 日志文件和以后的地位mysql> CHANGE MASTER TO GET_MASTER_PUBLIC_KEY=1;mysql> change master to MASTER_HOST='mysql_master',MASTER_USER='slave',MASTER_PASSWORD='123456',MASTER_LOG_FILE="mysql-bin.000001",MASTER_LOG_POS=156;mysql> start slave; ;; 启动复制mysql> show slave status G; ;; 查看复制的状态如果报 (1872, 'Slave failed to initialize relay log info structure from the repository')执行 reset slave;

二进制日志(bin-log)的阐明——主从的前提bin-log的相干字段和文件阐明查看日志日否开启等信息状况 log_bin：是否开启log_bin_basename：二进制日志文件名字(理论状况下会在前面加上.索引来命名文件)log_bin_index：记录日志文件的索引文件查看准作为主从中的主库的信息。 File：以后应用的二进制日志的文件和索引Possition：以后日志运行到那个点了对应的二进制日志文件和索引文件的关系。留神：每次mysql重启都会从新开启一个mysql-bin.*日志文件。长期不重启mysql-bin文件会过大。还是请dba来解决文件过大问题吧/(ㄒoㄒ)/~~。 如何查看文件内容办法1：mysqlbinlog命令查看mysqlbinlog 命令，以用户可视的形式展现出二进制日志中的内容。同时，也能够将其中的内容读取进去，供其余MySQL实用程序应用。 为了不便，咱们将mysql其余相干命令退出到系统命令行中。不须要或曾经懂的间接跳过。 查看日志[root@MiWiFi-R3P-srv data]# mysqlbinlog ./mysql-bin.000006 办法2：show binlog events命令查看show binlog events 命令查看某个binlog日志内容。 命令： mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count];选项解析： IN 'log_name' 指定要查问的binlog文件名(不指定就是第一个binlog文件) FROM pos 指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算) LIMIT [offset,] 偏移量(不指定就是0) row_count 查问总条数(不指定就是所有行)实例： A.查问第一个(最早)的binlog日志： mysql> show binlog events\G; B.指定查问 mysql-bin.000021 这个文件： mysql> show binlog events in 'mysql-bin.000021'\G;C.指定查问 mysql-bin.000021 这个文件，从pos点:8224开始查起： mysql> show binlog events in 'mysql-bin.000021' from 8224\G;D.指定查问 mysql-bin.000021 这个文件，从pos点:8224开始查起，查问10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 10\G;E.指定查问 mysql-bin.000021 这个文件，从pos点:8224开始查起，偏移2行，查问10条 mysql> show binlog events in 'mysql-bin.000021' from 8224 limit 2,10\G;实操截图 ...

MySQL的主从同步是一个很成熟的架构，优点为：①在从服务器可以执行查询工作(即我们常说的读功能)，降低主服务器压力;②在从主服务器进行备份，避免备份期间影响主服务器服务;③当主服务器出现问题时，可以切换到从服务器。 相信大家对于这些好处已经非常了解了，在项目的部署中也采用这种方案。但是MySQL的主从同步一直有从库延迟的问题，那么为什么会有这种问题。这种问题如何解决呢？ MySQL数据库主从同步延迟原理。MySQL数据库主从同步延迟是怎么产生的。MySQL数据库主从同步延迟解决方案。1. MySQL数据库主从同步延迟原理。 答：谈到MySQL数据库主从同步延迟原理，得从mysql的数据库主从复制原理说起，mysql的主从复制都是单线程的操作，主库对所有DDL和 DML产生binlog，binlog是顺序写，所以效率很高，slave的Slave_IO_Running线程到主库取日志，效率很比较高，下一步， 问题来了，slave的Slave_SQL_Running线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的，不是顺 序的，成本高很多，还可能可slave上的其他查询产生lock争用，由于Slave_SQL_Running也是单线程的，所以一个DDL卡主了，需要 执行10分钟，那么所有之后的DDL会等待这个DDL执行完才会继续执行，这就导致了延时。有朋友会问：“主库上那个相同的DDL也需要执行10分，为什 么slave会延时？”，答案是master可以并发，Slave_SQL_Running线程却不可以。 2. MySQL数据库主从同步延迟是怎么产生的。 答：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。 3. MySQL数据库主从同步延迟解决方案 答：最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如 sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也 可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。 mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。 基于局域网的master/slave机制在通常情况下已经可以满足'实时'备份的要求了。如果延迟比较大，就先确认以下几个因素： 网络延迟master负载slave负载一般的做法是，使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器，只作为备份用，不进行其他任何操作，就能相对最大限度地达到'实时'的要求了 slave_net_timeout单位为秒 默认设置为 3600秒 参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据 master-connect-retry单位为秒 默认设置为 60秒 参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试。 通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟 判断主从延时，通常有两个方法： Seconds_Behind_Master vs 2. mk-heartbeat，下面具体说下两者在实现功能的差别。可以通过监控show slave statusG命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。其值有这么几种：NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.0 - 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。正值 - 表示主从已经出现延时，数字越大表示从库落后主库越多。负值 - 几乎很少见，只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。 Seconds_Behind_Master是通过比较sql_thread执行的event的timestamp和io_thread复制好的 event的timestamp(简写为ts)进行比较，而得到的这么一个差值。我们都知道的relay-log和主库的bin-log里面的内容完全一 样，在记录sql语句的同时会被记录上当时的ts，所以比较参考的值来自于binlog，其实主从没有必要与NTP进行同步，也就是说无需保证主从时钟的 一致。你也会发现，其实比较真正是发生在io_thread与sql_thread之间，而io_thread才真正与主库有关联，于是，问题就出来了， 当主库I/O负载很大或是网络阻塞，io_thread不能及时复制binlog（没有中断，也在复制），而sql_thread一直都能跟上 io_thread的脚本，这时Seconds_Behind_Master的值是0，也就是我们认为的无延时，但是，实际上不是，你懂得。这也就是为什 么大家要批判用这个参数来监控数据库是否发生延时不准的原因，但是这个值并不是总是不准，如果当io_thread与master网络很好的情况下，那么 该值也是很有价值的。（就好比：妈–儿子–媳妇的关系，妈与儿子亲人，媳妇和儿子也亲人，不见得媳妇与妈就很亲。开个玩笑:-）之前，提到 Seconds_Behind_Master这个参数会有负值出现，我们已经知道该值是io_thread的最近跟新的ts与sql_thread执行到 的ts差值，前者始终是大于后者的，唯一的肯能就是某个event的ts发生了错误，比之前的小了，那么当这种情况发生时，负值出现就成为可能。 方法2. mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。 mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳 now()，该结构也会被复制到从库上，表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示 延时的秒数越多。我们都知道复制是异步的ts不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复 制，巧妙的借用timestamp来检查延时，赞一个！ ...

引言 MySQL 主从复制原理是相当基础的知识，很久没有接触过 MySQL 主从复制了，因为我这边负责的业务暂时没用使用 MySQL 主从复制。既然有些忘记了，现在我重新复习记录下。 MySQL 主从复制介绍 MySQL 的主从复制是一个异步的复制过程（但一般情况下感觉是实时同步的），数据库数据从一个 MySQL 数据库（我们称之为 Master）复制到另一个 MySQL 数据库（我们称之为 Slave）。在 Master 与 Slave 之间实现整个主从复制的过程是由三个线程参与完成的。其中有两个线程（SQL 线程和 IO 线程）在 Slave 端，另外一个线程（IO 线程）在 Master 端。（来自 MySQL 帮助文档） 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 端的数据是完全一样的。 ...