共计 3581 个字符，预计需要花费 9 分钟才能阅读完成。
对于 MySQL 主从搭建，松哥之前写过好多篇文章了，还录过一个视频。不过之前的都是一主一从的构造，然而小伙伴们晓得，咱们在我的项目中，更常见一种构造是双 M 构造，即两个 MySQL 实例，每个 MySQL 实例互为主备，这样在主节点忽然断电或者不可用的时候，slave 节点能够很快切换为 master，架构图如下：
在这种构造中，两个 MySQL 实例的位置是平等的，互为对方的主备，咱们判断谁是主机谁是从机的形式次要是看 readonly，谁是只读的，那谁就是从机，所以这种状况下，主从切换也很不便，只有批改 readonly 属性即可。
接下来咱们就来搭建一个双 M 的主从备份，看看和单纯的 M-S 构造的有啥区别。
1. 筹备工作
以下配置基于 Docker。
这里，咱们首先筹备两台机器：
- M1：10.3.50.27:33061
- M2：10.3.50.27:33062
1.1 M1 配置
M1 的配置就三个步骤，比拟容易：
1. 受权给 M2 服务器
GRANT REPLICATION SLAVE ON *.* to 'rep1'@'10.3.50.27' identified by '123';
FLUSH PRIVILEGES; 这里示意配置 M2 登录用户名为 rep1，明码为 123，并且必须从 10.3.50.27 这个地址登录，登录胜利之后能够操作任意库中的任意表。其中，如果不须要限度登录地址，能够将 IP 地址更换为一个 %。
留神，在 MySQL8 里边，这块有一些变动。MySQL8 中用户创立和受权须要离开，不能像下面那样一步到位，具体形式如下：
CREATE USER `rep1`@`10.3.50.27` IDENTIFIED WITH caching_sha2_password BY 'javaboy.COM';
GRANT Replication Slave ON *.* TO `rep1`@`10.3.50.27`;2. 批改主库配置文件
开启 binlog，并设置 server-id，每次批改配置文件后都要重启 MySQL 服务才会失效
开启 binlog 次要是批改 MySQL 的配置文件 mysqld.cnf，该文件在容器的 /etc/mysql/mysql.conf.d 目录下。
针对该配置文件，咱们做如下批改：
[mysqld]
# 这个参数示意启用 binlog 性能，并指定 binlog 的存储目录
log-bin=javaboy_logbin
# 设置 binlog_format 格局，留神不要应用 STATEMENT
binlog_format=ROW
# 设置一个 binlog 文件的最大字节
# 设置最大 100MB
max_binlog_size=104857600
# 设置了 binlog 文件的有效期（单位：天）expire_logs_days = 7
# binlog 日志只记录指定库的更新（配置主从复制的时候会用到）binlog-do-db=javaboy_db
# binlog 日志不记录指定库的更新（配置主从复制的时候会用到）#binlog-ignore-db=javaboy_no_db
# 写缓存多少次，刷一次磁盘，默认 0 示意这个操作由操作系统依据本身负载自行决定多久写一次磁盘
# 1 示意每一条事务提交都会立刻写磁盘，n 则示意 n 个事务提交才会写磁盘
sync_binlog=0
# 为以后服务取一个惟一的 id（MySQL5.7 开始须要）server-id=1各项配置的含意松哥曾经在凝视中阐明了。截图如下：
如下图：
- log-bin：同步的日志门路及文件名，肯定留神这个目录要是 MySQL 有权限写入的（我这里是偷懒了，间接放在了上面那个 datadir 上面）。
- binlog-do-db：要同步的数据库名，当从机连上主机后，只有这里配置的数据库才会被同步，其余的不会被同步。
- server-id: MySQL 在主从环境下的惟一标志符，给个任意数字，留神不能和 M2 反复，因为未来 server-id 用于标记 binlog 是由哪个库产生的，所以主从数据库的 server-id 千万不能一样，不然可能导致主从数据库 binlog 的循环复制问题。
- 留神 binlog_format 的值为 ROW，具体起因在之前的文章中松哥曾经和大家聊过了，这里就不再赘述。
配置实现后重启 MySQL 服务端：
docker restart mysql330613. 查看 M1 以后二进制日志名和偏移量
这个操作的目标是为了在 M2 启动后，从这个点开始进行数据的复原：
show master status;
至此，M1 配置实现。
1.2 M2 配置
M2 的配置和 M1 截然不同，惟一不同的中央在于，M2 的 mysqld.cnf 这个文件中的 server-id=2，其余都截然不同，我就不反复了。
配置实现后，相当于 M2 当初也是一个主机，咱们在 M2 上也能够执行 show master status; 命令，后果如下：
1.3 主从配置
接下来配置 M1 和 M2 别离为对方的主机。
M1 配置
先来配置给 M1 配置吧，执行如下命令设置主机：
change master to master_host='10.3.50.77',master_port=33062,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154;这里配置了主机地址、端口以及从机登录主机的用户名和明码，留神最初两个参数要和 M2 中的保持一致。
留神，因为 MySQL8 明码插件的问题，这个问题同样会给主从配置带来问题，所以在 MySQL8 配置主从上，下面这行命令须要增加 get_master_public_key=1，残缺命令如下：
change master to master_host='10.3.50.77',master_port=33062,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154,get_master_public_key=1;3. 启动 slave 过程
start slave;启动之后查看从机状态：
show slave status\G;
4. 查看 slave 的状态
次要是上面两项值都要为为 YES，则示意配置正确：
Slave_IO_Running: Yes
Slave_SQL_Running: Yes至此，配置实现，主机创立库，增加数据，从机会主动同步。
如果这两个有一个不为 YES，示意主从环境搭建失败，此时能够浏览日志，查看出错的起因，再具体问题具体解决。
M2 配置
接下来再来配置 M2，M2 和 M1 的配置基本上是统一的，change master 中记得把地址和端口写对：
change master to master_host='10.3.50.77',master_port=33061,master_user='rep1',master_password='123',master_log_file='javaboy_logbin.000001',master_log_pos=154;配置实现后，当初 M1 和 M2 就互为主备了。
1.4 测试
测试分两步：
- M1 中新建 javaboy_db 库，库中建 user 表，表中插入一条记录，而后查看 M2 中是否将数据同步过去了。
- M2 中向 user 表中增加一条记录，查看 M1 中是否有对应的值。
通过测试，咱们发现没问题，当初能够两边相互同步对方的数据了。
2. 谁主谁从
尽管是双 M 构造，然而在理论利用中还是得分个主从，那么双 M 该怎么分主从呢？
在生产环境中，咱们个别会将备份节点设置为 read_only，也就是只读，避免有误操作，当然不必放心设置为 read_only 后 binlog 的写入也被阻止，super 用户仍然领有写入权限。
设置全库只读的方法也很简略，首先咱们执行如下 SQL 先看看对应变量的值：
show variables like 'read_only';
能够看到，默认状况下，read_only 是 OFF，即敞开状态，咱们先把它改为 ON，执行如下 SQL：
set global read_only=1;1 示意 ON，0 示意 OFF，执行后果如下：
这个 read_only 对 super 用户有效，所以设置实现后，接下来咱们退出来这个会话，而后创立一个不蕴含 super 权限的用户，用新用户登录，登录胜利之后，执行一个插入 SQL，后果如下：
能够看到，这个错误信息中说，当初的 MySQL 是只读的（只能查问），不能执行以后 SQL。
如此设置之后，在 master 产生异样须要主从切换的时候再将 slave 长期顶替上来。为了更好的做到主从同步，binlog 的类型倡议应用 row 模式，对于 binlog 的三种模式，能够参考 666！MySQL 的 binlog 的三种格局这么好玩！一文。
好啦，有问题欢送留言探讨。
