問題タブ [mongodb-oplog]

さまざまなmongoURIを含む構成ファイルを読み込んでループし、mongo-oplogを使用してそれらのアクティビティを監視しようとしています。これらすべてのデータベースのリスナー (更新、挿入、削除など) を動的に設定する方法がよくわかりません。どうすればそうすることができるかについてのアイデアはありますか？

Meteor で oplog テーリングを使用する利点は何ですか? 私はこれらを知っています：

• レプリカ セットがあると、高可用性が保証されます
• Oplog テーリングは、DB の変更を検出してクライアントにプッシュする際のパフォーマンスを向上させます。

より具体的には、「リアルタイム」の側面がそれほど重要ではない Meteor アプリを考えると (つまり、セッション中にクライアントがデータの変更を見る可能性が高いほど書き込みが集中しない)、レプリカ セットを持つことの可用性の利点も無視されます。 、oplogテーリングを使用することの他の利点はありますか?

mongodbの更新時に、socket.ioを介してイベントをブラウザにプッシュする既存の作業ノード+ mongodb + oplogアプリケーションがあります。構成は現在次のようになっています。

私は最近、プライマリ データベース マシンと 1 つのセカンダリ データベース マシンがある実際のレプリカ セットを使い始めました。マルチノード レプリカセットへの変更に対応するには、ノード アプリケーションの MongoOplog の構成をどのように変更すればよいですか?

Tim Oxley の例 ( https://gist.github.com/timoxley/1502645 )と同様に、Mongoose で oplog を使用します。
新しく挿入されたドキュメント (oplog 'i' 操作) を Mongoose ドキュメントに変換する効率的な方法を探しています。
私はこれを試しました:
var my_model = mongoose.model('test_doc', my_schema);
// ...
関数 oplog_receiver(op, doc) {
if( op === 'i' ) {
doc = new my_model(doc);
doc.isNew = false;
}
// ...
doc.modified_at = new Date();
doc.save(エラー => {});
}

それはうまくいきました。
これは行く方法ですか、それともこれを行うより良い方法はありますか?

どうもありがとう、
ローマ

セカンダリ データベースの構成ファイルでは、99 GB の oplog サイズを定義しました (oplogSizeMB: 99000) が、数時間後には既に 120 GB を超えるサイズに遭遇しています (1 つのファイルは 74 GB で、2 つ目のファイルは 65 GB です)。

これはバージョン 3.4.0 のバグですか? mongodb バージョン 3.2.1 では、この問題は発生しませんでした。それとも、oplog の振る舞いについて何か誤解しているのでしょうか?

SUSE Linux Enterprise Server 11 (x86_64) で mongodb を実行しています。