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

2022-09-25 10:48:14 字數 1005 閱讀 5517

問題:mysql某個表自增id溢位導致某業務block

背景:tokudb引擎的乙個大表tb1,存放業務上的機審日誌,每天有大量的寫入, 並且由於歷史原因,這張表是int si程式設計客棧gned 型別的,最大只能存 2147483647行記錄 。

處理過程:

增加dble中介軟體**,然後做分割槽,將新資料寫到新加的的乙個分片上。 同時業務上修改連線將這個表tb1的連線方式改走dble。 但是業務上改完**後,發現還有殘餘的部分insert into tb1的寫請求被**到了老的表上,且有些表被錯誤得路由到了dble上。 這加劇了事情的複雜度。最終業務上將這個寫tb1的**下線後,整個業務才恢復正常。

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

use logdb;

select max(id) from tb1; -- 記錄下當前最大的id為 ***x

create table tb2 like tb1; -- 建立影子表

alter table tb2 modify column id bigint unsign程式設計客棧ed not null auto_increment ; -- 修改新錶為bigint unsigned型別,能存 18446744073709551615 行資料。

alter table tb2 auto_increment=***x+1; -- 改大新錶的自增主鍵起始值

rename table tb1 to tb_archive程式設計客棧 , tb2 to tb1; -- 切換表名

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

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

後續優化措施:

增加對自增id的監控, 見這裡

mysql 實現id自增序列 mysql自增id列

如果希望在每次插入新記錄時,自動地建立主鍵欄位的值。可以在表中建立乙個 auto increment 字段。mysql 使用 auto increment 關鍵字來執行 auto increment 任務。預設地auto increment 的開始值是 1,每條新記錄遞增 1。主鍵又稱主關鍵字,主關...

mysql重置所有表自增id

建立儲存過程之前需判斷該儲存過程是否已存在,若存在則刪除 drop procedure ifexists init sql string 建立儲存過程 create procedure init sql string begin 定義變數 declare s int default0 declare...

mysql自增id重置

參考 使用truncate truncate table 說明 使用truncate會刪除表的資料釋放空間,並且重置字自增id,但不會刪除表的定義。用處 需要清空表的時候才能使用。使用修改標識 dbcc checkident table name reseed,new reseed value 說明...