在运维数据库时,我们需要处理三个问题,1:数据可靠性,2:数据库可用性,3:高并发,
必不可少的,我们都会直接或者间接的运用数据库的主从复制
那么如何配置 MySQL 的主从同步？
要配置主从同步,首先要了解下mysql的主从同步机制:
当客户端提交一个事务到 MySQL 的集群，直到客户端收到集群返回成功响应，在这个过程中，MySQL 集群需要执行很多操作：主库需要提交事务、更新存储引擎中的数据、把 Binlog 写到磁盘上、给客户端返回响应、把 Binlog 复制到所有从库上、每个从库需要把复制过来的 Binlog 写到暂存日志中、回放这个 Binlog、更新存储引擎中的数据、给主库返回复制成功的响应。
主从同步的默认时序(异步):
主从同步的方式:
mysql提供了三种主从同步的方式:1.同步复制,2.异步复制,3.半异步复制
同步复制: 开启一个事务操作后,在提交事务时,主库需要等待从库执行完复制操作后,才会给客户端返回响应,这样的好处是可以保证主库和从库的数据完全一致,但是生产中基本不可用
一是因为主库需要等待所有从库执行完成后才会返回响应,性能太差
二是如果主库或者从库有问题,整个数据库系统都会发生问题,可用性太低
异步复制: 与同步相反,开启一个事务操作后,在提交事务时,会异步的启动主库不需要等待从库执行完复制操作,直接给客户端返回响应,从库会有一个专门的复制线程，从主库接收 Binlog，然后把 Binlog 写到一个中继日志里面，再给主库返回复制成功的响应,主从的操作是两个不同的线程,不会相互等待,但是在异步复制的情况下 它没有办法保证数据能第一时间复制到从库上,如果主库宕机就会有丢数据的风险,读写分离存在读到脏数据的问题.
为了解决同步和异步复制的问题,mysql 5.7版本后新增了一个同步方式, 半同步复制: 半同步复制介于同步和异步二者之间，事务线程不用等着所有的复制成功响应，只要一部分复制响应回来之后，就可以给客户端返回了。
优点: 因为配置成半同步复制，只要数据成功复制到任意一个从库上，主库的事务线程就直接返回了。这种半同步复制的方式，它兼顾了异步复制和同步复制的优点。如果主库宕机，至少还有一个从库有最新的数据，不存在丢数据的风险。并且，半同步复制的性能也还凑合，也能提供高可用保证，从库宕机也不会影响主库提供服务。所以，半同步复制这种折中的复制方式，也是一种不错的选择。
重要的参数
rpl_semi_sync_master_wait_no_slave: 含义是：“至少等待数据复制到几个从节点再返回”。
这个数量配置的越大，丢数据的风险越小，但是集群的性能和可用性就越差。最大可以配置成和从节点的数量一样，这样就变成了同步复制。一般情况下，配成默认值 1 也就够了，这样性能损失最小，可用性也很高，只要还有一个从库活着，就不影响主库读写。丢数据的风险也不大，只有在恰好主库和那个有最新数据的从库一起坏掉的情况下，才有可能丢数据。
rpl_semi_sync_master_wait_point: 这个参数控制主库执行事务的线程，是在提交事务之前（AFTER_SYNC）等待复制，还是在提交事务之后（AFTER_COMMIT）等待复制。默认是 AFTER_SYNC，也就是先等待复制，再提交事务，这样完全不会丢数据。AFTER_COMMIT 具有更好的性能，不会长时间锁表，但还是存在宕机丢数据的风险。
配置过程:
具体配置过程可参照:blog.csdn.net/u010870518/…
另外，虽然我们配置了同步或者半同步复制，并且要等待复制成功后再提交事务，还是有一种特别容易被忽略、可能存在丢数据风险的情况。如果说，主库提交事务的线程等待复制的时间超时了，这种情况下事务仍然会被正常提交。并且，MySQL 会自动降级为异步复制模式，直到有足够多（rpl_semi_sync_master_wait_no_slave）的从库追上主库，才能恢复成半同步复制。如果这个期间主库宕机，仍然存在丢数据的风险。
