Прочитайте уровень опасности большинства ошибок при обновлении Sharded Cluster с 3.2 до 3.4.

Я обновил сегментированный кластер MongodDB с двумя наборами реплик с 3.2 до 3.4. Текущий механизм хранения — MMAPv1. После успешного обновления всех вторичных, первичных, конфигурационных серверов и mongos до 3.4, когда я запускаю конфигурационный сервер с помощью следующей команды.

судо монгод --configsvr

Я продолжаю получать следующую ошибку.

SHARDING [перезагрузка реестра сегментов] Периодическая перезагрузка реестра сегментов не удалась :: вызвана :: 115 не удалось получить обновленный список сегментов с сервера конфигурации из-за того, что текущий механизм хранения не поддерживает большинство readConcerns; повторит попытку через 30 секунд

А также я не могу подключить mongos к серверу конфигурации. Когда я пытаюсь подключить его, используя следующую команду

sudo mongos --configdb [ip-of-my-config-server]:27019

Это дает мне следующую ошибку.

BadValue: configdb поддерживает только строку подключения набора реплик.

Я предполагаю, что mongos не может подключиться к серверу конфигурации из-за ошибки большинства readConcerns на сервере конфигурации.

В руководстве MongoDB говорится: «При чтении с серверов конфигурации наборов реплик MongoDB 3.4 использует уровень Read Concern «большинства»».

И чтобы использовать уровень беспокойства о чтении «большинство», WiredTiger должен использоваться как механизм хранения.

Так что, похоже, мне нужно переключиться на механизм хранения WiredTiger, чтобы он заработал. Но когда я собирался переключиться на механизм хранения WiredTiger члена набора вторичных реплик, в соответствии с руководством

"Эта процедура полностью удаляет данные члена набора вторичных реплик"

Так что я застрял на полпути. Ситуация

  1. Сервер конфигурации выдает ошибку относительно большинства readConcerns.
  2. Я должен переключиться на WiredTiger, чтобы избавиться от него.
  3. Переключение на WiredTiger приведет к удалению данных из вторичных членов.
  4. Данные не будут реплицированы обратно на вторичных членов во время этого переключения на процедуру WiredTiger из-за ошибки сервера конфигурации, и в конечном итоге я потеряю все данные (пожалуйста, исправьте, если я ошибаюсь).

Вопросы:

  1. Могу ли я заставить MongoDB 3.4 использовать «локальный» уровень Read Concern при чтении с серверов конфигурации набора реплик?
  2. Как я могу переключиться на движок WiredTiger без потери данных в моем сценарии?

upgrade mongodb sharding replicaset wiredtiger
person umarxe    schedule 01.03.2017    source источник
comment
Можно ли перейти на версию 3.2, выполнить миграцию на WiredTiger, а затем выполнить обновление?   -  person Vince Bowdren    schedule 01.03.2017
comment
Да, это можно сделать, если другого решения не найдено.   -  person umarxe    schedule 01.03.2017

Ответы (1)


arrow_upward
0
arrow_downward

Вы можете перенести каждый узел в набор реплик как если бы он был автономным, используя mongodump для резервного копирования данных, перезапуск с помощью WiredTiger и пустого каталога данных, а затем использование mongorestore для заполнения новой базы данных.

Обычно это не рекомендуется для узлов набора реплик, но только потому, что проще стереть данные на вторичном сервере и позволить ему выполнить повторную синхронизацию с другими узлами. Такой способ будет работать нормально, но потребует от вас немного более кропотливой работы с инструментами дампа и восстановления.

person Vince Bowdren    schedule 01.03.2017