一步步带你事先MySQL配置主从复制项目记录
一、检测通信
查看master（centos7）和slave（win10）的ip地址，并检测是否可以相互通信
到这里我们知道，master的ip为192.168.131.129，slave的ip为192.168.0.6，并且可以相互通信
查看防火墙状态
临时手动启动、停止防火墙
systemctl stop 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> GRANT REPLICATION SLAVE ON *.* to ‘mslave’@’192.168.131.1’ IDENTIFIED BY ‘1qaz@WSX’;
mysql> FLUSH PRIVILEGES;
开启主从复制的权限，从库可以通过这个账户和密码，从这个IP来请求访问这个主库上的任意库，同步这个主库的任意库里的任意表
3. 获取binlog文件名和position
看当前二进制日志的名字，主库的更新是往哪个binlog写的，以及当前写日志的位置，从这个位置往后开始进行主从同步
三、slave配置
1. 配置全局唯一的server-id
找到my.ini
配置全局唯一的server-id
重启MySQL服务
2. 使用master创建的账户读取binlog同步数据
这一步配置主要是给IO线程读取binlog使用
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端口是否可以连接
最重要的是，自己玩的时候，如果虚拟机是NAT模式，则需要写成VMnet8网关ip。如果都是物理机通信，那直接写正确的ip即可
可以在MySQL数据库下的mysql库的user表中更改允许登录的ip
然后重新赋予权限
出现错误后还可以查看错误日志中提示的ip是否和自己允许slave登录的ip一致
2. binlog的position问题
在master中查看show master status一下binlog日志文件名以及position，然后用命令重新配置slave，比如：
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
set global sql_slave_skip_counter=1;
start slave;
可以通过show slave status查看以下标识，IO线程出错一般是网络问题，SQL线程出错一般是SQL在slave库执行出现了问题
