简单修复主从同步引发的bug

整理一下这周数据库主从不同步问题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已经降下来了,没有对服务造成影响,同时可以正常申帖。问题初步解决。

你可能感兴趣的:(linux,sql)