同步
master节点接收用户的写请求，并写入到binlog中，Slave上执行sart slave命令开启主从复制开关
slave通过一个IO线程与master建立连接，发送binlog dump指令
master服务器接收到来自slave服务器的IO线程的请求后，其上负责复制的IO线程会根据slave服务器的IO线程请求的信息分批读取指定binlog日志文件指定位置之后的binlog日志信息，然后返回给slave端的IO线程
当slave服务器的IO线程获取到master服务器上的IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写道slave端自身的relay log（中继日志）文件的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时，能告诉master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容
slave通过另一个线程sql thread应用本地的relay log，将数据同步到slave库中
常见问题及处理方案
数据丢失
如果主库突然宕机，然后恰好数据还没同步到从库，那么有些数据可能在从库上是没有的，有些数据可能就丢失了
5.6开启半同步复制（semi-sync复制）
主库写入binlog日志之后，就将强制此时立即将数据同步到从库，从库写入到自己本地的relay log之后，接着会返回一个ack给主库，主库接收到至少一个从库的ack之后才会认为是写操作完成了
可以设置超时间，等待一定的时间后从库未返回结果，降级未异步同步
主从同步延迟问题
原因
大事务，导致同步慢
化大事务为小事务
控制每个事务操作的量，如删除很多数据时，分成多次删除
大表DDL
借助第三方工具机型ddl操作 pt-online-schema-change
建立一张新表，进行表结构修改操作
操作完毕后将原始表中的数据同步到新表，分批操作
同步完成之后修改名字并将原始表删除
网络传输延迟
master节点挂载过多的slave节点
一般不要超过5个
主从服务器配置不一样
从服务器承担过多的读操作
show status 查看主从同步延时
对于一些强一致性的业务场景，要求插入后必须能读取到，强制读请求走主库
考虑是否需要拆表，将大表拆分为小表，提供同步效率
修改代码逻辑，不要插了就查，直接update
sql上加入特殊标识，代理层解析
/*master*/select * from table
开发专门访问主库的查询api
sleep方案
事务问题
事务中的所有sql统一都走主库，由于只涉及一个库，本地事务就可以搞定
