##はじめに
これは絶対にやめよう！
備忘録的にまとめてみた。
気づいたら追加していこう。
GridFsは、Replica SetメンバーDBでは使わない
ReplicaSetに新たにDBを追加してSyncが始まった時に、GridFsのデータが足枷になり辛い思いをしたことがある。もはやs3や他のストレージがあるこのご時世、Replica Set云々ではなくて、GridFsは無用だという話かもしれない。
ログデータなど肥大するデータは、Replica SetメンバーDBに保存しない
手軽にコレクションが追加できてしまうので、やりがちかなと思う。
基本、生ログデータはどこかにバックアップを取って、集計して、閲覧可能な状態にして、更にバックアップを取っておく必要がある。
集計する過程でMongoDBを利用することはあっても、ログデータの保存にReplica SetメンバーDBを使う必要はない。
ちなみに、、集計したデータをエンドのアプリケーション側で使ったりする場合は、Replica SetメンバーDBに保存することがあっても良いと思う。
Replica SetメンバーDBのプライマリ以外のメンバーDBはバックアップサーバーとして使わない
Replica Setは、DBのレスポンスのチューニングのための手段だと理解した方が良いと思っている。
ホットデータなど、動的変化し激しく利用されるデータのバックアップはとても難しい。なので、バックアップが必須な場合、その前提で設計をした方が良い。
例えば、クリティカルデータとディスポーサルデータなどデータを区分して、クリティカルデータのみバックアップしたり、バックアップポリシーを設定して運用すると良いのかなと思っている。
まとめ
Replica Setのメンバー数にもよると思うが、同期が走るとDBが大きいとサーバーにそれなりの負荷が生じる。スケールアップとアウトのバランスは、データや帯域やトランズアクションの量を考慮しながら考える必要があり、結構難しく手探りな状態に陥りやすい。
ベストプラクティスがあれば、知りたい。
などなど、いろいろと考慮しながらReplica Setを上手く使いこなすと良いのかなと思う。