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分鐘左右便可恢復業務的寫入操做，剩餘的遷移數據的影響相對會小一些。

後續優化措施：

    增長對自增id的監控， 見這裏 http://www.javashuo.com/article/p-frobolct-eq.html

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