庫：mysql5.6.19
從：mysql5.6.37
場景:昨天開發組反應從庫和主庫的資料同步有問題，在主庫中進行更新過的資料，從庫中有的沒有更新，導致他們根據觸發器變化的資料不準確。
起先接到這個問題，我把驚著了，按理說mysql從庫的版本遠遠高於主庫的，即使要出問題，也應該是早期的從庫版本出問題才對，但是另乙個版本號為5.6.19的從庫，資料一切都正常，唯獨版本為mysql5.6.37這個資料庫出問題了。
這個問題讓我百思不得其解，後來我開啟mysql5.6.37從庫的日誌，發現大量1062的錯誤資訊，類似下面這種：
detailed error: duplicate entry 'd2a03020711-0-28304342' for key 'devid';, error_code: 1062
剛開始的時候我還沒在意，因為在mysql的配置檔案中，我已經設定了忽略1032和1062這兩個錯誤，程式應該會處理好這個問題才對。
當我排查完主庫中的binlog日誌中，在從庫中未變更的每乙個對應資訊都能找到對應的update語句。
而這一部分update語句在mysql5.6.37的binlog日誌中，有時能找到，大90%都找不到，但是能在relay日誌中又到找到找到。
問題定位到此，結論已經基本搞清楚了，在relay日誌中的update語句，要麼是沒執行，要麼是執行失敗了。
所以我把解析後的update語句重新在mysql5.6.37的從庫上執行了一次。結果我發現，報的錯誤正是error日誌中所留下來的錯誤。
這個時候，我才發現原來我對跳過1062的error_code理解是有問題的，正常處理的1062，在error日誌中應該不會留下痕跡，但是如果留下痕跡，那就是說明有相應的sql沒有執行成功。
問題產生的原因：
於是我開啟主庫和從庫的表進行檢視，認真對比後，發現沒有任何問題。但是error日誌的提示，問題產生的原因在於從庫a表中使用了`devid` (`devid`,`typeid`,`userid`)唯一索引。
於是我把從庫中的表進行刪除，並重新同步了資料，然後看到的問題消失了。我以為問題就算解決完了。
但是過了一會，相同的問題又在mysql5.6.37的從庫中出現了。
但另外乙個低版本的mysql5.6.19也使用同樣的索引，那麼為何高版本mysql5.6.37這個唯一索引，在update時會有問題，而低版本的mysql在執行update時不沒有問題呢，對這個我百思不得其解。
後來我問了同事，剛才做了什麼操作，原來是在mysql5.6.37的mysql上新增了觸發器。
這才算是真正找到了問題的原因。
原來他設計的觸發器剛好就是把之前表中變更的資料記錄，全部更新到b表中，而且使用了和之前a表中一致的唯一索引devid。
於是果斷去掉b表的唯一索引，發現更新資料就正常了。
mysql安慰 mysql資料庫的一次救援
有時候加班這東西真的不可取，事情發生在凌晨1點多鐘 一台相當慢的伺服器，是別的部門借給我們用，我簡直是醉了，這尼瑪也能跑服務，我在糾結了兩個小時之後決定果斷重啟一下，反正都凌晨了應該不會影響他們的業務，至於應用服務等伺服器起來之後我再手動開啟，好決定了就這麼幹。哎真的是思維停滯了，居然就這麼重啟別人...
一次修復MySQL資料庫的經歷
實驗室伺服器的硬碟滿了，結果導致乙個線上服務的mysql資料庫的兩個錶壞了。具體症狀是desc cdb searchindex顯示 error 1017 hy000 can t find file cdb searchindex errno 2 這是要通過 etc my.cnf 或者同類的mysql...
記一次MySQL資料庫crash事件
mysql8.0資料庫最近一次不知道怎麼回事,突然啟動不了,如下提示 mysql daemon failed to start 日誌如下 網上也找了很多資料,但都處理不了 因為本人安裝資料庫習慣將安裝好的資料庫移到移到其他目錄,所以做了乙個操作,用原來的覆蓋現有的檔案 左邊是原始資料庫檔案,右邊是移...