Mysql主从同步搭建过程

• • 一. 主库环境搭建
  • • 1. 主库配置修改
    • 2. 检查配置是否生效
    • 3. 添加从库访问的角色
  • 二. 从库环境搭建
  • • 1. 修改配置
    • 2. 检查配置是否生效
    • 3. 从库连接到主库，进行同步
  • 三. 半同步复制
  • • 1. 配置半同步复制
    • 2. 测试
    • • • 2.1 从库关闭同步：
        • 2.2 从库开启同步

先说一下我的环境：

这里我用的是虚拟机，系统是Centos7，安装mysql 用的是 docker

一主两从配置：

主库： 192.168.31.24
从库1： 192.168.31.23
从库2： 192.168.31.22

Centos7安装Docker-ce
Docker安装mysql 以及 redis

一. 主库环境搭建

1. 主库配置修改

用Docker 安装好 mysql之后，需要修改两处设置

vi /usr/local/docker/mysql/conf/my.cnf

追加配置

server_id=1
log-bin=master-bin-log

重启mysql镜像

docker restart mysql

2. 检查配置是否生效

用 navicat 连接到mysql，在 数据库名为 performance_schema 的库里面执行

show variables like '%server_id%';

show master status;

如果显示为配置文件中的数据，说明就生效了

3. 添加从库访问的角色

然后在 数据库名为 mysql 的库里面执行这两条sql

GRANT ALL PRIVILEGES ON *.* TO 'slave'@'192.168.31.%' IDENTIFIED BY 'root123456' WITH GRANT OPTION;

flush privileges;

二. 从库环境搭建

1. 修改配置

vi /usr/local/docker/mysql/conf/my.cnf

追加配置

server_id=101
binlog_do_db=user
binlog_do_db=account
binlog_do_db=rule

binlog_do_db 就是要同步的库，多个库的话，就像我一样设置，要确保主库和从库都有这些数据库，并且表名和字段结构都一样，
如果不设置 binlog_do_db，就是同步所有库
binlog_ignore_db 这个表示不需要同步的库

重启mysql

docker restart mysql

2. 检查配置是否生效

用 navicat 连接到mysql，在 数据库名为 performance_schema 的库里面执行

show variables like '%server_id%';

如果显示为配置文件中的数据，说明就生效了

3. 从库连接到主库，进行同步

从库执行

stop slave;
change master to master_host='192.168.31.24', master_user='slave', master_password='root123456', master_log_file='master-bin-log.000002', master_log_pos=154;
start slave;

master_log_file 和 master_log_pos 是主库执行 show master status; 查询到的数据

到这里主从 同步就搭建完成了

三. 半同步复制

我们今天谈论第二种架构。我们知道，普通的replication，即MySQL的异步复制，依靠MySQL二进制日志也即binary log进行数据复制。比如两台机器，一台主库（master），另外一台是从库（slave）。

1. 正常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave的io线程接收到t1并写入到自己的的relay log；slave的sql线程写入到本地数据库。 这时，master和slave都能看到这条新的事务，即使master挂了，slave可以提升为新的master。

2. 异常的复制为：事务一（t1）写入binlog buffer；dumper线程通知slave有新的事务t1；binlog buffer进行checkpoint；slave因为网络不稳定，一直没有收到t1；master挂掉，slave提升为新的master，t1丢失。

3. 很大的问题是：主库和从库事务更新的不同步，就算是没有网络或者其他系统的异常，当业务并发上来时，slave因为要顺序执行master批量事务，导致很大的延迟。

为了弥补以上几种场景的不足，MySQL从5.5开始推出了半同步复制。相比异步复制，半同步复制提高了数据完整性，因为很明确知道，在一个事务提交成功之后，这个事务就至少会存在于两个地方。即在master的dumper线程通知slave后，增加了一个ack（消息确认），即是否成功收到t1的标志码，也就是dumper线程除了发送t1到slave，还承担了接收slave的ack工作。如果出现异常，没有收到ack，那么将自动降级为普通的复制，直到异常修复后又会自动变为半同步复制

半同步复制具体特性：

• 从库会在连接到主库时告诉主库，它是否配置了半同步。
• 如果半同步复制在主库端是开启了，并且至少有一个半同步复制的从库节点，那么此时主库的事务线程在提交时会被阻塞并等待，结果有两种可能，要么至少一个从库节点通知它已经收到了所有这个事务的Binlog事件，要么一直等待直到超过配置的超时时间为止，而此时，半同步复制将自动关闭，转换为异步复制。
• 从库节点只有在接收到某一个事务的所有Binlog，将其写入并Flush到Relay Log文件之后，才会通知对应主库上面的等待线程。
• 如果在等待过程中，等待时间已经超过了配置的超时时间，没有任何一个从节点通知当前事务，那么此时主库会自动转换为异步复制，当至少一个半同步从节点赶上来时，主库便会自动转换为半同步方式的复制。
• 半同步复制必须是在主库和从库两端都开启时才行，如果在主库上没打开，或者在主库上开启了而在从库上没有开启，主库都会使用异步方式复制

1. 配置半同步复制

追加修改主库配置文件：

plugin-load=rpl_semi_sync_master=semisync_master.so
rpl_semi_sync_master_enabled=1 

追加修改从库配置文件：

plugin-load=rpl_semi_sync_slave=semisync_slave.so
rpl_semi_sync_slave_enabled=1 

然后重启主库，从库

2. 测试

2.1 从库关闭同步：

然后主库添加数据：

执行了10s，原因是期间主库一直在等待从库返回确认消息，没有从库开启同步，所以才会执行了10s

2.2 从库开启同步

然后主库添加数据：

ok了