Пытаюсь настроить репликацию Mongo, но в итоге получим два вторичных члена, но не первичных - PullRequest
3 голосов
/ 14 января 2012

Я пытался настроить простую систему репликации. 1 основное монго, 1 резервная копия и 1 арбитр.

К сожалению, его запуск приводит к тому, что главный избирается вторым, и резервная копия выбирается ПЕРВИЧНОЙ (хороший арбитр работы).

Main имел приоритет 100, а резервное копирование с приоритетом 0 вместе с задержка ведомого.

Я пытался сказать резервной копии, чтобы она пошла вниз:

PRIMARY>   db.runCommand({replSetReconfig: conf})
{
        "assertion" : "initiation and reconfiguration of a replica set must
be sent to a node that can become primary",
        "assertionCode" : 13420,
        "errmsg" : "db assertion failure",
        "ok" : 0
}
PRIMARY> .adminCommand({replSetStepDown:1000000, force:1})
Fri Jan 13 17:27:29 SyntaxError: syntax error (shell):1
PRIMARY> db.adminCommand({replSetStepDown:1000000, force:1})
Fri Jan 13 17:27:36 DBClientCursor::init call() failed
Fri Jan 13 17:27:36 query failed : admin.$cmd { replSetStepDown:
1000000.0, force: 1.0 } to: 127.0.0.1
Fri Jan 13 17:27:36 Error: error doing query: failed shell/
collection.js:151
Fri Jan 13 17:27:36 trying reconnect to 127.0.0.1
Fri Jan 13 17:27:36 reconnect 127.0.0.1 ok
SECONDARY>
SECONDARY>
SECONDARY> db.adminCommand({replSetStepDown:1000000, force:1})
{ "errmsg" : "not primary so can't step down", "ok" : 0 }

Что сработало, но главное еще и второй день.

Есть идеи? Спасибо!

файл конфигурации

conf = {
  version: 90002,
  _id : "example",
  members: [
    {
      _id : 1,
      host : "main.example.com:27017",
      priority: 100
    },
    {
      _id : 2,
      host : "backup.example.com:27017",
      priority: 0,
      slaveDelay : 3600
    },
    {
      _id : 3,
      host : "arbiter.example.com:27017",
      priority: 0,
      arbiterOnly: true
    }
  ]
};

rs.status на главной ()

{
  "set" : "example",
  "date" : ISODate("2012-01-13T23:29:09Z"),
  "myState" : 2,
  "members" : [
    {
      "_id" : 1,
      "name" : "main.example.com:27017",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "optime" : {
        "t" : 1326496827000,
        "i" : 1
      },
      "optimeDate" : ISODate("2012-01-13T23:20:27Z"),
      "self" : true
    },
    {
      "_id" : 2,
      "name" : "backup.example.com:27017",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "uptime" : 324,
      "optime" : {
        "t" : 1326492641000,
        "i" : 1
      },
      "optimeDate" : ISODate("2012-01-13T22:10:41Z"),
      "lastHeartbeat" : ISODate("2012-01-13T23:29:09Z"),
      "pingMs" : 0
    },
    {
      "_id" : 3,
      "name" : "arbiter.example.com:27017",
      "health" : 1,
      "state" : 7,
      "stateStr" : "ARBITER",
      "uptime" : 324,
      "optime" : {
        "t" : 0,
        "i" : 0
      },
      "optimeDate" : ISODate("1970-01-01T00:00:00Z"),
      "lastHeartbeat" : ISODate("2012-01-13T23:29:09Z"),
      "pingMs" : 0
    }
  ],
  "ok" : 1

}

rs.status () при резервном копировании

{
  "set" : "example",
  "date" : ISODate("2012-01-13T23:31:06Z"),
  "myState" : 2,
  "members" : [
    {
      "_id" : 0,
      "name" : "BACKUPVMW02:27017",
      "health" : 1,
      "state" : 2,
      "stateStr" : "SECONDARY",
      "optime" : {
        "t" : 1326492641000,
        "i" : 1
      },
      "optimeDate" : ISODate("2012-01-13T22:10:41Z"),
      "self" : true
    }
  ],
  "ok" : 1

Ответы [ 2 ]

1 голос
/ 15 февраля 2012

вы можете использовать старую версию mongodb - поле, которое они использовали для голосования, называлось «голоса», тогда, я думаю, не приоритетным.Когда они переключились на поле «приоритет», я думаю, вы должны вызывать rs.reconfig (configfile).

1 голос
/ 14 января 2012

Оказывается, у вас есть 3 узла, с 1 основным, 1 подчиненным и 1 арбитром, который не работает должным образом. Устранена задержка ведомого, и приоритет был соблюден (после переустановки всех узлов с нуля и удаления каталогов данных)

...