乙個由於時間問題引發的血案

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

。另外為了避免類似問題，將這個命令加入到系統初始化指令碼中，以後一安裝完系統就跑系統初始化指令碼。

教訓：這個是乙個很低階的錯誤，對於這種伺服器都需要用的基礎配置，必須新增到系統初始化指令碼中，避免再次出現類似的問題。同時也給自己乙個教訓就是配置好伺服器後需要做詳細的檢查，要細心，杜絕此類低階錯誤的發生。