MySQLテーブルに52GBの断片化が蓄積すると、ディスク警告が迅速な判断を迫ります。魅力的な近道はTRUNCATEですが、稼働中のビジネステーブルでは即座にデータ損失を意味します。このインシデントレポートでは、まずinformation_schemaで断片化を確認し、その後ALTER TABLE ... ENGINE=InnoDBやpt-online-schema-changeを使用して書き込みをブロックせずにテーブルを再構築する、より安全な方法を紹介しています。著者はまた、操作前にテーブルサイズ、行数、レプリケーション遅延を確認することの重要性を強調しています。本番でMySQLを運用するチームにとって、これは文書化されたランブックに値する典型的なシナリオです。重要なのは特定のコマンドではなく、失っても構わないテーブルをTRUNCATEしない、常にロールバック計画を持つ、ステージングコピーで再構築をテストするという意思決定フレームワークです。
本番MySQLテーブルに52GBの断片化が蓄積し、ディスク80%警告が発生。著者は危うくTRUNCATEを実行しそうになったが、リスクに気づき安全な代替手段を紹介しています。