mysql主从复制概述

1、mysql主从复制概述

1.1 mysql主从复制的优点：

1、提升读写性能：比如某一个sql的执行会锁住整张表，此时如果由从库可以提供读的功能，那么可以实现读写分离，主库写，从库读，提升性能。
2、提高可用性：比如备份数据，可以对从库来备份数据，避免主库备份影响到主库的写入。又比如主库故障了，可以切换到从库。

1.2 主从复制步骤如下：

1、主库配置server-id, bin-log文件名，创建拥有复制权限的账号并授权给从库；
2、从库配置server-id, bin-log文件名，relay-log。从库执行change master命令，指向主库的ip, 端口， 日志文件，日志文件position。执行start slave命令开启从库同步（箭头2），然后会同步主库中position之后数据。
3、如果slave发送的指定bin-log日志position点之后没有新内容，主库不会进行任何操作。当有数据更新时
（箭头1），主库会通过master IO线程将更新的数据，以及最新的bin-log文件名和position位置，发送给从库（箭头3）。
4、从库接收到数据后，通过Slave IO线程将接收到的日志内容依次添加到Slave端的relay-log文件的最末端（箭头4），并将读取到的Master端的 bin-log的文件名和position点记录到master.info文件中，以便在下一次读取的时候能告知master从响应的bin-log文件名及最后一个position点开始发起请求。
5、Slave Sql线程检测到relay-log中内容有更新，会立刻解析relay-log的内容在Master真实执行时候的那些可执行的SQL语句，将解析的SQL语句并在Slave里执行（箭头5），执行成功后，Master库与Slave库保持数据一致。

备注1：
主要会用到3个线程：主库的IO线程、从库的IO线程和执行sql线程。
主要会用到2个文件：主库的bin-log日志文件，从库的relay-log中继日志文件。
备注2：
主库与从库之间维持了一个长链接，主库内部有一个线程，专门服务于从库的这个长链接的。
备注3：
binlog 日志有三种格式，分别是statement（sql语句），row（真实数据）和mixed。
MySQL的大叔想了一个折中的方案，mixed格式的binlog。所谓的mixed格式其实就是row和statement格式混合使用，当MySQL判断可能数据不一致时，就用row格式，否则使用就用statement格式。

1.3 问题1：主库中position位置之前的数据，怎么同步给从库呢？

1、主从同步，只是针对主库中position位置之后的数据进行同步的。如果要对存量数据进行同步，就需要先对主库加锁，再使用linux的mysqldump命令，先对主库中的数据库进行备份。然后使用linux 的mysql命令将备份数据传到从库的机器上，然后在从库上再全量写入到从库中。

由于主库白天一般来说都有在写入，因此这种存量数据的复制，一般考虑凌晨进行同步，这样master的file和position的变化少一点，对用户的影响也少一点。

1.4 问题2：主从不同步，有哪些方式进行避免？

1、避免从库压力大：可以多加几台从库。避免从库访问量过大而消耗大量CPU，导致没有资源去及时同步主库数据。当然从库也不宜过多，一般3-5台就可以了。
2、避免操作大事务：大事务意味着从库要执行的时间也很长，从而导致主从复制时间长，会导致主从不同步。比如一个事务执行就要10分钟，那么主库执行完后，给到从库执行，最后这个事务可能就会导致从库延迟10分钟。
3、主从配置不一致：使用同等高版本的mysql。高版本的mysql可以多线程复制。
4、从库复制响应慢：可以通过配置参数来提升从库性能，直接禁用slave端的binlog，sync_binlog在slave端设置为0。

参考文章：
1、MySQL主从复制详解及实战
2、MySQL的主从
3、mysql主从
4、mysql主从不一致，重新同步从库