回答:
dbpathセカンダリが回復状態に入った理由は不明であるため、これは少し安全ではありません。
上記と同じですが、プロセス中はアプリケーションを停止します。これにより、アプリケーションがセカンダリが複製できるよりも多くのデータを挿入する可能性を防ぎます。ただし、問題は生産中に発生する可能性があります。
dbpathの両方のセカンダリをdbpathを両方のセカンダリにコピーしますdbpathいくつかのメモ：
MMSを使用します。無料で、セットアップが簡単で、レプリカセットに関する適切な情報を提供します。「レプリケーションラグ」の値を0付近に維持し、レプリケーションラグが「レプリケーションoplogウィンドウ」より大きくならないようにするために必要なすべての手段を講じるようにしてください。
常に1Gbネットワークと（ごめん）大量のRAMがあることを確認してください。より多くの、より良い。追加の経験則：RAMとSSDの2倍よりもむしろRAMとSSDの半分を使用し、SSDを使用しない（RAMは妥当な制限内に収まる）。
免責事項： 本番データをいじる前に、常に本番データのバックアップを作成してください。
レプリケーション・プロセスは、あなたが事がいくつか作ることですsecondary.Soに新しいDBPATHからスクラッチを起動しても失敗しoplogの変化を。oplogのサイズは、アプリケーションへのすべての書き込みを処理できるように最適な値に設定する必要があります。
oplogサイズの増加：
プライマリサーバーをシャットダウンする
use admin
db.shutdownServer()スタンドアロンとしてプライマリを起動し、異なるポートで実行します37017
ポート37017でmongoにログインします
mongo --port 37017ローカルデータベースの古いコンテンツを削除する
安全のために、削除する前に古いoplogのbackopを用意してください
mongodump --db local --collection 'oplog.rs' --port 37017ローカルデータベースに古いコンテンツをドロップします
use local
db.oplog.rs.drop()
db.me.drop()
db.replset.election.drop()
db.replset.minvalid.drop()
db.startup_log.drop()Replsetコレクションは削除できないため、必要なIDで削除します。
db.system.replset.remove({ "_id" : "your_replsetname"})必要なサイズ、たとえば50 GBの新しいoplogを作成します
db.runCommand( { create: "oplog.rs", capped: true, size: (50 * 1024 * 1024 * 1024) } )また、mongod.confファイルでoplogサイズをMB単位で指定できます。たとえば、50 GBの場合は429496 MBです
replication:
oplogSizeMB: 429496お役に立てれば ！！！
編集：
Nicholas Tolley Cottrellがコメントで述べたように。MongoDB バージョン3.6では、再起動せずに実行時にoplogサイズを変更できます。
現在のoplogサイズを確認する
use local
db.oplog.rs.stats().maxSizeoplogサイズを10 GBに変更するには
db.adminCommand({replSetResizeOplog: 1, size: 10000})