记一次mysql5.7.22的已有数据的主从迁移

环境

步骤

备份已有环境数据

主库配置

从库配置

出现的问题及解决的方法

因新上线一个报表系统为了让两个系统独立，新的系统因是报表系统并不涉及业务逻辑但是又是比较消耗性能就准备利用mysql的主从搞一个从库保持两个系统的独立性就需要独立出来一个从库。大概就是这个原因让我们开始做主从复制。

环境

这是我们生产环境的配置如下

主机	版本
192.168.2.22	v5.7.22
192.168.2.23	v5.7.22

步骤

备份已有环境数据

因为我们是生产环境我们首先确定我们大概是在几点开始进行数据备份我们这次采用的是mysql自带的mysqldump 本身数据量就比较少我们导出来大概16G 用了2分钟左右生成了一个sql文件步骤比较简单因为使用的默认引擎innodb，在我们使用mysqldump时就自动锁表了不用再单独锁表:

1. 导出主库数据
   mysqldump -u root -p ahida --databases jiw >jiw20210112.sql
2. 导入数据到从库中时
   create database jiw;
mysql -uroot -p jiw>jiw20210112.sql;
3. 等待数据导入完全（因为我们的数据较少但是使用sql文件形式还是浪费了很多时间）查看当前导入到从库的数据是否一致

主库配置

我们目前的主库是已经再用 所用我们导出数据后就通知各个部门暂停1分钟的导入数据然后开始对主库开启binlog的设置，因为我们只需要同步一个业务库的所以加上了binlog-do-db=otms只同步这个库的binlog下面开始设置:
1、修改/etc/my.cnf 文件在【mysqlid】下添加如下:

##binlog配置
log-bin=master-bin #开启二进制日志
server-id=1 #设置server-id
binlog-format=ROW
binlog-do-db=otms
expire_logs_days = 7 # binlog过期清理时间
max_binlog_size = 1G # binlog每个日志文件大小

2、重启mysql

service mysql start

3、查看binlog是否启动成功

show variables like 'log_bin';

Value 为 OFF 则未开启日志文件
4、查看binlog日志状态

show master status;

5、赋权用户给一个用户可以访问log的权限的用户

GRANT REPLICATION SLAVE,REPLICATION CLIENT ON *.* TO 'slave'@'192.168.2.23' IDENTIFIED BY 'slave';
FLUSH PRIVILEGES;

从库配置

1、在/etc/my.cnf下配置binlog

#配置binlog  /etc/my.cnf
log_bin = slave-bin
server_id = 2
relay_log = slave-relay-bin
log_slave_updates = 1
#以下两个为可选选项，如果要保证数据不丢失最好在清理binlog之前把要清理的日志备份，日志文件的大小根据磁盘的性能做适当的调整
expire_logs_days = 7 #binlog过期清理时间
max_binlog_size = 100m #binlog每个日志文件大小

2、重启mysql跟主库一样查看是否成功
3、注册slave语句
CHANGE MASTER TO MASTER_HOST='10.100.10.52',MASTER_USER='SLAVE',MASTER_PASSWORD='SLAVE',MASTER_LOG_FILE='master-bin.000002',MASTER_LOG_POS=953;
4、开启slave
start slave
5、查看slave状态是否成功
SHOW SLAVE STATUS;

看到这两个参数为Yes 那到这数据就算成功了

出现的问题及解决的方法

1、在导出时出现表不存在但是使用dump 出现锁这张表 通过排查看到我们之前复制表的时候有过文件在但是表已经删除 出现 sheet.frm文件 这个时候把.frm文件啥删除就行了
2、在步骤都完成后同步有失败 查看日志看到 从库更新一个表但是这个表中这个字段不存在，我们当时想的是我们已经把服务关了为什么还会有插入呢。这时候一个同事说他还有个调度在跑在我们配置的时候这个时候表已经到导出完了。这样我们去对比我们在配置这3分钟内的数据 然后把从库缺的数据给补齐就可以了。