原文：https://www.jianshu.com/p/9d84a725332d
https://www.cnblogs.com/fengzheng/p/13401783.html
https://juejin.im/entry/6844903458290532366
主从配置一般都是和读写分离相结合，主服务器负责写数据，从服务器负责读数据，并保证主服务器的数据及时同步到从服务器。
主节点
1、当主节点上进行 insert、update、delete 操作时，会按照时间先后顺序写入到 binlog 中；
2、当从节点连接到主节点时，主节点会创建一个叫做 binlog dump 的线程；
3、一个主节点有多少个从节点，就会创建多少个 binlog dump 线程；
4、当主节点的 binlog 发生变化的时候，也就是进行了更改操作，binlog dump 线程就会通知从节点 (Push模式)，并将相应的 binlog 内容发送给从节点；
从节点
当开启主从同步的时候，从节点会创建两个线程用来完成数据同步的工作。
（1）I/O线程： 此线程连接到主节点，主节点上的 binlog dump 线程会将 binlog 的内容发送给此线程。此线程接收到 binlog 内容后，再将内容写入到本地的 relay log。
（2）SQL线程： 该线程读取 I/O 线程写入的 relay log，并且根据 relay log 的内容对从数据库做对应的操作。
理论上怎么实现从库和主库的数据一致性？
1、异步复制
主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上，如果此时，强行将从提升为主，可能导致“数据不一致”。早期MySQL(5.5以前)仅仅支持异步复制。
2、半同步复制
MySQL在5.5中引入了半同步复制，主库在应答客户端提交的事务前需要保证至少一个从库接收并写到relay log中，半同步复制通过rpl_semi_sync_master_wait_point参数来控制master在哪个环节接收 slave ack，master 接收到 ack 后返回状态给客户端，此参数一共有两个选项 AFTER_SYNC & AFTER_COMMIT。
- AFTER_COMMIT
AFTER_COMMIT时，commitTrx的调用在engine层commit之后，即在等待Slave ACK时候，虽然没有返回当前客户端，但事务已经提交，其他客户端会读取到已提交事务。如果Slave端还没有读到该事务的events，同时主库发生了crash，然后切换到备库。那么就会出现数据不一致的问题。如果主库永远启动不了，那么实际上在主库已经成功提交的事务，在从库上是找不到的，也就是数据丢失了。
PS：早在11年前后，阿里巴巴数据库就创新实现了在engine层commit之前等待Slave ACK的方式来解决此问题。
3、全同步复制
MySQL官方针对上述问题，在5.7.2引入了Loss-less Semi-Synchronous，在调用binlog sync之后，engine层commit之前等待Slave ACK。这样只有在确认Slave收到事务events后，事务才会提交。
set rpl_semi_sync_master_wait_point=AFTER_SYNC
SET GLOBAL rpl_semi_sync_master_wait_for_slave_count= N；
// 应答多少个slave才commit
- AFTER_SYNC: 官方推荐的方式 # 即是先确认从库接收到数据并成功写入relaylog，主库再在引擎层提交数据。
客户端发出commit请求后，在主库上写入binlog并推送给slave，slave接收到binlog并写入relaylog，发送ACK确认已经接收binlog后，master在引擎层commit，客户端接收commit完成，此时其他会话才可以看见已提交的数据。
故障分析：假设master在接收ACK确认时宕机，因为在引擎层并没有提交，HA切换到从库，因为binlog已经写入从库的relaylog，因此不会造成数据丢失。
但是也不是万无一失，因为当主库在binlog flush并且binlog同步到了备库之后，binlog sync之前发生了abort，那么很明显这个事务在主库上是未提交成功的（由于abort之前binlog未sync完成，主库恢复后事务会被回滚掉），但由于从库已经收到了这些Binlog，并且执行成功，相当于在从库上多出了数据，从而可能造成“数据不一致”。
在after_sync模式下解决了after_commit模式带来的数据不一致的问题，因为主库没有提交事务。
此外，MySQL半同步复制架构中，主库在等待备库ack时候，如果超时会退化为异步后，也可能导致“数据不一致”。（等待的时间以rpl_semi_sync_master_timeout参数为准，默认为10秒。）
其他防丢失操作
- 在master上修改配置
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
上述两个选项的作用是：保证每次事务提交后，都能实时刷新到磁盘中，尤其是确保每次事务对应的binlog都能及时刷新到磁盘中，只要有了binlog，InnoDB就有办法做数据恢复，不至于导致主从复制的数据丢失。
- 在slave上修改配置
master_info_repository = "TABLE"
relay_log_info_repository = "TABLE"
relay_log_recovery = 1
上述前两个选项的作用是：确保在slave上和复制相关的元数据表也采用InnoDB引擎，受到InnoDB事务安全的保护，而后一个选项的作用是开启relay log自动修复机制，发生crash时，会自动判断哪些relay log需要重新从master上抓取回来再次应用，以此避免部分数据丢失的可能性。
配置示例
Master配置：
开启远程连接
使用命令行或者客户端工具进入 MySQL，执行命令：
GRANT REPLICATION SLAVE ON *.* to 'root'@'192.168.0.108' identified by 'P@ssw0rd';
FLUSH PRIVILEGES;
上面语句执行完成后，在从服务器中使用客户端或者命令行测试是否生效。
mysql -h 192.168.0.101 -uroot -p
启用 bin-log，并设置 server-id
需要在 MySQL 配置文件中修改，MySQL 配置文件默认位置在如下位置，从上下到下优先级降低：
/etc/my.cnf
/etc/mysql/my.cnf
/usr/local/etc/my.cnf
~/.my.cnf
配置内容如下：
[mysqld]
log-bin=mysql-bin
server-id=101
- 其他参数
除了上面两个必要参数外，还有其他的几个参数。
（1）binlog_format
bin-log 日志的格式，支持下面三种，推荐使用 mixed 。
statement：会将对数据库操作的sql语句写入到binlog中。
row：会将每一条数据的变化写入到binlog中。
mixed：statement 与 row 的混合。MySQL 决定什么时候写 statement 格式，什么时候写 row 格式。
（2） binlog-do-db
配置要同步的数据库，如果不配置默认为全部数据库。
binlog-do-db=db1
binlog-do-db=db2
（3）binlog-ignore-db
配置不需要同步的数据库。
binlog-ignore-db=db3
（4）expire-logs-days
bin-log 日志保存天数，保存天数越久占用空间越大。
然后重启 MySQL 服务
mysql.server restart
使用下面的命令可以查看配置是否生效：
show variables like 'log_bin';
show variables like 'server_id';
使用下面的语句查看 master 状态。
show master status;
从服务器配置
1、打开从服务器的配置文件，在其中加上如下配置：
server-id=108
2、重启 MySQL 服务。
mysql.server restart
3、配置主从同步
change master to master_host='192.168.0.101',master_user='root',master_password='P@ssw0rd',master_log_file='mysql-bin.000001' ,master_log_pos=154;
其中 master_host表示主服务器 IP，master_user和master_password分别是主服务器的用户名和密码，master_log_file和master_log_pos在主服务器中通过show master status语句可以查到。
4、开启同步进程。
start slave
5、查看同步状态。
show slave status;
- Slave挂了怎么恢复同步?
重启，只要同步服务再次启动，那就可以从上次同步的位置继续增量同步了。
- 单Master挂了怎么办？
如果马上启动那就是最好的解决办法。如果由于硬件或者比较棘手的问题导致没办法立即重启，那就要选一个从库升级为主库，选择的标准是数据最接近主库的，也就是最后一次同步时间最晚的。如果有可能（比如主服务只是数据库无法启动，但机器还在）还要到主服务上拉取最新的 bin-log 进行同步。最后进行一系列设置将选中的从库变更为主库配置。
- 大致步骤：
身份调换之前，主服务器会对表上锁，保证调换期间，不会写进新的数据。
从服务器先停止从服务器IO线程，此期间，会应用完RelayLog中的所有信息，保证主、从数据完全一致。接下来，主、从服务器都会把自身的Binlog文件清除掉，建立起新的Binlog文件，再将之前两者的交互信息删干净，此时，可以重新建立主从连接了，从服务器俨然成为新一代主服务器，而原主服务器也解开之前的表锁，担起了从服务器的角色，事实证明，这是一次完美的试炼。
作者：小幸运Q
链接：https://www.jianshu.com/p/9d84a725332d
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
