整理一下这周数据库主从不同步问题bug的解决过程。
起初的原因是审贴人员在申帖的时候，发现审过的帖子后来又出来了。这个在日志当中其实是有报错的。获取那条帖子的id获取失败。但是帖子肯定是存在的，原因初步推测是主从数据库不同步造成的。因为数据库分读写库。写库写完还需要推给从库。因为配置的审核帖子的是从写库获取的，之后因为数据没有完全同步过来。从读库读取的时候，出现的没有获取当前数据的情况。
这个时候，在从数据库上查show slave status; 然后找一个参数：second behind master的值。网上有文章说看这个值不太准，当这个值为0的时候可能出问题。我这里不存在这个问题。
后来发现确实在出问题的时段，这个值特别大，100多。这个时候，基本判定问题。开始找nginx日志和所有能查的日志。没有找到问题。
后来在老大看阿里的服务器性能异常的时候。发现了在问题时段，出现了大量的写入操作。
推断可能是有定时脚本在这个时候会跑。但是不确定是什么脚本。
因为数据库的mysqlbinlog是开启的，这个时候就去查了一下在问题时段的执行语句。这个当时因为没有仔细观察，mysqlbinlog里面会把replace into 给当成query. 导致第一次找错了位置。后来结合sql语句和crontab的时间，才真正的定位了bug位置。
代码本身并没有问题，这个时间段确实有大量的写入操作。而且就得在这个时间段执行。因为写库写入太快，但是从库跟不上同步，所有才出现这个问题。这个时候尝试加了一下time.sleep(5),写入主库3000个之后先同步一下。执行时间上并没有慢太多，但是画图的时候，明显能够看到second_behind_master已经降下来了，没有对服务造成影响，同时可以正常申帖。问题初步解决。