MySQL-使用bin-log日志不停主库，恢复主从同步

版权声明： https://blog.csdn.net/Scirhh/article/details/89480177

    之前编者在前面写过「 Mysql - 主从复制不一致，不停库不锁表恢复主从同步」的文章。但，编者当时觉得太繁琐，恢复速度巨慢（特别是对于大数据的数据库）。所以，在那之后，编者就捣鼓了使用 bin-log 恢复主从同步的方法与大家分享。

1、搭建 MySQL 主从同步架构

    MySQL 主从同步具体搭建步骤，请参考 CentOS下搭建 MySQL + Keepalived 主从高可用

2、确认主从的状态，如下图

主库：

[root@seichung1 ] mysql -uroot -p
mysql> show master status\G
*************************** 1. row ***************************
             File: skon-binlog.000006
         Position: 582096
     Binlog_Do_DB:
 Binlog_Ignore_DB:
Executed_Gtid_Set: 6b756fde-4c48-11e9-955f-000c29a9ef8c:1-9428
1 row in set (0.01 sec)

从库：

[root@seichung2 ] mysql-uroot -p
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.16.253
                  Master_User: seichung
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: skon-binlog.000006
          Read_Master_Log_Pos: 588147
               Relay_Log_File: seichung2-relay-bin.000011
                Relay_Log_Pos: 465208
        Relay_Master_Log_File: skon-binlog.000006
             Slave_IO_Running: Yes
            Slave_SQL_Running Yes
					……

3、修改 my.cnf 文件

    为了保证不会使得 bin-log 日志文件过大，致使后面恢复困难，所以需要在 my.cnf 添加 max_binlog_size = 1G 参数

[root@seichung1 ] vim /etc/my.cnf
	max_binlog_size = 1G
[root@seichung1 ] systemctl restart mysqld

4、模拟从库宕掉，然后创建数据库，导入数据。

从库：

[root@seichung2 ] mysql-uroot -p
mysql> stop slave;

    主库创建 seichung 库，并查看主从同步情况，主从出现不同步，这是因为已经将从库 stop , 所以主从不会进行同步

主库：

[root@seichung1 ] mysql-uroot -p
mysql>　create database seichung charset=utf8;
mysql> show database;

    接下来，启动 slave ，查看主从的状态。如图：

[root@seichung2 ] mysql-uroot -p
mysql> start slave;
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 192.168.16.253
                  Master_User: seichung
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: skon-binlog.000006
          Read_Master_Log_Pos: 2365741
               Relay_Log_File: seichung2-relay-bin.000011
                Relay_Log_Pos: 2243113
        Relay_Master_Log_File: skon-binlog.000006
             Slave_IO_Running: No
            Slave_SQL_Running: No
              Replicate_Do_DB:
              			……

5、恢复主从同步结构。

5.1、将主库上的 bin-log 日志传到从库上，利用 bin-log 进行数据恢复。

主库：

[root@seichung1 ] scp /data/mysql/skon-binlog.000006 [email protected]:/data/

从库：停止从库的 slave，利用 bin-log 恢复数据

[root@seichung2 ] mysql -uroot -p
mysql> stop slave;
[root@seichung2 ] mysqlbinlog /data/skon-binlog.000006 | mysql -uroot -p

5.2、这里有人可能会有疑问，生产环境下，主库是时时刻刻都在写入数据等操作，那么怎么主从同步的数据是一致的呢？

    先不 start slave ，在主从上模拟时刻写入数据（导入数据）。看下主从同步最后是否会恢复。之前只是创建了 seichung 库，seichung库并没有数据。接下来，导入数据到 seichung 库。如下图

主库：

[root@seichung1 ]  mysql -uroot -p < seichung.sql

5.3、校验之前，先来查看下，主库与从库里的数据一致性。

会发现，主从的数据是不一致的。

主库：

[root@seichung1 ] mysql -uroot -p
mysql> show databases;

从库：

[root@seichung2 ] mysql -uroot -p
mysql> show databases;

5.4、启动 slave ，校验 MySQL 主从同步是否恢复。

从库：

[root@seichung2 ] mysql -uroot -p
mysql> start slave;
mysql> show slave status\G

主库：

[root@seichung1 ] mysql -uroot -p
mysql> drop database ycm;

    最后，检查主从的数据一致性。可以看到，主从已经恢复，删除 ycm 库，从库上也会一起删除。如图