一、检测通信

查看master(centos7)和slave(win10)的ip地址,并检测是否可以相互通信

到这里我们知道,master的ip为192.168.131.129,slave的ip为192.168.0.6,并且可以相互通信

查看防火墙状态

systemctl status firewalld.service

临时手动启动、停止防火墙

systemctl start firewalld.service
systemctl stop firewalld.service

持久打开、关闭防火墙(重启服务生效)

systemctl enable firewalld.service
systemctl disable firewalld.service

开放3306端口

二、master配置

1. 开启二进制日志

配置log_bin和全局唯一的server-id,和slave区分开,不能配置成一样的(如果是my.cnf新添加配置,一定要重启mysql服务)

2. 创建一个用于主从库通信用的账号

即在master中创建一个账号,用于slave登录master读取binlog

虽然我们在linux上查看的ip地址是192.168.131.129,但我们创建账户登录时不写这个ip,写的是192.168.131.1。因为我这里虚拟机用的是nat模式,虚拟机(master)和物理机(slave)通信的时候,虚拟机先把数据发送到网关192.168.131.1(默认与vmnet8通信),192.168.131.1再转发到物理机,所以物理机接收到的是192.168.131.1的数据,故我们在master上为slave创建账户的时候,应该写192.168.131.1

如果给slave配置的不是网关192.168.131.1地址,错误日志(可在my.cnf中指定)中会有如下信息:

意思是从192.168.131.1的mslave用户权限不够,那是因为我们在master上配置的是允许从其他地址登录,并不是允许从192.168.131.1地址登录,这就导致权限不够。

由于master这边收到的就是来自192.168.131.1的请求,所以错误日志显示的是192.168.131.1

所以创建账户的命令应如下:

mysql> create user 'mslave'@'192.168.131.1' identified by '1qaz@wsx';
mysql> grant replication slave on *.* to 'mslave'@'192.168.131.1' identified by '1qaz@wsx';
mysql> flush privileges;

开启主从复制的权限,从库可以通过这个账户和密码,从这个ip来请求访问这个主库上的任意库,同步这个主库的任意库里的任意表

3. 获取binlog文件名和position

看当前二进制日志的名字,主库的更新是往哪个binlog写的,以及当前写日志的位置,从这个位置往后开始进行主从同步

show master status;

三、slave配置

1. 配置全局唯一的server-id

找到my.ini

配置全局唯一的server-id

重启mysql服务

2. 使用master创建的账户读取binlog同步数据

这一步配置主要是给io线程读取binlog使用

mysql> change master to master_host='192.168.131.129',master_port=3306,master_user='mslave',master_password='1qaz@wsx',
master_log_file='mysql-bin.000006',master_log_pos=1262;

master_host:指定master的ip
master_log_file:binlog文件名
master_log_pos:binlog的position

3. 开启slave服务

通过show slave status命令查看主从复制状态,show processlist查看master和salve相关线程的运行状态

四、配置中可能出现的问题

1. 网络连接问题

通过show slave status命令查看主从复制状态

连接connection错误,先考虑是否网络互通,ping一下

然后再检查从库里面的配置信息是否正确

如果都正确,还可以检查一下master的3306端口是否可以连接

telnet xxx.xxx.xxx.xxx 3306

最重要的是,自己玩的时候,如果虚拟机是nat模式,则需要写成vmnet8网关ip。如果都是物理机通信,那直接写正确的ip即可

可以在mysql数据库下的mysql库的user表中更改允许登录的ip

然后重新赋予权限

mysql> grant replication slave on *.* to 'mslave'@'xxx.xxx.xxx.xxx' identified by '1qaz@wsx';

出现错误后还可以查看错误日志中提示的ip是否和自己允许slave登录的ip一致

2. binlog的position问题

在master中查看show master status一下binlog日志文件名以及position,然后用命令重新配置slave,比如:

mysql> change master to master_host='192.168.131.129',master_port=3306,master_user='mslave',master_password='1qaz@wsx',
master_log_file='mysql-bin.000006',master_log_pos=1262;

配置slave前需要stop slave,配置完成再start slave

3. sql线程出错

问题发生原因如下:

首先配置主从复制的时候,slave的mytest库中没有user表,而master的mytest库已经有user表了

配置好主从复制后直接drop table mytest.user,这就会写到binlog里面,然后在通过dump线程和io线程将这个操作发送到从库的relay log,然后从库的sql线程从relay log里把drop table mytest.user捞出来在从库执行这个sql,可从库的mytest根本就没有user表,这就是删除一个不存在的表,于是出现错误了

一般我们不会做这样的操作,一般都是主从配置以后,slave从数据开始增量进行同步,先做数据的增量,然后做数据的增删改查

不会配置好主从复制后,一开始就删主库的东西,如果真的出现这样的问题,随时可以在从库 show slave status,来查看主从同步的状态,有什么错误,就相应解决

要么在stop slave,把position重新设置一下,start slave,即重新开启主从同步,从最新的位置,这个drop操作不需要在从库上同步

要么就是stop,跳过该个错误,然后start

stop slave;
set global sql_slave_skip_counter=1;
start slave;

可以通过show slave status查看以下标识,io线程出错一般是网络问题,sql线程出错一般是sql在slave库执行出现了问题

 到此这篇关于mysql实现配置主从复制项目实践的文章就介绍到这了,更多相关mysql  主从复制内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持!