前言
主从同步使得数据可以从一个数据库服务器复制到其他服务器上，在复制数据时，一个服务器充当主服务器（master），其余的服务器充当从服务器（slave）。
主从同步好处
- 通过增加从服务器来提高数据库的性能，在主服务器上执行写入和更新，在从服务器上向外提供读功能，可以动态地调整从服务器的数量，从而调整整个数据库的性能。
- 提高数据安全-因为数据已复制到从服务器，从服务器可以终止复制进程，所以，可以在从服务器上备份而不破坏主服务器相应数据
- 在主服务器上生成实时数据，而在从服务器上分析这些数据，从而提高主服务器的性能
主从同步实现方式
主从同步是基于Bin Log日志来实现的。 BinLog日志参数配置
| 参数 | 含义 | 优点 | 缺点 |
|---|---|---|---|
| Statement | 语句级，binlog 会记录每次一执行写操作的语句。相对 row 模式节省空间，但是可能产生不一致性，比如“update tt set create_date=now()”，如果用 binlog 日志 进行恢复，由于执行时间不同可能产生的数据就不同 | 节省空间 | 有可能造成数据不一致 |
| row | 行级， binlog 会记录每次操作后每行记录的变化。 | 保持数据的绝对一致性。因为不管 sql 是什么，引用了什么函数，他只记录 执行后的效果 | 占用较大空间 |
| mixed | statement 的升级版，一定程度上解决了，因为一些情况而造成的 statement 模式不一致问题，默认还是 statement，在某些情况下譬如：当函数中包含 UUID() 时；包含 AUTO_INCREMENT 字段的表被更新时；执行 INSERT DELAYED 语句时；用 UDF 时；会按照 ROW 的方式进行处理 | 节省空间，同时兼顾了一定的一致性 | 还有些极个别情况依旧会造成不一致，另外 statement 和 mixed 对于需要对 binlog 的监控的情况都不方便 |
一主多从
一般是主库负责所有读写请求，而从库只负责容灾恢复和冗余备份。
如果做了读写分离的话，主库负责写请求，从库负责读请求，可以提升数据库性能。
双主多从
一般是主库1负责所有读写请求，主库2不对外提供服务，只用来容灾恢复。
相比一主多从架构，双主多从架构可以减少宕机时间，更快恢复数据库可用状态。
主从同步原理
- 主库数据发送变更的时写入Bin Log日志
- 从库IO发起dump主库请求
- 主库发送Bin Log到从库
- 从库IO线程写入Bin Log内容到Relay Log
- 从库SQL线程读取Relay Log内容
- 从库SQL线程重新执行一遍SQL语句
如何提升主从同步性能
1. 从库开启多线程复制
在最后两步SQL线程读取Relay Log 和重放时可以修改参数slave_parallel_workers=x来指定线程个数
2. 修改同步模式，改为异步
主从同步共有三种复制方式：
-
全同步复制
当主库执行完一个事务，并且所有从库都执行完该事务后，才给客户端返回成功。
-
半同步复制
至少有一个从库执行完成后，就给客户端返回成功。
-
异步复制
主库执行完后，立即返回成功，不关心从库是否执行完成。
如果对数据安全性要求没那么高，可以把同步模式改成半同步复制或者异步复制。
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。
