MySql主从复制模式，在不停服的情况下解决数据不同步的问题

主从复制搭建

Docker部署mysql并实现主从复制

主从不同步或从节点无法复制

在上一篇《Docker部署mysql并实现主从复制》的末尾，有提到两种关于Slave_SQL_Running不为yes的故障排查及恢复步骤，但是是在主节点锁库或者设置只读的情况下进行恢复，也就意味着此时数据库无法对外提供写服务。在线上生产环境并不合适。因为不锁表或者不设置只读的话，主库的MASTER_LOG_FILE和MASTER_LOG_POS是一直在变化的。
刚好最近在工作中遇到这个问题，进过测试可以完美解决主库不停服情况下恢复从库的复制，在这里做一下记录。

主库数据备份

使用mysqldump备份数据库，关键参数–master-data。
–master-data选项的作用就是将二进制的信息写入到输出文件中，在这里是写入到备份的sql文件中。选项开启时默认会打开lock-all-tables，因此同时实现了两个功能，一个是加锁，一个是取得log信息。
master_data取1和取2的区别，后者只是把 change master … 命令注释起来了，没多大实际区别；
–single-transaction在导出开始时设置事务隔离状态并使用一致性快照开始事务,而后马上unlock tables，然后执行导出,导出过程不影响其它事务或业务连接，但只支持类似innodb多版本特性的引擎，因为必须保证即使导出期间其它操作(事务点t2)改变了数据，而导出时仍能取出导出开始的事务点t1时的数据。
当master_data和 single_transaction 同时使用时，先加全局读锁，然后设置事务一致性和使用一致性快照开始事务，然后马上就取消锁，然后执行导出。

// 备份所有的DB
mysqldump -uroot -p  --single-transaction --no-autocommit --master-data=2 -A > fileName_dump.sql
// 备份单个DB
mysqldump -uroot -p  --single-transaction --no-autocommit --master-data=2  dbName > fileName_dump.sql

查看备份的文件

// 查看备份文件
[root@localhost home]# head -n 30 fileName_dump.sql 
-- MySQL dump 10.13  Distrib 5.7.27, for Linux (x86_64)
--
-- Host: localhost    Database: lasa_parking
-- ------------------------------------------------------
-- Server version5.7.27-log

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET @OLD_TIME_ZONE=@@TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0 */;

--
-- Position to start replication or point-in-time recovery from
--

-- CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000247', MASTER_LOG_POS=29759823;

--

关键点，记录下MASTER_LOG_FILE和MASTER_LOG_POS，后面配置从库复制时会用到

CHANGE MASTER TO MASTER_LOG_FILE=‘mysql-bin.000247’, MASTER_LOG_POS=29759823;

备份文件传输

使用scp命令发送备份文件到从节点服务器

scp fileName_dump.sql  root@192.168.0.21:/root/fileName_dump.sql

从库清空

// 删除从节点数据库
drop database dbName
// 重新床架从节点数据库并使用
create database dbName
use dbName
// 
source fileName_dump.sql

从节点配置

// 先重置一下slave
reset slave all;
// 连接主节点
CHANGE MASTER TO MASTER_HOST='192.168.0.20',MASTER_PORT=3306,MASTER_USER='repl',MASTER_PASSWORD='123',MASTER_LOG_FILE='mysql-bin.000247',MASTER_LOG_POS=29759823;
// 启动从节点复制
start slave;
// 查看从节点状态, Slave_SQL_Running: Yes说明从节点服务配置成功
show slave status\G

Slave_IO_Running: Yes，Slave_SQL_Running: Yes:说明主从节点IO通讯和bin_log同步均正常。
Master_Log_File: mysql-bin.000248和Relay_Master_Log_File: mysql-bin.000248是一致的。
Read_Master_Log_Pos: 6520180和Exec_Master_Log_Pos: 6520180也是一致的。