写在开篇，问题现象
❝这个是说主从复制中由于某些原因从库的数据总是滞后于主库，这时候就需要我们手动定期的进行主从库的数据同步了，使得主从数据差距能够减到最小。常用的方法就是：在负载较低时暂时阻塞主数据库的更新，强制主从数据库更新同步。
❝一般，通常，大部分来说，slave的数据滞后于master的主要原因是：slave因某些未知的原因没有连接上master，比如下面的情况，在slave服务器上查看复制的状态，发现Replica_IO_Running和Replica_SQL_Running两个线程都是NO，其实，只要有1个是NO，那么都是不正常的，因此要确保两个线程都是YES。
mysql> show replica status\G; *************************** 1. row *************************** Replica_IO_State: Queueing source event to the relay log Source_Host: 192.168.11.151 Source_User: syn_a Source_Port: 3306 Connect_Retry: 60 Source_Log_File: mysql-bin.000030 Read_Source_Log_Pos: 44702579 Relay_Log_File: zbx-db02-relay-bin.000003 Relay_Log_Pos: 25782831 Relay_Source_Log_File: mysql-bin.000029 Replica_IO_Running: NO Replica_SQL_Running: NO
❝小小的温馨提示：不过还有一些不可预知的情况，就算Slave库的IO线程和SQL线程都是YES，说不定slave的数据也是滞后于master，那么不管什么原因导致slave的数据滞后于master，那么都可以通过手动定期的进行主从库的数据同步。
开始手动同步操作
- 在master上操作
# 1. 在master上锁表，阻止应用写入或更新数据 ```shell FLUSH TABLES WITH READ LOCK; # 2. 查看master状态 查主库状态 mysql> show master status\G; *************************** 1. row *************************** File: mysql-bin.000047 Position: 27610714 Binlog_Do_DB: Binlog_Ignore_DB: Executed_Gtid_Set: 9208096f-4731-11ec-a23e-005056210589:1-22, 92099aae-4731-11ec-a3da-00505629525b:1-820702 1 row in set (0.00 sec) ERROR: No query specified mysql>
❝记住上面的这两个数值，File的二进制文件名字mysql-bin.000047，Position的数值27610714，这个数值是从库复制的目的坐标。
- 在slave上操作 在从库上，执行内置的MASTER_POS_WAIT函数
mysql> select MASTER_POS_WAIT('mysql-bin.000047','27610714'); +------------------------------------------------+ | MASTER_POS_WAIT('mysql-bin.000047','27610714') | +------------------------------------------------+ | 0 | +------------------------------------------------+ 1 row in set, 1 warning (0.32 sec)
❝通过select语句执行MASTER_POS_WAIT函数后，会进入阻塞状态，直到从库达到指定的日志文件和偏移量后，正常的话就返回0，否则返回-1，如果返回-1，则表示超时退出。
- 最后再回到master上操作 在主库上执行解锁操作，使其能够进行读写。
mysql> UNLOCK TABLES; Query OK, 0 rows affected (0.01 sec)
写在最后
❝如果按笔者的方法不能让您一招制敌，那请你关注我，我免费帮你修。
