以前、同じdbフォルダーでレプリカセットのデモを試しました。レプリカセット名は "test"です。次に、別の名前「repl」でreplセットを再構築しようとしました。再構成した後、以下のエラーメッセージが表示されます。
{
"ok" : 0,
"errmsg" : "replSetReconfig should only be run on PRIMARY, but my state is REMOVED; use the \"force\" argument to override",
"code" : 10107,
"codeName" : "NotMaster"
}
だから私はerrmsgに従い、以下のコマンドを実行してみます:
rs.reconfig(config,{"force":true})
今、私は次のエラーメッセージを受け取ります:
{
"ok" : 0,
"errmsg" : "New and old configurations differ in replica set name; old was test, and new is repl",
"code" : 103,
"codeName" : "NewReplicaSetConfigurationIncompatible"
}
残念な!したがって、私は以前の名前「test」を使用しています。しかし、再びエラーが発生します。
{
"ok" : 0,
"errmsg" : "New and old configurations differ in the setting of the arbiterOnly field for member 127.0.0.1:27020
; to make this change, remove then re-add the member",
"code" : 103,
"codeName" : "NewReplicaSetConfigurationIncompatible"
}
私は本当に理解していません、すべての構成情報が前のものと一貫している必要がある場合、なぜそれを再構成する必要があるのですか?
ローカルデータベースを削除できると誰かが言ったが、この操作はまだ機能しない。
{
"ok" : 0,
"errmsg" : "Cannot drop 'local' database while replication is active",
"code" : 20,
"codeName" : "IllegalOperation"
}
ああ、MGD!現在のdbフォルダーでreplsetを再起動することがなぜそれほど難しいのか理解できませんでした。
MongoDB BOLに従って ここ 既存のレプリカセットを再構成して、既存のレプリカセット構成を上書きします。メソッドを実行するには、レプリカセットの primary に接続する必要があります。
_rs.reconfig(configuration, force)
_
既存のレプリカセットを再構成するには、最初にrs.conf()
で現在の構成を取得し、必要に応じて構成ドキュメントを変更してから、変更したドキュメントを rs.reconfig() に渡します。
rs.reconfig()は replSetReconfig コマンドのラッパーを提供します。
Forceパラメーターを使用すると、再構成コマンドを非プライマリノードに発行できます。
警告:MongoDBのバージョン間で検証ルールが異なる可能性があるため、異なるMongoDBバージョンのメンバーを含むレプリカセットを再構成しないでください。
rs.reconfig()
Shellメソッドは、現在のプライマリをトリガーして、状況によってはステップダウンすることができます。プライマリが停止すると、すべてのクライアント接続が強制的に閉じられます。これは仕様によるものです。新しいプライマリの選択には時間がかかる場合があるため、メンテナンス期間中に再構成の変更をスケジュールして、書き込みの可用性の損失を最小限に抑えます。
_{ force: true }
_
警告:{force:true}でrs.reconfig()を使用すると、コミットされた書き込みがロールバックされる可能性があります。このオプションを使用するときは注意してください。
メンバーの優先順位と投票_MongoDB version 3.2
_で変更されました。
優先度が_0
_より大きいメンバーは_0 votes
_を持つことができません。
_Non-voting
_メンバーは_0
_の優先度を持つ必要があります。
たとえば、rs0という名前のレプリカセットには次の構成があります。
_{
"_id" : "rs0",
"version" : 1,
"protocolVersion" : NumberLong(1),
"members" : [
{
"_id" : 0,
"Host" : "mongodb0.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"Host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"Host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
],
"settings" : {
"chainingAllowed" : true,
"heartbeatIntervalMillis" : 2000,
"heartbeatTimeoutSecs" : 10,
"electionTimeoutMillis" : 10000,
"catchUpTimeoutMillis" : 2000,
"getLastErrorModes" : {
},
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
}
}
_
次の一連の操作は、2番目のメンバーの members [n] .priority を更新します。操作は、プライマリに接続された mongo Shellを介して発行されます。
_cfg = rs.conf();
cfg.members[1].priority = 2;
rs.reconfig(cfg);
_
上記のステートメントなどで動作します
最初のステートメントは、rs.conf()メソッドを使用して、レプリカセットの現在の構成を含むドキュメントを取得し、そのドキュメントをローカル変数cfgに設定します。
2番目のステートメントは、_members[n].priority
_値をメンバー配列の2番目のドキュメントに設定します。追加設定については、レプリカセットの構成設定を参照してください。
_To access the member configuration document in the array, the
statement uses the array index and not the replica set member’s
`members[n]._id` field.
_
最後のステートメントは、変更されたcfgを使用してrs.reconfig()
メソッドを呼び出し、この新しい構成を初期化します。再構成が成功すると、レプリカセットの構成は次のようになります。
{"_id": "rs0"、 "version":2、 "protocolVersion":NumberLong(1)、 "members":[{"_id":0、 "Host": "mongodb0.example.net:27017"、 「arbiterOnly」:false、「buildIndexes」:true、「hidden」:false、「priority」:1、「tags」:{
_ },
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 1,
"Host" : "mongodb1.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 2,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
},
{
"_id" : 2,
"Host" : "mongodb2.example.net:27017",
"arbiterOnly" : false,
"buildIndexes" : true,
"hidden" : false,
"priority" : 1,
"tags" : {
},
"slaveDelay" : NumberLong(0),
"votes" : 1
}
_
]、 "settings":{"chainingAllowed":true、 "heartbeatIntervalMillis":2000、 "heartbeatTimeoutSecs":10、 "electionTimeoutMillis":10000、 "catchUpTimeoutMillis":2000、 "getLastErrorModes":{
_ },
"getLastErrorDefaults" : {
"w" : 1,
"wtimeout" : 0
},
"replicaSetId" : ObjectId("58858acc1f5609ed986b641b")
_
}}
注:レプリカ構成オブジェクトを更新するときは、メンバーアレイのレプリカセットメンバーに配列インデックスを使用してアクセスします。配列インデックスは0から始まります。このインデックス値を、メンバー配列の各ドキュメントの_
members[n]._id
_フィールドの値と混同しないでください。
ヘルプとして、mongo
Shell rs.help()
と入力できます。
_> rs.help()
rs.status() { replSetGetStatus : 1 } checks repl set status
rs.initiate() { replSetInitiate : null } initiates set with default settings
rs.initiate(cfg) { replSetInitiate : cfg } initiates set with configuration cfg
rs.conf() get the current configuration object from local.system.replset
rs.reconfig(cfg) updates the configuration of a running replica set with cfg (disconnects)
rs.add(hostportstr) add a new member to the set with default attributes (disconnects)
rs.add(membercfgobj) add a new member to the set with extra attributes (disconnects)
rs.addArb(hostportstr) add a new member which is arbiterOnly:true (disconnects)
rs.stepDown([stepdownSecs, catchUpSecs]) step down as primary (disconnects)
rs.syncFrom(hostportstr) make a secondary sync from the given member
rs.freeze(secs) make a node ineligible to become primary for the time specified
rs.remove(hostportstr) remove a Host from the replica set (disconnects)
rs.slaveOk() allow queries on secondary nodes
rs.printReplicationInfo() check oplog size and time range
rs.printSlaveReplicationInfo() check replica set members and replication lag
db.isMaster() check who is primary
reconfiguration helpers disconnect from the database so the Shell will display
an error, even if the command succeeds.
_
最初にすべてのレプリカ構成を削除する必要があると思います。したがって、基本的には--replSet
なしでインスタンスを起動する必要があります。次に、db.system.replset
コレクションに移動して、対応するIDを削除します。次に、レプリカインスタンスを再起動します。