这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记。
复制流程
- Master开启bin log日志功能，日志用于记录数据库的更新内容。
- 需要开启3个线程，Master IO线程、Slave开启 IO线程、 SQL线程。
- 当从节点当从节点连接主节点时，主节点会创建一个log dump线程。
- Slave 通过IO线程连接master，并且请求某个bin-log，position之后的内容。
- MASTER服务器收到slave IO线程发来的日志请求信息，io线程去将bin-log内容，position返回给slave IO线程。
- Slave服务器收到bin log日志内容，将内容写入relay log中继日志。
- Slave端开启SQL线程，实时监控relay log日志内容是否有更新，解析文件中的SQL语句，在slave数据库中去执行。
复制模式
\
异步模式：
主节点不会主动推送bin-log到从节点，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主节点如果崩溃掉了，此时主节点上已经提交的事务可能并没有传到从节点上，如果此时，强行将从提升为主，可能导致新主节点上的数据不完整。
半同步模式：
介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay-log中才返回成功信息给客户端（只能保证主库的bin-log至少传输到了一个从节点上，但并不能保证从节点将此事务执行更新到db中），否则需要等待直到超时时间然后切换成异步模式再提交。相对于异步复制，半同步复制提高了数据的安全性，一定程度的保证了数据能成功备份到从库，同时它也造成了一定程度的延迟，但是比全同步模式延迟要低，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。
全同步复制：
全同步方式，当主库在执行完客户端提交的事务后，必须等待此次的binlog发送给从库，并且所有从库成功地执行完该事务后，主库才能返回客户端。
复制方式
MySQL 主从复制有三种方式：基于SQL语句的复制（statement-based replication，SBR），基于行的复制（row-based replication，RBR)，混合模式复制（mixed-based replication,MBR)。对应的bin-log文件的格式也有三种：STATEMENT, ROW, MIXED。
Statement-base Replication (SBR) ： 就是记录sql语句在bin-log中，Mysql 5.1.4 及之前的版本都是使用的这种复制格式。
优点：是只需要记录会修改数据的sql语句到bin-log中，减少了bin-log日志量，节约I/O，提高性能。
缺点：是在某些情况下，会导致主从节点中数据不一致（比如sleep(),now()等）。
Row-based Relication(RBR)： mysql master将SQL语句分解为基于Row更改的语句并记录在bin-log中，也就是只记录哪条数据被修改了，修改成什么样。
优点： 不会出现某些特定情况下的存储过程、或者函数、或者trigger的调用或者触发无法被正确复制的问题。
缺点： 会产生大量的日志，尤其是修改table的时候会让日志暴增,同时增加bin-log同步时间。也不能通过bin-log解析获取执行过的sql语句，只能看到发生的data变更。
Mixed-format Replication(MBR)： MySQL NDB cluster 7.3 和7.4 使用的MBR。是以上两种模式的混合，对于一般的复制使用STATEMENT模式保存到bin-log，对于STATEMENT模式无法复制的操作则使用ROW模式来保存，MySQL会根据执行的SQL语句选择日志保存方式。
读写分离配置
- 修改Master my.cnf 配置服务id、开启binglog功能等，配置从库的连接账号密码。
- 修改Slave my.cnf 配置服务id、Master的地址，开启mysql后，输入命令开始主从同步。
- SpringBoot中可以使用shardsphere配置主从复制，配置多个数据源，并指定主从数据源，运行时会根据sql类型判断主库访问还是从库访问。
