MySQLテーブル自増idオーバーフローのフェイルオーバディスク

質問:MySQLのあるテーブルの増加idオーバーフローによるビジネスblock
背景:
tokudbエンジンの大きなテーブルtb 1は、ビジネス上のレビューログを格納し、毎日大量の書き込みがあり、履歴上、このテーブルはint signedタイプであり、最大2147483647行の記録しか保存できません.
プロセス:
DBLEミドルウェアエージェントを追加し、rangeパーティションを作成し、新しいデータを追加したスライスに書きます.同時に業務上接続を修正し、この表tb 1の接続方式をDBLEに変更する.しかし、ビジネス上でコードを変更した後、残りの部分のinsert into tb 1の書き込み要求が古いテーブルに転送され、一部のテーブルがDBLEに誤ってルーティングされていることが分かった.これは事の複雑さを激化させた.最終的に業務上このtb 1と書かれたコードをラインオフした後、業務全体が正常に戻った.
その後、再盤した後、実際にこのような場合、ログクラスのテーブルの問題に対して、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;  --     

これでtb 1はデータを書き込むことができ、業務も一時的に回復することができ、残りの仕事はtb_archiveテーブルのデータはtb 1に移行します(移行データはpt-archiverツールを使ってバックグラウンドをゆっくり走ればいいです).
計算すると、全体の操作の中で最大5分程度で業務の書き込み操作を回復することができ、残りの移行データの影響は相対的に小さい.
次の最適化対策:
自己増加idのモニタリングを追加します.ここを参照してください.https://blog.51cto.com/lee90/2427912
生産上の突発的な問題を整理し、関連する応急対策を的確に制定している.