問題:MySQL某個表自增id溢出導致某業(yè)務block
背景:
tokudb引擎的一個大表tb1,存放業(yè)務上的機審日志,每天有大量的寫入, 并且由于歷史原因,這張表是int signed 類型的,最大只能存 2147483647行記錄 。
處理過程:
增加DBLE中間件代理,然后做range分區(qū),將新數據寫到新加的的一個分片上。 同時業(yè)務上修改連接將這個表tb1的連接方式改走DBLE。 但是業(yè)務上改完代碼后,發(fā)現還有殘余的部分insert into tb1的寫請求被轉發(fā)到了老的表上,且有些表被錯誤得路由到了DBLE上。 這加劇了事情的復雜度。最終業(yè)務上將這個寫tb1的代碼下線后,整個業(yè)務才恢復正常。
后來復盤后,我想了下其實這種情況下,對于日志類的表的問題,DBA應該采用迅速果斷的措施 盡快恢復業(yè)務,然后再考慮其它問題。 這樣考慮的話,上面的問題就好解決了。 只需要下面幾步:
use logdb;
select max(id) from tb1; -- 記錄下當前最大的id為 xxxx
create table tb2 LIKE tb1; -- 創(chuàng)建影子表
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就可以寫入數據了,業(yè)務也能暫時恢復,剩下的工作就是把 tb_archive 表的數據遷移到 tb1 里面的(遷移數據可以使用pt-archiver工具在后臺慢慢跑就行)。
算了下,整個操作中切表最多5分鐘左右即可恢復業(yè)務的寫入操作,剩余的遷移數據的影響相對會小一些。
后續(xù)優(yōu)化措施:
增加對自增id的監(jiān)控, 見這里 https://www.jb51.net/article/184935.htm
整理些生產上可能遇到的突發(fā)問題,并正對性的制定相關的應急預案
到此這篇關于MySQL表自增id溢出的故障復盤解決的文章就介紹到這了,更多相關MySQL自增id溢出內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
您可能感興趣的文章:- MySQL的自增ID(主鍵) 用完了的解決方法
- 關于mysql自增id,你需要知道的
- 關于MySQL自增ID的一些小問題總結
- 關于Mysql自增id的這些你可能還不知道
- mysql自增id超大問題的排查與解決
- MySQL分表自增ID問題的解決方法
- 線上MySQL的自增id用盡怎么辦