一个由于时间问题引发的血案

一个由于时间问题引发的血案

导读：公司目前正在搞多机房部署，多机房部署数据库那一块采用是MYSQL的主主同步，由于部署另外一个机房的时候忘记添加时间ntp服务器的同步，导致两个机房服务器时间不一致，而公司有个论坛是采用discuzX2的版本，论坛的php的统计程序会在0点的时候做清空帖子数等一些操作，这些信息会改写数据库中相应的记录，应此通过MYSQL的同步，另外一边也出现帖子数清零的现象。

         公司目前正在实施多机房部署，避免因为一个机房出先问题而导致业务中断的情况，目前另外一个机房已经部署好了，只是目前只用了一个机房，深圳机房还处于测试阶段，架构如下图所示：

目前在用的是佛山机房。网站架构为LNMP(linux/nginx/mysql/php),其中论坛使用的是discuzX2的版本。

         下午3点的时候运营那边突然打电话过来询问，为什么论坛的所有板块的帖子都置0了？感到问题比较严重，于是赶紧登录服务器查看，SELECT `name`,todayposts FROM pre_forum_forum;查看这个板块表中，发现todayposts被重置了。因为数据库的管理员只有我一个人知道，因此不会有人去直接重置那个表的信息。查找计划任务看看是否有计划任务会去更新pre_forum_forum表的todayposts字段，也没发现。我怀疑是什么条件触发了那个论坛的一些统计脚本，因为帖子到了0点才会清零。突然意识到会不会是时间到0点了？于是登录佛山服务器查看，时间正常。再登录深圳机房服务器，oh my gold！时间是00点过2分钟。咨询开发，他们说是discuz中含有一些统计的和清零的脚本，到了0点就会清空帖子数等一些操作。这些操作会写入数据库，由于佛山和深圳机房做了MYSQL主主同步，因此也会同步到佛山机房的数据库中，导致佛山的论坛出现帖子数清零的现象。那么为什么深圳机房的时间会和佛山机房的差那么远呢？原来是忘记将时间同步的命令添加到计划任务中。赶紧将时间同步的命令添加到计划任务中，59 5,9,14,19,23 * * * ntpdate asia.pool.ntp.org。另外为了避免类似问题，将这个命令加入到系统初始化脚本中，以后一安装完系统就跑系统初始化脚本。

教训：这个是一个很低级的错误，对于这种服务器都需要用的基础配置，必须添加到系统初始化脚本中，避免再次出现类似的问题。同时也给自己一个教训就是配置好服务器后需要做详细的检查，要细心，杜绝此类低级错误的发生。