MySQL テーブル自動増分 ID オーバーフロー障害レビューソリューション

問題: MySQLテーブル内の自動増分IDのオーバーフローによりビジネスブロックが発生した

背景：

tokudb エンジンの大きなテーブル tb1 には、ビジネスマシンの監査ログが格納されます。毎日大量のデータが書き込まれます。歴史的な理由により、このテーブルは int 符号付き型であり、最大 2147483647 行を格納できます。

処理プロセス:

DBLE ミドルウェアエージェントを追加し、範囲パーティション分割を実行し、新しく追加されたシャードに新しいデータを書き込みます。同時に、ビジネスは接続を変更し、このテーブル tb1 の接続モードを DBLE に変更しました。しかし、ビジネスコードが変更された後、残りの tb1 への挿入書き込み要求の一部が古いテーブルに転送され、一部のテーブルが誤って DBLE にルーティングされていることが判明しました。これにより事態はさらに複雑になります。最終的に、tb1 を書き込んだコードがオフラインになった後、ビジネス全体が正常に戻りました。

状況を検討した結果、この場合、ログテーブルの問題については、DBA が迅速かつ断固たる措置を講じてできるだけ早く業務を復旧し、その後に他の問題を検討する必要があると考えました。このように考えれば、上記の問題は簡単に解決できます。ほんの数ステップです:

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; -- 新しいテーブルを、18446744073709551615 行のデータを格納できる bigint unsigned タイプに変更します。
alter table tb2 auto_increment=xxxx+1; -- 新しいテーブルの自動増分主キーの開始値を変更します。 rename table tb1 to tb_archive , tb2 to tb1; -- テーブル名を切り替えます。

この操作の後、データを tb1 に書き込むことができ、業務を一時的に回復できます。残りの作業は、tb_archive テーブルのデータを tb1 に移行することです (pt-archiver ツールを使用してデータを移行し、バックグラウンドでゆっくりと実行できます)。

計算してみると、テーブルを切り取って業務書き込み操作を再開するのに最大で約 5 分しかかからず、移行された残りのデータへの影響は比較的小さくなります。

その後の最適化対策:

自動増分 ID の監視を追加します。こちらを参照してください https://www.jb51.net/article/184935.htm

生産中に発生する可能性のある予期しない問題を整理し、それに応じて適切な緊急計画を策定します。

これで、MySQL テーブルの自動インクリメント ID オーバーフローのトラブルシューティングと解決法に関するこの記事は終了です。MySQL の自動インクリメント ID オーバーフローに関するその他の関連コンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: