#mongodb #replication
#mongodb #репликация
Вопрос:
Я пытаюсь воспроизвести oplog из 1 набора реплик в другой в mongo. Я получаю сообщение об ошибке, есть идеи, почему?
mongooplog --from "10.0.0.180:27017" -h "my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019" -d my_db -u dbuser -p db_pass
Fri Jun 27 14:24:21 starting new replica set monitor for replica set my_rs with seed of 10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27017 for replica set my_rs
Fri Jun 27 14:24:21 changing hosts to { 0: "10.0.0.88:27017", 1: "10.0.0.88:27018" } from my_rs/
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27017 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27017 in replica set my_rs
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27018 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27018 in replica set my_rs
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27019 for replica set my_rs
Fri Jun 27 14:24:21 Primary for replica set my_rs changed to 10.0.0.88:27017
Fri Jun 27 14:24:21 replica set monitor for replica set my_rs started, address is my_rs/10.0.0.88:27017,10.0.0.88:27018
connected to: my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 [ReplicaSetMonitorWatcher] starting
Fri Jun 27 14:24:21 [oplogreplay] going to connect
Fri Jun 27 14:24:21 [oplogreplay] connected
Fri Jun 27 14:24:21 [oplogreplay] starting from Jun 26 14:24:21:0
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [omongooplog --from "10.0.0.180:27017" -h "my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019" -d my_db -u dbuser -p db_pass
Fri Jun 27 14:24:21 starting new replica set monitor for replica set my_rs with seed of 10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27017 for replica set my_rs
Fri Jun 27 14:24:21 changing hosts to { 0: "10.0.0.88:27017", 1: "10.0.0.88:27018" } from my_rs/
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27017 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27017 in replica set my_rs
Fri Jun 27 14:24:21 trying to add new host 10.0.0.88:27018 to replica set my_rs
Fri Jun 27 14:24:21 successfully connected to new host 10.0.0.88:27018 in replica set my_rs
Fri Jun 27 14:24:21 successfully connected to seed 10.0.0.88:27019 for replica set my_rs
Fri Jun 27 14:24:21 Primary for replica set my_rs changed to 10.0.0.88:27017
Fri Jun 27 14:24:21 replica set monitor for replica set my_rs started, address is my_rs/10.0.0.88:27017,10.0.0.88:27018
connected to: my_rs/10.0.0.88:27017,10.0.0.88:27018,10.0.0.88:27019
Fri Jun 27 14:24:21 [ReplicaSetMonitorWatcher] starting
Fri Jun 27 14:24:21 [oplogreplay] going to connect
Fri Jun 27 14:24:21 [oplogreplay] connected
Fri Jun 27 14:24:21 [oplogreplay] starting from Jun 26 14:24:21:0
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 } plogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
Fri Jun 27 14:24:21 [oplogreplay] { assertion: "unauthorized db:admin ns:admin lock type:1 client:10.0.0.88", assertionCode: 10057, errmsg: "db assertion failure", ok: 0.0 }
from Параметр также является RS (с noauth=true набором), но если я попытаюсь использовать «my_rs / 10.0.0.180: 27017», он терпит неудачу, не похоже from , что параметр может использовать RS-адрес.
имя пользователя и пароль, используемые для воспроизведения на 88, находятся в базе данных администратора, а также в my_db.
Обновить
Я обновился до 2.4.10. Обновление, похоже, дает более значимое ведение журнала. На 180 я могу подключиться к локальной базе данных (без авторизации) и выполнить a db.oplog.rs.count() и получить результаты (как для локальных, так и для удаленных подключений). Однако, когда я запускаю mongooplog с 180 в качестве from , я все равно получаю сообщение об ошибке (это из 88):
Tue Jul 1 10:16:29.034 [oplogreplay] error getting oplog
Tue Jul 1 10:16:29.034 [oplogreplay] { $err: "not authorized for query on local.oplog.rs", code: 16550 }
и я вижу аналогичную ошибку в журналах ошибок 180.
Ответ №1:
Вам необходимо добавить базу данных аутентификации в командную строку, поскольку по умолчанию mongooplog будет считать, что ваши учетные данные имени пользователя и пароля применяются к базе данных, к которой вы применяете oplog.
—authenticationDatabase dbname
Новое в версии 2.4.
Указывает базу данных, в которой хранятся учетные данные пользователя. Если вы не укажете базу данных аутентификации, mongooplog предполагает, что
база данных, указанная в качестве аргумента опции —db, содержит учетные данные пользователя.
поэтому в вашем случае я бы добавил --authenticationDatabase admin в вашу командную строку.
Комментарии:
1. итак, если я использую 2.2, потребуется обновление, чтобы заставить oplog работать?
2. Возможно, вы могли бы попробовать добавить эти учетные данные в базу данных my_db — проблема в том, что он пытается применить ваши учетные данные для входа в другую базу данных. ЕСЛИ у вас одинаковые учетные данные как в admin, так и в my_db, это должно сработать. Осторожно, хотя я не пробовал это на 2.2.
3. Привет, Джон, см. Раздел «Обновление» в моем исходном сообщении — я обновил mongo и попытался установить authenticationDatabase на local, admin и my_db (одна и та же учетная запись пользователя существует во всех 3 базах данных). Я все еще получаю ошибку, показанную выше.
4. Из последнего сообщения об ошибке мне кажется, что у вашего пользователя нет соответствующего доступа к локальной базе данных и коллекции oplog. Я бы проверил роли пользователей и предоставил этому пользователю как можно больше (ReadWrite). docs.mongodb.org/v2.4/reference/user-privileges
5. попробую это сделать. может потребоваться роль администратора кластера.
Ответ №2:
Mongooplog, похоже, не справлялся с аутентификацией, а также, похоже, не поддерживает фильтрацию баз данных для репликации.
Я написал инструмент (gem), который позволяет выполнять репликацию между 2 наборами реплик. Он доступен по адресу https://github.com/brettcave/mongo-oplogreplay