デリバティブ偏愛家の日記

弱小投資家の相場備忘録

MySQL DBの空き容量が枯渇して嵌った話

よくよく考えるまでもなく、インフラ担当者でもなかったのにDB管理をしていたら嵌った素人の話。

※金で解決した、というオチなので参考になる可能性は低いですが、似たような失態を犯さないように、という程度の参考にはなるかもしれません。

 

事の発端

元々AWSAmazon Web Services)の契約をしており、そこでRDS(Relational Database Service)を利用し、MySQLのDBを立てていた。そこには日々バッチで回収しているマーケットデータや、様々なソースから入手した過去のマーケットデータを入れている。

aws.amazon.com

東証上場全銘柄の株価5分足はある程度ダウンロードしていたが、直近使う予定も無かったので、手が空いたタイミングでPythonを使って投入している。SQLサーバーや作業を行う仮想サーバーのスペックが低いために時間がかかるので、たまに進捗を見る、という感じである。

 

昨日もせっせと投入していたら遂に恐れていた事態が起きてしまった。

 

「strage full」

 

ここで来たかー!!!!!という感じではあるが、容量のチェックを完全に忘れていたのでまずその時点でDB管理としては終わっている。

 

原因

確かに為替の1分足を15年分投入したりと無茶はしていたが、それでも設計や運用に問題があったと言わざるを得ない。

未使用のカラムが多過ぎる

最終的には板情報まで組み込むことを考えて設計したので、上下10本分のBid/Askが入れられるようになっているが、現状全く使っていない(仮に入れると光速で枯渇するという話もある)。

使う宛も無いのにとりあえず入れたデータが多過ぎる

YJFXのバイナリーオプションは価格データを15分毎にメールで送ってくれるのだが、それをXMLにして全てDBに突っ込んだは良いが、全く取引していないし、今後も特に予定は無い(スプレッドがやけに広い)。そんなデータが大量に入っているのは無駄であろう。

残容量をチェックする習慣が無い

一時期、上に書いた膨大な為替データを入れたことでDBの残容量が2割を切ったのに、特にチェックせずに日々のデータを入れていたら枯渇した。お粗末な話である。

 

事後対応

こうなってしまっては、明日以降の取引が困難になるので(裁量取引はしていないので、DBのデータが無いと投資判断は都度手計算する必要がある。それは流石に発狂する)、早急に対応が必要となった。

データ削除で容量確保を試みる

素人が思いつく方法である。確かに使用予定が当分無いであろうデータがそこそこあったので、それをせっせと消していった。

これは完全に備忘録だが、消し方にも二種類ある。

  • Delete:データの全削除、一部削除が可能だが、遅い
  • Truncate:データの全削除のみ可能だが、速い

ただ、条件を指定して消すのにもある程度容量が必要で、ほぼ容量0となっていた状態では八方塞がりとなり、数千件ずつ簡単なクエリで手で消していく作業を続けた。

 

…色々消したがなかなかDBの空き容量は増えない。データの行数は既に4,000,000程削ったのに…

 

ふとGoogle先生に尋ねてみると、恐ろしい回答が返ってきた。

 

「InnnoDBはデータ削除をしても容量は戻りません。それでも削減したい場合はコピーして別のテーブルを作成しましょう。」

 

f:id:plnjpy:20171005030833j:plain

(筆者近影)

 

何とも無慈悲な話である。当初、現状の1/10程のデータ量だったDBをローカルで作成し、AWSに移行するだけで凄まじい手間だったのに(完全に"安い料金プランを選んでいる"ためであり、AWS側の問題ではない)、これが10倍となると想像したくもない。真面目な話、移行中はそれ以外に取引も暫く中断することになるし、日々のバッチ処理を止めたり何なりしないといけない。

 

過去のある時点までDBをロールバックする案を検討する

一応RDSのサービスに含まれており、不可能では無いが、全く根本的な解決ではないし、直近のデータが抜けるので、それをどうにか取ってくる必要がある。数週間の延命では意味が無い…

 

光明を見出す

万事休すかと思われたが、RDSの画面をポチポチ弄っていたら、天から垂れる蜘蛛の糸が視界に入った。

 

「ストレージ容量」と書かれたボックスの横に上下の矢印があるではないか。

 

…いやまさかそんな簡単に増やせるヌルゲーではないでしょう

 

上矢印をクリックしてみる。

 

確かにボックス内の数字は大きくなっていく。適当に1.5倍にしてみる。

 

…どうせこんな数字、反映ボタンを押すと「お客様が使用されているDBの種類ではストレージ容量を変更することはできません」だの何だのエラーが出て終了するんだろう?

 

反映ボタンを押してみる。

 

DBのステータスが「modify」に変わった。

 

…何か上手くいってそうだけど、どうせ低料金DBだからmodifyに異様に時間がかかって気付けば自分で別途入れ直した方が早い、というような悲劇的な結末なんだろう?

 

待つこと3分。

 

……あっさりと容量は当初の1.5倍に増えた。

 

一瞬で金で解決できてしまった。ヌルゲーではないか。あの阿鼻叫喚した4時間は何だったのか…元々月に$15程度しか料金は発生していないが、これがどうなるのかが多少の不安要素だが、流石にとんでもない金額にはならないだろう(なっていたらまた記事になる)。

 

という訳でジェフ・ベゾスに全く頭が上がらないまま、一件落着となった。トレーダー諸氏はとても便利なRDSの使用を検討してみてはどうか。

(再掲)

aws.amazon.com