Является ли миграция mongodb между кластерами с использованием репликации жизнеспособным вариантом?

Question

У нас есть управляемый кластер mongodb 3.0.11, работающий на Compose с ~ 300 ГБ данных (назовите это C0). Мы хотим переместить эти данные в самоуправляемый кластер mongodb 4.x, работающий на GCP (назовите это C1). Я экспериментировал с несколькими репозиториями github, которые были созданы для клонирования / синхронизации БД, но ни одно из них не сработало надежно для моих тестов (и, честно говоря, я не уверен, что хочу использовать эти не сильно протестированные репозитории для переноса нашего производства). data).

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

Вот что меня интересует - эксперты mongodb прокомментируют, будет ли это работать (иесли у вас есть какой-либо совет, основанный на опыте этого:)

• Добавьте два экземпляра mongodb из C1 в качестве реплики с приоритетом 0 и установите членов в C0
• Подождите, пока C1.members будет запущен-to-date
• Перейти в «режим обслуживания» - клиенты доступа к базе данных выключены
• Принудительно обновить один из C1.members, чтобы он стал основным
• Удалить все C0.membersиз набора реплик
• Перезапустите клиенты базы данных с новой строкой подключения к набору реплики C1

Альтернатива - написать свой собственный клонер / синхронизатор, поскольку ни один из инструментов, которые я до сих пор не нашелпохоже, готово к выпуску монго 4.х.

Мысли?

Answer 1

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

Миграция между кластерами с использованием общего подхода, который вы описали, возможна, если вы используете совместимые версии сервера MongoDB и можете добавлять всех участников к одному и тому женабор реплик. В настоящее время для последовательных обновлений поддерживаются только смежные выпуски основных серверов, поэтому, если отправной точкой является MongoDB 3.0.x, самой новой версией, которую вы можете напрямую добавить в набор реплик 3.0.x, будет 3.2.x. Если ваша конечная цель - 4.0.x, вам нужно перейти с 3.2 => 3.4, 3.4 => 3.6 и, наконец, 3.6 => 4.0. Замечания по выпуску MongoDB содержат конкретные предварительные условия, процедуры обновления и информацию о совместимости для каждого основного выпуска.

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

Лучшим вариантом для живой миграции с DBaaS будет создание пользователя сПолучите доступ к журналу репликации и найдите инструмент миграции, который соответствует вашему варианту использования и версиям исходного / целевого сервера. В производственной среде я бы с осторожностью пытался выполнить живую миграцию между несколькими основными выпусками (например, с 3.0.x на 4.0.x) и поощрял бы такую ​​же миграцию версий (3.0.x => 3.0.x) с отдельными шагами обновления.

В качестве общего подхода я бы:

• Просмотрите все заметки о выпуске, обновлении и совместимости для обновлений сервера и драйвера, которые вы планируете.
• Убедитесь, чтовы используете совместимые версии драйверов и обновите свои драйверы / код приложения перед обновлением версий сервера.
• Протестируйте процесс обновления с резервной копией производственных данных в репрезентативной промежуточной среде / среде QA.
• Тестваши приложения с обновленными версиями драйверов / серверов и репрезентативной рабочей нагрузкой для поиска потенциальных проблем, таких как снижение производительности.