一、什么是mysql主从同步？
MySQL主从同步，可以实现将一台数据库服务器同步到多台数据库服务器。MYSQL自带主从同步功能，经过配置，可以实现基于库，表结构的多种方案同步
可以对MySQL做主从架构并且进行读写分离。让主服务器处理写请求，从服务器处理读请求，这样可以进一步提升数据库并发处理
当master(主)库的数据发生变化的时候，变化会实时的同步到slave(从)库。
二、主从同步有什么好处？
1.读写分离，提升数据库性能
2.容灾恢复，主服务器不可用时，从服务器提供服务，提高可用性
3.冗余备份，主服务器数据损坏丢失，从服务器保留备份
三、主从同步实现方式
MySQL主从同步是基于Bin Log实现的，而Bin Log记录的是原始SQL语句。 Bin Log共有三种日志格式，可以binlog_format配置参数指定
常见的主从同步架构有一主多从、双主多从。
一主多从架构：
一般是主库负责所有读写请求，而从库只负责容灾恢复和冗余备份。
如果做了读写分离的话，主库负责写请求，从库负责读请求，可以提升数据库性能。
双主多从架构：
一般是主库1负责所有读写请求，主库2不对外提供服务，只用来容灾恢复。
相比一主多从架构，双主多从架构可以减少宕机时间，更快恢复数据库可用状态。
四、主从同步的原理是什么？
1.当主库数据发生变更时，写入本地Bin Log文件
2.从库IO线程发起dump主库Bin Log文件的请求
3.主库IO线程推送Bin Log文件到从库中
4.从库IO线程把Bin Log内容写入本地的Relay Log文件中
5.从库SQL线程读取Relay Log文件内容
6.从库SQL线程重新执行一遍SQL语句
首先我们来了解master-slave的体系结构。 如下图：
不管是delete、update、insert，还是创建函数、存储过程，所有的操作都在master上。当master有操作的时候,slave会快速的接收到这些操作，从而做同步。 但是，这个机制是怎么实现的呢？
在master机器上，主从同步事件会被写到特殊的log文件中(binary-log);在slave机器上，slave读取主从同步事件，并根据读取的事件变化，在slave库上做相应的更改。
4.1主从同步事件有哪些
上面说到：
在master机器上，主从同步事件会被写到特殊的log文件中(binary-log);
主从同步事件有3种形式:statement、row、mixed。
1.statement：会将对数据库操作的sql语句写入到binlog中。
2.row：会将每一条数据的变化写入到binlog中。
3.mixed：statement与row的混合。Mysql决定什么时候写statement格式的，什么时候写row格式的binlog。
4.2在master机器上的操作
当master上的数据发生改变的时候，该事件(insert、update、delete)变化会按照顺序写入到binlog中。
binlog dump线程
当slave连接到master的时候，master机器会为slave开启binlog dump线程。当master 的 binlog发生变化的时候，binlog dump线程会通知slave，并将相应的binlog内容发送给slave。
4.3在slave机器上的操作
当主从同步开启的时候，slave上会创建2个线程。
-
I/O线程。该线程连接到master机器，master机器上的binlog dump线程会将binlog的内容发送给该I/O线程。该I/O线程接收到binlog内容后，再将内容写入到本地的relay log。
-
SQL线程。该线程读取I/O线程写入的relay log。并且根据relay log的内容对slave数据库做相应的操作。
4.4如何在master、slave上查看上述的线程？
使用SHOW PROCESSLIST命令可以查看。
如图，在master机器上查看binlog dump线程。
如图，在slave机器上查看I/O、SQL线程。
五、主从同步延迟问题
主从同步最常遇到的问题就是主从同步延迟，可以通过在从库上执行show slave status命令查看延迟时间，Seconds_Behind_Master表示延迟的秒数。
5.1 主从同步延迟的原因有哪些？
1.从库机器性能较差
主库负责所有读写请求，从库只用来备份，会用性能较差的机器，执行时间自然较慢。
2.从库压力更大
读写分离后，主库负责写请求，从库负责读请求。
互联网应用一般读请求更多，所以从库读压力更大，占用更多CPU资源。
3.网络延迟
当主库的Bin Log文件往从库上发送时，可能产生网络延迟，也会导致从库数据跟不上。
4.主库有大事务
当主库上有个大事务需要执行5分钟，把Bin Log文件发送到从库，从库至少也需要执行5分钟，所以这时候从库就出现了5分钟的延迟。
5.2 主从同步延迟的解决方案？
1.从库机器性能较差
把从库换成跟主库同等规格的机器。
2.从库压力更大
多搞几台从库，分担读请求压力。
3.网络延迟
联系运维或者云服务提供商解决。
4.主库有大事务
把大事务分割成小事务执行，大事务不但会产生从库延迟，还可能产生死锁，降低数据库并发性能，所以尽量少用大事务。
5.3 如何提升主从同步性能
1、从库开启多线程复制
就是在主从同步的最后两步使用多线程，修改配置 slave_parallel_workers=4，代表开启4个复制线程。
2、修改同步模式，改为异步
主从同步共有三种复制方式：
1.全同步复制
当主库执行完一个事务，并且所有从库都执行完该事务后，才给客户端返回成功。
2.半同步复制
至少有一个从库执行完成后，就给客户端返回成功。
3.异步复制
主库执行完后，立即返回成功，不关心从库是否执行完成。
如果对数据安全性要求没那么高，可以把同步模式改成半同步复制或者异步复制。
3、修改从库Bin Log配置
修改sync_binlog配置： sync_binlog=0 ，表示写binlog不立即刷新磁盘，由系统决定什么时候刷新磁盘。sync_binlog=1，每次写binlog都刷新磁盘，安全性高，性能差。
sync_binlog=N，写N次binlog才刷新磁盘。
从库对数据安全性要求没那么高，可以设置sync_binlog=0。
修改innodb_flush_log_at_trx_commit配置：
innodb_flush_log_at_trx_commit=0，每隔一秒钟，把事务日志刷新到磁盘。innodb_flush_log_at_trx_commit=1，每次事务都刷新到磁盘。
innodb_flush_log_at_trx_commit=2，每次事务都不主动刷新磁盘，由系统决定什么时候刷新磁盘。
从库对数据安全性要求没那么高，可以设置innodb_flush_log_at_trx_commit=2。
