MySQL表自增id溢出的故障復盤如何解決？本篇文章小編給大家分享一下MySQL表自增id溢出的故障復盤解決方法，小編覺得挺不錯的，現在分享給大家供大家參考，有需要的小伙伴們可以來看看。

問題：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 溢出_MySQL表自增id溢出的故障复盘怎么解决 MySQL表自增id溢出的故障复盘解决方法...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。