問題：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分鐘左右即可恢復業務的寫入操作，剩餘的遷移資料的影響相對會小一些。

後續優化措施：

增加對自增id的監控， 見這裡 https://www.jb51.net/article/184935.htm

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

到此這篇關於MySQL表自增id溢位的故障覆盤解決的文章就介紹到這了,更多相關MySQL自增id溢位內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！