GMOアドマーケティングのT.Kです。
先日、当社の監視システムにより、DBサーバーのディスク空き容量が20%を下回ったことが検知されました。
ニュースでとある工場がDBの保守作業でディスクの容量不足によりシステムが停止したと報じられ、他人事ではないと感じました。

概要

特定のレポートテーブルがディスク容量の40%を占めていることが明らかになりました。そのレポートテーブルのユニークキーが実際に必要とされる粒度よりも細かいことが以前から分かっており、粒度を粗くしてレコード数を減らすことで対応することにしました。

作業内容

• 新しいテーブルを作成して、元テーブルから再集計したデータをコピー
  
  • 負荷が集中しないように分割してWaitを入れながらコピーするためにスクリプトを作成
• レポート集計バッチを一部停止
• 新しいテーブルと元のテーブルを入れ替える
• 新しいユニークキーに対応したレポート集計バッチをリリースして集計を再開
• 問題がないことを確認した後に元のテーブルを削除

ディスク容量の見積もり

• データ量は最低でも3分の1に削減できるため、新しいテーブルには12%あれば足りる
• binlogのサイズも大きくなることが心配だったが、同じディスクに置かれていたDBバックアップを退避させることで余裕が生まれた

作業の進捗

• 問題が発生した際にすぐに対応できるように、スクリプトは勤務時間内のみ動かした
• コピーの進捗と使用量の増加率を見守りながら作業を進めた

今後の課題

• 空き容量が少ない状態での作業は心臓に悪いと感じた
• ユニークキーの見直しは前から要望があったが、他に優先するタスクが多かったため着手できなかった
• 今後は余裕を持って対応できるように体制を改善していく必要がある

T.K