レプリカセットを作成しましたが、問題はレプリカセットの2つのメンバー[3つのメンバーセット]が48時間から回復モードになっていることです。最初は回復するノードのサイズが増加していましたが、今ではそれも停止しています。そのため、ノードのリカバリでは、90 GBのデータと60+ GBのローカルデータの後にスタックします。
このモードから抜ける方法は?
dbpath
セカンダリがリカバリ状態に入った理由は不明なので、これは少し安全ではありません。
上記と同じですが、プロセス中にアプリケーションを停止します。これにより、アプリケーションがセカンダリが複製できるよりも多くのデータを挿入する可能性がなくなります。ただし、生産中に問題が発生する可能性があります。
dbpath
のコンテンツを削除しますdbpath
の内容を両方のセカンダリのdbpath
にコピーしますいくつかの注意事項:
[〜#〜] mms [〜#〜] を使用します。これは無料で、簡単にセットアップでき、レプリカセットに関する優れた情報を提供します。 「レプリケーションラグ」の値を0付近に保つようにして、レプリケーションラグが「レプリケーションoplogウィンドウ」より大きくならないようにするために必要なすべての手段を講じてください。
常に1GbネットワークとRAMの(申し訳ありません)シットロードがあることを確認してください。多いほど良い。追加の経験則:RAMおよびSSDの半分よりもRAMでSSDなし(RAM合理的な制限)。
免責事項:常に本番環境のバックアップを作成しますそれをいじる前のデータ。
セカンダリの新しい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"})
必要なサイズの新しいoplogを作成します(50 GBなど)
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().maxSize
oplogサイズを10 GBに変更するには
db.adminCommand({replSetResizeOplog: 1, size: 10000})