主从数据不一致，重新配置主从同步也是一种解决方法。
1.从库停止主从复制
mysql> stop slave;
2.对主库数据库加锁
flush tables with read lock;
3.备份主库数据
mysqldump -uroot -p --databases testdb1 testdb2 > bak.sql
4.重置主库日志
reset master；
这个是重置master的核心语法，看一下官方解释。
RESET MASTER removes all binary log files that are listed in the index file, leaving only a single, empty binary log file with a numeric suffix of .000001, whereas the numbering is not reset by PURGE BINARY LOGS.
RESET MASTER is not intended to be used while any replication slaves are running. The behavior of RESET MASTER when used while slaves are running is undefined (and thus unsupported), whereas PURGE BINARY LOGS may be safely used while replication slaves are running.
大概的意思是RESET MASTER将删除所有的二进制日志，创建一个.000001的空日志。RESET MASTER并不会影响SLAVE服务器上的工作状态，所以盲目的执行这个命令会导致slave找不到master的binlog，造成同步失败。
但是我们就是要重置同步，所以必须执行它。
5.对主库数据库解锁
unlock tables;
6.删除旧数据
drop database testdb1;
drop database testdb2;
7.重置备库日志
reset master；
8.从库导入数据
source /tmp/bak.sql
9.重置从库日志
RESET SLAVE; 或者 reset slave all;
官方解释：
RESET SLAVE makes the slave forget its replication position in the master‘s binary log. This statement is meant to be used for a clean start: It deletes the master.info and relay-log.info files, all the relay log files, and starts a new relay log file. To use RESET SLAVE, the slave replication threads must be stopped (use STOP SLAVE if necessary).
大概意思是，RESET SLAVE将清除slave上的同步位置，删除所有旧的同步日志，使用新的日志重新开始，这正是我们想要的。需要注意的是，必须先停止slave服务（STOP SLAVE），我们已经在第一步停止了它。
####清理slave 同步信息：
---reset slave 仅清理master.info 和 relay-log.info 文件
---删除所有的relay log 文件，重启用一个新的relay log 文件。
---重置 MASTER_DELAY 复制延迟间隔为:0
---不清理内存里的同步复制配置信息
---不重置 gtid_executed or gtid_purged 参数值
reset slave;
（重启mysqld后，内存里的同步配置信息自动重置）
reset slave all;
---其他功能和reset slave 一样，唯一区别是：会立即清理内存里的同步配置信息。
10.开启主从复制
start slave;