背景

事情是這樣的，在公司內(nèi)部新開發(fā)了一個功能還沒有上線，目前部署在測試環(huán)境，Node服務會開啟一個定時任務，每5分鐘會處理好一部分數(shù)據(jù)寫入到mysql數(shù)據(jù)庫中。

在這之前，一切都運行正常，中秋節(jié)后上班第一天打開后臺系統(tǒng)發(fā)現(xiàn)沒有數(shù)據(jù)展示了，然后查詢數(shù)據(jù)庫發(fā)現(xiàn)歷史存儲的數(shù)據(jù)都沒了，沒了?，F(xiàn)在只會存儲最新的定時任務執(zhí)行后的數(shù)據(jù)。可在此之間沒有修改過任何代碼，這個就神奇了。

頭疼時間

查看寫入的數(shù)據(jù)始終都只會存儲最新的數(shù)據(jù)，則檢查是否沒有觸發(fā)更新的邏輯，全部都命中新增的邏輯。

const isExist = await this.Model.findOne({
  where: {
    projectId
  }
});
if (isExist) {
  await isExist.destroy()
  updateList.push(item)
} else {
  createList.push(item)
}

現(xiàn)在的邏輯是將新增和更新分開處理，經(jīng)檢查發(fā)現(xiàn)所有的isExist都是null，導致全部命中新增的邏輯?？墒菙?shù)據(jù)庫中明明是有數(shù)據(jù)的，為什么查詢不出來呢？懷疑是有第三方數(shù)據(jù)存在臟數(shù)據(jù)之類的情況，所以我將數(shù)據(jù)庫現(xiàn)存數(shù)據(jù)全部清空，重新寫入查看效果。結果第一次寫入是正常的，后續(xù)還是不會觸發(fā)更新，經(jīng)過查詢發(fā)現(xiàn)每次寫入數(shù)據(jù)庫大約十幾秒數(shù)據(jù)就被清空了。

可是在寫入后的代碼邏輯中是沒有執(zhí)行刪除數(shù)據(jù)的處理，而且每次都是穩(wěn)定復現(xiàn)，寫入后就被刪除了，查詢無果無奈找到db幫找原因。db查詢?nèi)罩窘o出的結論就是有定時執(zhí)行刪除的邏輯。

看到日志只能繼續(xù)在代碼中找原因了。由于此時是使用的 sequelize 的 bulkCreate 批量創(chuàng)建數(shù)據(jù)，所以開始懷疑是不是這個批量處理的過程中出現(xiàn)了問題，當初是因為每次執(zhí)行的數(shù)據(jù)量太多所以沒有選擇單條執(zhí)行，這個時候為了排查問題，所以我改成了單條數(shù)據(jù) create 方式創(chuàng)建數(shù)據(jù)。

this.Model.bulkCreate(list)

修改為：

for (const item of list) {
  this.Model.create(item)
}

結果不出意外的還是定時被刪除了，?? 然后開始懷疑是事務沒有提交的問題，雖然此邏輯是完全不需要用到事務操作，但還是抱著懷疑的心態(tài)試試看。

let transaction;
try {
  // 建立事務對象
  transaction = await this.ctx.model.transaction();
  for (const item of list) {
    // 事務增操作
    await this.Model.create(item, {
        transaction,
    });
    // 提交事務
    await transaction.commit();
  }
} catch (err) {
    // 事務回滾
    await transaction.rollback();
}

結果不出意外的還是定時被刪除了，??????此時已經(jīng)沒有改動的余地了，此時的天都已經(jīng)黑了，可是問題還沒解決，只能繼續(xù)面向百度編程了，此時搜索到也有同一個人遇到這樣的問題，他的解決方案是修改表名稱，這時候也只能死馬當作活馬醫(yī)了。

結果出意外的恢復正常寫入以及更新了。

為什么更改了表名稱后就正常呢，思來想去也想不出為什么。結果今天在重新部署服務的時候看了一眼歷史部署記錄，發(fā)現(xiàn)了端倪。就在假期的最后一天晚上有一個部署記錄，然后我回看了和最開始發(fā)生數(shù)據(jù)異常的時間段相差無幾?；揪涂梢詳喽ê痛舜尾渴鹩泻艽蟮年P系，由于公司內(nèi)部的部署方案有docker和虛擬機兩種方式，導致每個時間段都會有兩個定時任務同時執(zhí)行，由于數(shù)據(jù)處理的過程中需要查詢第三方數(shù)據(jù)，最后兩邊寫入的時間會存在一定的延時，導致寫好的數(shù)據(jù)被另一邊執(zhí)行了刪除的邏輯，由于那臺服務器一直未更新修改的代碼，一直執(zhí)行的是最開始那份先刪除再更新的邏輯。至于為啥執(zhí)行了刪除但是沒有更新，猜想是刪除后更新的邏輯出錯了。這也是為什么修改了表名稱后就正常了，因為那臺服務器上面還是舊的代碼，新增刪除不能讀到之前的那張表了，問題到此終于是告一段落了。

總結

到此是否感覺看了一個大烏龍事件，最終的原因和代碼沒有任何關系，但是卻三番五次的改動無果。在排查過程中還有很多沒有寫的，比如懷疑重復數(shù)據(jù)導致所以增加唯一索引，懷疑自增ID多大重新清零，但是這個改動的過程中也學到了不少新的知識，如何使用事務，新增唯一索引，修改表名稱，重置自增ID等很多服務端相關的知識。最后的總結是遇到問題先不要質(zhì)疑代碼，從系統(tǒng)層面，運行版本，環(huán)境變量，運維等方面也要有一定的思考

到此這篇關于Mysql寫入數(shù)據(jù)十幾秒后被自動刪除了如何解決的文章就介紹到這了,更多相關Mysql數(shù)據(jù)自動刪除內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論