前言：前面几篇文章讲解了在应用层读写分离的配置和使用，这篇文章将来个主从复制的实战解析。
说明：主从复制，读写分离结构图
原理图
主库生成一个线程: Binlog Dump线程
1、此线程运行在主库，当主从都配置好后，从库运行START SLAVE启动复制后，会在主库上生成一个BinlogDump线程，该线程的主要作用就是读取主库Binlog事件，然后发送到从库（从库的I/O线程）。
从库生成两个线程：一个I/O线程，一个SQL线程；
1、i/o线程去请求主库 的binlog，并将得到的binlog日志写到relay log（中继日志） 文件中；
2、主库会生成一个 log dump 线程，用来给从库 i/o线程传binlog；
3、SQL 线程，会读取relay log文件中的日志，并解析成具体操作，来实现主从的操作一致，而最终数据一致；
详细流程如下：
1、主库验证从库发起的连接；
2、主库为从库开启一个线程；
3、从库将主库日志的偏移位告诉主库；
4、主库检查该值是否小于当前二进制日志偏移位。
5、如果小于，则通知从库可以取数据。
6、从库持续从主库取数据，直至取完，这时，从库线程进入睡眠，主库线程同时进入睡眠。
7、当主库有更新时，主库线程被激活，并将二进制日志推送给从库，并通知从库线程进入工作状态。
8、从库SQL线程执行二进制日志，随后进入睡眠状态。
存在问题：
1、主库宕机后，数据可能丢失
解决：先配置主主同步，再用keepalived实现双机热备自动切换，具体请百度双机热备
2、从库只有一个sql Thread，主库写压力大，复制很可能延时
说明：当主库的TPS并发较高时，产生的DDL数量超过slave一个sql线程所能承受的范围，那么延时就产生了，当然还有就是可能与slave的大型query语句产生了锁等待。
解决：
1、用多台slave来分摊请求
2、关闭slave的一些日志功能，如sync_binlog，innodb_flushlog，innodb_flush_log_at_trx_commit
3、更好的硬件
一、环境介绍
主：Linux(centos 7) MySQL(5.6.4) IP:192.168.8.228
从：Linux(centos 7) MySQL(5.6.4) IP:192.168.8.146
二、配置主库环境
1、修改mysql配置文件 my.cnf，加入如下红框内容
2、添加从库权限账号
注释：在主服务器上为从服务器分配一个账号，就像一把钥匙，从服务器拿着这个钥匙，才能到主服务器上来共享主服务器的日志文件。
提醒：记得 FLUSH PRIVILEGES 刷新权限
3、查看主服务器当前二进制日志名和偏移量
解释：这个操作的目的是为了在从数据库启动后，从这个点开始进行数据的恢复
出现以上结果，说明主库设置完毕了
三、配置从库环境
1、修改从库mysql配置文件 my.cnf，加入如下红框内容
2、配置连接主库参数
说明：不支持在配置文件中加这些参数，mysql5.5+版本主从复制不支持这些变量，需要在从库上用命令来设置
3、启动slave进程
从库基本命令：
启动：slave start
停止：slave stop
4、查看slave的状态，如果下面两项值为YES，则表示配置正确：
1）、Slave_IO_Running: Yes
2）、Slave_SQL_Running: Yes
到此，从库配置完成，只等主库更新数据了
注意：上一步可能会遇到的问题(一定要记得先停止从库改完后再启动从库)
错误：当执行show slave statusG 时，发现slave_IO_Running：no时，并且下面的error_log还报错了，类似这种 Slave can not handle replication events with时
原因：是你的master和slave的mysql版本不一样，mysql5.6的binlog_checksum默认设置的是crc32。 而MySQL5.5 或者更早的版本默认值是None，所以可以将两个服务器的校验都设为none，或者crc32。
四、开始实验
1、主库表test1和从库表test1里面都没有数据
2、在主库中添加一条数据，再查看从库表是否有这条数据
以上就是本篇文章的全部内容了，关于主从复制--读写分离就到这里了。