主从集群
在实际的生产环境中，由单台Mysql作为独立的数据库是完全不能满足实际需求的，无论是在安全性，高可用性以及高并发等各个方面。因此，一般来说都是通过 主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力进行部署与实施。
MySQL 主从集群带来的作用是：
提高数据库负载能力，主库执行读写任务（增删改），备库仅做查询。
提高系统读写性能、可扩展性和高可用性。
数据备份与容灾，备库在异地，主库不存在了，备库可以立即接管，无须恢复时间。
主从原理
主从的具体实现离不开binlog，可以查看了解mysql三大日志。
主从复制
mysql主从复制需要三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread）
binlog dump线程：
主库中有数据更新时，根据设置的binlog格式，将更新的事件类型写入到主库的binlog文件中，并创建log dump线程通知slave有数据更新。当I/O线程请求日志内容时，将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
I/O线程：该线程会连接到master，向log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中。
SQL线程：该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。
下图描述了复制的过程：
过程解析
主库写入数据并且生成binlog文件。该过程中MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。
在事件写入二进制日志完成后，master通知存储引擎提交事务。
从库服务器上的IO线程连接Master服务器，请求从执行binlog日志文件中的指定位置开始读取binlog至从库。
主库接收到从库的IO线程请求后，其上复制的IO线程会根据Slave的请求信息分批读取binlog文件然后返回给从库的IO线程。
Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容。
从库服务器的SQL线程会实时监测到本地Relay Log中新增了日志内容，然后把RelayLog中的日志翻译成SQL并且按照顺序执行SQL来更新从库的数据。
从库在relay-log.info中记录当前应用中继日志的文件名和位置点以便下一次数据复制。
异步、同步和半同步复制
异步复制(Asynchronous replication)
逻辑上
MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。
技术上
主库将事务 Binlog 事件写入到 Binlog 文件中，此时主库只会通知一下 Dump 线程发送这些新的 Binlog，然后主库就会继续处理提交操作，而此时不会保证这些 Binlog 传到任何一个从库节点上。
全同步复制(Fully synchronous replication)
逻辑上
指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。
技术上
当主库提交事务之后，所有的从库节点必须收到、APPLY并且提交这些事务，然后主库线程才能继续做后续操作。但缺点是，主库完成一个事务的时间会被拉长，性能降低。
半同步复制(Semisynchronous replication)
逻辑上
是介于全同步复制与全异步复制之间的一种，主库只需要等待至少一个从库节点收到并且 Flush Binlog 到 Relay Log 文件即可，主库不需要等待所有从库给主库反馈。同时，这里只是一个收到的反馈，而不是已经完全完成并且提交的反馈，如此，节省了很多时间。
技术上
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
为什么会主从延迟
主从延迟是怎么回事？
根据前面主从复制的原理可以看出，两者之间是存在一定时间的数据不一致，也就是所谓的主从延迟。我们来看下导致主从延迟的时间点：
主库 A 执行完成一个事务，写入 binlog，该时刻记为T1.
传给从库B，从库接受完这个binlog的时刻记为T2.
从库B执行完这个事务，该时刻记为T3.
那么所谓主从延迟，就是同一个事务，从库执行完成的时间和主库执行完成的时间之间的差值，即T3-T1。
我们也可以通过在从库执行show slave status，返回结果会显示seconds_behind_master，表示当前从库延迟了多少秒。
seconds_behind_master如何计算？
每一个事务的binlog都有一个时间字段，用于记录主库上写入的时间
从库取出当前正在执行的事务的时间字段，跟当前系统的时间进行相减，得到的就是seconds_behind_master，也就是前面所描述的T3-T1。
最直接的影响就是从库消费中转日志（relaylog）的时间段也就是T2～T3，而造成原因一般是以下几种：
1、从库的机器性能比主库要差
比如将20台主库放在4台机器，把从库放在一台机器。这个时候进行更新操作，由于更新时会触发大量读操作，导致从库机器上的多个从库争夺资源，导致主从延迟。
不过，目前大部分部署都是采取主从使用相同规格的机器部署。
2、从库的压力大
按照正常的策略，读写分离，主库提供写能力，从库提供读能力。出于对于主库的敬畏之心，将进行大量查询放在从库上，结果导致从库上耗费了大量的CPU资源，进而影响了同步速度，造成主从延迟。
对于这种情况，可以通过一主多从，分担读压力；也可以采取binlog输出到外部系统，比如Hadoop，让外部系统提供查询能力。
3、大事务的执行
一旦执行大事务，那么主库必须要等到事务完成之后才会写入binlog。
如：主库执行了一条insert … select非常大的插入操作，该操作产生了近几百G的binlog文件传输到只读节点，进而导致了只读节点出现应用binlog延迟。
因此，DBA经常会提醒开发，不要一次性地试用delete语句删除大量数据，尽可能控制数量，分批进行。
4、主库的DDL(alter、drop、repair、create)
1、只读节点与主库的DDL同步是串行进行，如果DDL操作在主库执行时间很长，那么从库也会消耗同样的时间，比如在主库对一张500W的表添加一个字段耗费了10分钟，那么只读节点上也会耗费10分钟。
2、只读节点上有一个执行时间非常长的的查询正在执行，那么这个查询会堵塞来自主库的DDL，读节点表被锁，直到查询结束为止，进而导致了只读节点的数据延迟。
5、锁冲突
锁冲突问题也可能导致从机的SQL线程执行慢，比如从机上有一些select … for update的SQL，或者使用了MyISAM引擎等。
6、从库的复制能力
一般场景中，因偶然情况导致从库延迟了几分钟，都会在从库恢复之后追上主库。但若是从库执行速度低于主库，且主库持续具有压力，就会导致长时间主从延迟，很有可能就是从库复制能力的问题。
回头再看下主从复制的流程，主要看下红色的箭头：
1、上面两个箭头分别表示的是客户端写入主库和sql_thread执行relaylog，若粗细表示并发度，可见主库明显高于从库。
2、从库上的执行，即sql_thread更新逻辑，在5.6版本之前，是只支持单线程，那么在主库并发高、TPS高时，就会出现较大的主从延迟。
如何尽量降低主从延迟
主从同步问题永远都是一致性和性能的权衡，得看实际的应用场景，若想要减少主从延迟的时间，可以采取下面的办法：
- 降低多线程大事务并发的概率，优化业务逻辑
- 优化SQL，避免慢SQL，减少批量操作，建议写脚本以update-sleep这样的形式完成。
- 提高从库机器的配置，减少主库写binlog和从库读binlog的效率差。
- 尽量采用短的链路，也就是主库和从库服务器的距离尽量要短，提升端口带宽，减少binlog传输的网络延时。
- 实时性要求的业务读强制走主库，从库只做灾备，备份。
