MongoDBのShard Key設計を失敗したため、そのリカバリにたいへん手間取ったメモ

年末年始の休暇を挟み、MongoDBサーバのディスクが溢れそうになっていたので、 「そろそろShard増やすか」と思ったら、思いの外うまいこといかなかったのでメモ。

【今回のトラブル】 AWS上にある、約1TBのMongoDBサーバ(m2.4xlarge×3台/Shard6個)のディスク容量が残り10%を切ったので、 新しいMongoDBサーバ(m2.4xlarge×3台/Shard6個)を追加しようとしたけど、データが全く移動できなくなった。

【現象】

新しく追加したShardへ、既存データが入っているChunkを移動さえしようとするも失敗

「おや？」と思い、chunksizeを “estimatedChunkSize”以上に変更。

Configとmongosを立ち上げ直して、moveChunkを実行したが途中で失敗

どうにもこうにもChunkが動かないので、Chunkの分割を試みる。

…….やっぱ駄目。＼(^o^)／ｵﾜﾀ

【原因】 MongoDBを触っている勘のいい方なら、ログの時点でわかりそうですが、 今回のShard Keyの設定は、「hourint」つまり、時刻フィールドでShard Keyを設定し、24個のShardで運用しようと試みてしまっていました。

【参考】 昨年の発表資料

そのため、

a.ドキュメントが時刻フィールドで偏る（日中のドキュメントが多い）

b.MongoDBがChunkを分割しようにも、Chunkを分割できない

1Chunkの中には、ある特定時間帯のドキュメントしかないので、Chunkをsplitできない

【結論】 今回のようなChunkが肥大化してしまう事例は、MongoDBのShardKeyを複合Keyで設定していれば回避できた事例でした。 そのため、「”app”,”userid”,”dateint”,”hourint”」の複合ShardKeyで、コレクションを再作成することにしました。 私の場合、コレクションのIndexは複合Keyで運用していたのですが、 ShardKeyも複合Keyで設定できることを知らなかったのが敗因でした(´Д｀) ということで、mongosからmongodumpを実行し、新年からコレクションの再作成を行うというリカバリを行うハメになりました。 しかも、mongos経由でバックアップを行っても、1MBpsecしか出ないので、ほぼ1週間ダンプ待ちの状態になりました。

MongoDBのShard Keyを設定する際は、Chunkが肥大化しないような設計を心がけましょう!!