歡迎您光臨本站 註冊首頁

MySQL表自增id溢出的故障覆盤解決

←手機掃碼閱讀     火星人 @ 2020-04-27 , reply:0


問題:MySQL某個表自增id溢出導致某業務block

背景:

tokudb引擎的一個大表tb1,存放業務上的機審日誌,每天有大量的寫入, 並且由於歷史原因,這張表是int signed 類型的,最大隻能存 2147483647行記錄 。

處理過程:

增加DBLE中間件代理,然後做range分區,將新數據寫到新加的的一個分片上。 同時業務上修改連接將這個表tb1的連接方式改走DBLE。 但是業務上改完代碼後,發現還有殘餘的部分insert into tb1的寫請求被轉發到了老的表上,且有些表被錯誤得路由到了DBLE上。 這加劇了事情的複雜度。最終業務上將這個寫tb1的代碼下線後,整個業務才恢復正常。

後來覆盤後,我想了下其實這種情況下,對於日誌類的表的問題,DBA應該採用迅速果斷的措施 儘快恢復業務,然後再考慮其它問題。 這樣考慮的話,上面的問題就好解決了。 只需要下面幾步:

use logdb; select max(id) from tb1; -- 記錄下當前最大的id為 xxxx create table tb2 LIKE tb1; -- 創建影子表 alter table tb2 modify column id bigint unsigned not null auto_increment ; -- 修改新表為bigint unsigned類型,能存 18446744073709551615 行數據。 alter table tb2 auto_increment=xxxx+1; -- 改大新表的自增主鍵起始值 rename table tb1 to tb_archive , tb2 to tb1; -- 切換表名

這樣操作後,tb1就可以寫入數據了,業務也能暫時恢復,剩下的工作就是把 tb_archive 表的數據遷移到 tb1 裡面的(遷移數據可以使用pt-archiver工具在後臺慢慢跑就行)。

算了下,整個操作中切表最多5分鐘左右即可恢復業務的寫入操作,剩餘的遷移數據的影響相對會小一些。

後續優化措施:


整理些生產上可能遇到的突發問題,並正對性的制定相關的應急預案



[火星人 ] MySQL表自增id溢出的故障覆盤解決已經有145次圍觀

http://coctec.com/docs/mysql/show-post-231767.html