在从库上show slave status；
看到 io thread线程和sql thread两个YES，大概率是一致了。
极端情况再说。

查看两个yes和一个id号：

Slave_IO_Running:YES  

Slave_SQL_Running:YES

#截取远程Position号
#mysql -h 192.168.18.31 -u 'ceshi' -p123 -e 'show master status \G' |awk 'NR==3{print $2}'
#截取master的binlog的同步文件
#mysql -h 192.168.18.31 -u 'ceshi' -p123 -e 'show master status \G' |awk 'NR==2{print $2}'
#截取本地的slave的Position号
#mysql -e 'show slave status \G' |awk 'NR==23{print $2}'

主从不同步的情况：

1.网络延迟

由于mysql主从复制是基于binlog的一种异步复制，通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。

2.主从两台机器的负载不一致，由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。

3.max_allowed_packet设置不一致，主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。

4.自增键不一致，key自增键开始的键值跟自增步长设置不一致引起的主从不一致。

5.同步参数设置问题，mysql异常宕机情况下，如果未设置sync_binlog=1或者innodb_flush_log_at_trx_commit=1很有可能出现binlog或者relaylog文件出现损坏，导致主从不一致。

6.主库binlog格式未Statement，同步到从库执行后可能造成主从不一致。

7.主库执行更改前有执行set sql_log_bin=0，会使主库不记录binlog，从库也无法变更这部分数据。

8.从节点未设置只读，误操作写入数据。

9.主库或从库意外宕机，宕机可能会造成binlog或者relaylog文件出现损坏，导致主从不一致

10.主从实例版本不一致，特别是高版本是主，低版本是从的情况下，主数据库上面支持的功能从数据库上面可能不支持

11.MYSQL自身bug导致