ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

记录一次 Mysql主从同步搭建过程

2021-09-12 18:02:00  阅读:187  来源: 互联网

标签:主库 同步 slave 复制 master Mysql 从库 主从 搭建


Mysql主从同步搭建过程

先说一下我的环境:

这里我用的是虚拟机,系统是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_filemaster_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了

标签:主库,同步,slave,复制,master,Mysql,从库,主从,搭建
来源: https://blog.csdn.net/haiyanghan/article/details/120251454

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有