Question

在实际的生产环境中，一般都是读多写少，为了提高性能，会采用主从复制的方式进行 读写分离 。即在主数据库（master）中写入数据，从数据库（slave）中读取数据。

原理

主从复制的过程主要由三个线程参与:

• master（binlog dump thread）:主库线程，主库数据更新时，将更新事件写入主库的 binlog，并且通知从库数据有更新。
• slave（I/O thread）:从库线程，读取主库的 binlog 并写入从库的 relay log。
• slave（SQL thread）:从库线程，读取从库的 relay log 并执行 SQL 语句，将数据更新到从库的表中。

注意:要实现主从复制，必须要求主库开启 binlog

搭建主从复制

主机配置文件

my.cnf

[mysqld]
# [必选] 主服务器唯一 ID
server-id=1

# [必选] 启用 binlog，并指定基础文件名，当带上路径时，也会同时指定文件存放的路径
log-bin=fengye404

# [可选] 0（默认）表示读写（主机），1 表示只读（从机）
read-only=0

# [可选] binlog 保留时长，单位为秒，不填默认 30 天
binlog_expire_logs_seconds=6000

# [可选] 单个 binlog 文件最大大小，默认 1GB
max_binlog_siez=200M

# [可选] 忽略的数据库，一般忽略 mysql 自带的数据库
binlog-ignore-db=mysql
binlog-ignore-db=information_schema
binlog-ignore-db=performance_schema
binlog-ignore-db=sys

# [可选] 记录 binlog 的数据库，默认全部
binlog-do-db=test

# [可选] 设置 binlog 格式
binlog_format=MIXED

从机配置文件

[mysqld]
# [必选] 从服务器唯一 ID
server-id=2

# [必选] 启用 relaylog，并指定基础文件名，当带上路径时，也会同时指定文件存放的路径
relay-log=fengye404

# [可选] 0（默认）表示读写（主机），1 表示只读（从机）
read-only=0

由于每台服务器的情况不同，剩下的部分自己实操吧，懒得写了

主从复制的一致性问题

根据上面讲的主从复制的原理，很容易想象到，其实主库和从库的内容不是实时同步的，其中可能会由于一些网络传输问题而存在一定的延迟。这样就会造成读写分离时读库的数据不是最新数据，也就是会发生主从同步中的数据不一致问题。按照数据一致性从弱到强，有三种数据同步策略。

异步复制

主库开启事务，更新完数据后可以直接提交，不需要等从库返回任何结果。

优点是不会影响主库写的效率，缺点是数据一致性弱。

半同步复制

主库开启事务，更新完数据后可以必须等待至少一个从库接收到了 binlog 并写入到中继日志中后，才能提交。可以通过 rpl_semi_sync_master_wait_for_slave_count 参数设置需要多少个从库响应。

优点是数据一致性相比于异步复制提高了很多，缺点是主库的写入性能收到影响

组复制

半同步复制虽然一定程度上提高了数据的一致性，但是由于其需要从库响应来判断是否提交，所以无法满足对数据一致性要求很高的场景。

组复制技术，简称 MGR（MySQL Group Replication），是 MySQL5.7.17 以后推出的新的数据复制技术，是基于 Paxos 协议的状态机复制。

首先我们将多个节点共同组成一个复制组，在执行读写事务的时候，需要通过一致性协议层（Consensus 层）的同意，也就是读写事务想要进行提交，必须要经过组里 大多数人（对应 Node 节点）的同意，大多数指的是同意的节点数量需要大于 （N/2+1），这样才可以进行提交，而不是原发起方一个说了算。而针对只读事务则不需要经过组内同意，直接 COMMIT 即可。