Облачная платформаAdvanced

От MongoDB к DDS

Эта статья полезна?
Язык статьи: Русский
Показать оригинал
Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

Поддерживаемые исходные и целевые базы данных

Таблица 1 Поддерживаемые базы данных

Исходная БД

Целевая БД

  • On-premises MongoDB (версии 3.2, 3.4, 3.6, 4.0, 4.2, 4.4 и 5.0)
  • ECS-hosted MongoDB (версии 3.2, 3.4, 3.6, 4.0, 4.2, 4.4 и 5.0)
  • Other Cloud MongoDB 3.2, 3.4, 3.6, 4.0, 4.2, 4.4 и 5.0
  • DDS DB instances (версии 3.2, 3.4, 4.0, 4.2, 4.4 и 5.0)
    ПРИМЕЧАНИЕ:
    • Если исходная база данных — экземпляр кластера DDS 3.2, поддерживается только полная миграция.
    • Если исходная база данных представляет собой экземпляр DDS DB, движок исходной БД — DDS. В противном случае движок исходной БД — MongoDB-DDS.
  • DDS DB instances (версии 3.4, 4.0, 4.2, 4.4 и 5.0)
    ПРИМЕЧАНИЕ:

    Версия целевой базы данных должна быть такой же либо более поздней, чем версия исходной базы данных

Вы можете выполнить следующую команду для запроса версии базы данных

db.version()

Требования к разрешениям учетной записи базы данных

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

Таблица 2 Разрешение учетной записи базы данных

Тип

Полная миграция

Полная+Инкрементальная миграция

Пользователь исходной базы данных

  • Набор реплик: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для административной базы данных.
  • Один узел: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для административной базы данных.
  • Кластер: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение на чтение для базы данных config.
  • Для миграции учётных записей и ролей исходной базы данных пользователи исходной и целевой баз данных должны иметь разрешение на чтение для system.users и system.roles системные таблицы базы данных admin.
  • Replica set: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение на чтение для базы данных local.
  • Single node: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение на чтение для базы данных local.
  • Кластер: Пользователь исходного узла mongos должен иметь разрешение readAnyDatabase для базы данных admin и разрешение на чтение для базы данных config. Пользователь исходного узла shard должен иметь разрешение readAnyDatabase для базы данных admin и разрешение на чтение для базы данных local.
  • Для миграции учётных записей и ролей исходной базы данных пользователи исходной и целевой баз данных должны иметь разрешение на чтение для system.users и system.roles системные таблицы admin‑базы данных.

Пользователь целевой базы данных

Пользователь, подключающийся к целевой базе данных, должен иметь разрешение dbAdminAnyDatabase админ‑базы данных и разрешение readWrite целевой базы данных.

Если целевая база данных является кластерным экземпляром, пользователь базы данных должен иметь разрешение clusterManager для админ‑базы данных.

Note
  • Рекомендуется создать отдельную учетную запись базы данных для подключения задачи DRS, чтобы предотвратить сбои задач, вызванные изменением пароля учетной записи базы данных.
  • После изменения паролей учетных записей источника и целевой баз данных измените информацию о подключении задачи DRS, обратившись к Изменение информации о подключении чтобы предотвратить автоматический повтор после сбоя задачи. Автоматический повтор заблокирует учетные записи баз данных.
  • Для экземпляра реплика‑сета пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных local.
    db.grantRolesToUser("Username",[{role:"readAnyDatabase",db:"admin"}, {role:"read",db:"local"}])
  • Для экземпляра кластера пользователь mongos исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных config.
    db.grantRolesToUser("Username",[{role:"readAnyDatabase",db:"admin"}, {role:"read",db:"config"}])

Поддерживаемые объекты миграции

Разные типы задач миграции поддерживают различные объекты миграции. Для получения подробностей см Таблица 3. DRS будет автоматически проверять выбранные вами объекты перед миграцией.

Таблица 3 Объекты миграции

Тип

Предостережения

Объекты миграции

  • Вы можете выбрать миграцию на уровне таблицы, базы данных или экземпляра (всеуровневую).
  • Набор реплик: можно мигрировать только коллекции (включая validator и capped collections), индексы и представления.
  • Кластер: Только коллекции (включая validator и capped collections), ключи шардинга, индексы и представления могут быть мигрированы.
  • Один узел: Только коллекции (включая validator и capped collections), индексы и представления могут быть мигрированы.
  • Только пользовательские данные и информация учетных записей исходной базы данных могут быть мигрированы. Системные базы данных (например, local, admin и config) и системная коллекция не могут быть мигрированы. Если сервисные данные хранятся в системной базе данных, выполните renameCollection команда для перемещения сервисных данных в пользовательскую базу данных.
  • Оператор создания представления не может содержать регулярное выражение.
  • Коллекции, содержащие _id поле без индексов не поддерживается.
  • Первый параметр BinData() не может быть 2.
  • Если используется диапазонный шардинг, maxKey не может использоваться в качестве первичного ключа.
  • Не храните строки символов, не являющиеся UTF-8, в поле String коллекции исходной базы данных. В противном случае данные будут неконсистентны до и после миграции.
  • Если исходная база данных является кластерным экземпляром версии 4.4 или новее, а версия целевой базы данных старше 5.0, составные hash shard keys и составные hash indexes не поддерживаются. Если версия целевой базы данных 5.0, составные hash shard keys и составные hash indexes поддерживаются.
  • Если исходная база данных является экземпляром replica set версии 4.4 или новее, а версия целевой базы данных старше 5.0, составные hash indexes не поддерживаются. Если версия целевой базы данных 5.0, составные hash indexes поддерживаются.
  • Коллекции временных рядов не поддерживаются ни в полной, ни в инкрементной фазах.
  • Ключи шарда кластера не могут быть синхронизированы во время инкрементной синхронизации.

Проверка конфигурации журнала на исходной базе данных

Во время инкрементной миграции Oplog исходной базы данных должен быть включён. Если Объем хранения достаточен, храните Oplog исходной базы данных как можно дольше. Рекомендуемый период удержания составляет не менее трёх дней.

Меры предосторожности

Чтобы задачи могли работать нормально, DRS предоставляет автоматическую предварительную проверку. Перед запуском задачи DRS DRS проверяет конфигурации и условия исходных и целевых баз данных. Для получения подробной информации о основных пунктах проверки и рекомендациях по их обработке, см DRS Pre-Check Items. Помимо пунктов предварительной проверки, необходимо обратить внимание на пункты, перечисленные в Таблица 4.

Таблица 4 Меры предосторожности

Тип

Ограничения

Ограничения для исходной базы данных

  • Исходный объект не может быть GeminiDB Mongo инстанс.
  • Имя исходной базы данных не может содержать /\.$ или пробелы. Имя коллекции и имя представления не могут начинаться с система. или содержать символ доллара ($).
  • Когда несколько исходных баз данных мигрируют в одну и ту же целевую базу данных, имя мигрируемой базы данных должно быть уникальным.
  • Набор реплик: экземпляр набора реплик MongoDB должен быть доступен и иметь первичные узлы.
  • Если требуется выполнить инкрементную миграцию для одиночного узла, исходная база данных должна быть однопроцессным экземпляром DDS в текущем облаке.

Ограничения использования

Общие

  • Во время миграции не изменяйте и не удаляйте имена пользователей, пароли и разрешения исходных и целевых баз данных, а также не меняйте их порты.
  • Во время миграции не изменяйте целевую базу данных (включая, но не ограничиваясь операциями DDL и DML), которую мигрируют.
  • Во время миграции откат данных, вызванный переключением primary/standby исходной базы данных, не поддерживается.
  • Во время миграции документы размером более 16 МБ в исходной базе данных не могут быть вставлены или обновлены.
  • Во время миграции не запускайте sh.moveChunk() в исходной базе данных. В противном случае мигрированные данные будут неконсистентны.

Полный перенос

  • Во время запуска задачи и полного переноса не выполняйте DDL‑операции в исходной базе данных. В противном случае задача может работать аномально.

Инкрементальная миграция

  • Во время инкрементальной миграции коллекций рекомендуется не переименовывать коллекции.
  • Для обеспечения производительности миграции конкурентный реплей выполняется на уровне набора в фазе инкрементальной задачи. В следующих сценариях поддерживается только запись одним потоком, а конкурентный реплей не поддерживается:
    • Индекс коллекции содержит уникальный ключ.
    • Значение ограниченный значение атрибута коллекции true.

    В любом из перечисленных выше сценариев задержка задачи может увеличиться.

Сравнение данных

  • Рекомендуется сравнивать данные в часы непиковой нагрузки исходной базы данных, чтобы предотвратить ложное сообщение о несогласованных данных и снизить влияние на исходную базу данных и задачи DRS.
  • Во время инкрементной синхронизации, если данные записываются в исходную базу данных, результаты сравнения могут быть несогласованными.
  • При сравнении строк, если в экземпляре Кластера существует осиротевший документ или мигрируют чанки, количество возвращённых строк неверно, и результаты сравнения несогласованы. Для получения подробностей см. Официальные документы MongoDB.

Другие ограничения

  • Если исходная база данных не находится на экземпляре Кластера, во время инкрементной миграции поддерживаются следующие операции и команды:
    • Создание и удаление баз данных
    • Добавление, удаление и обновление документов
    • Создание и удаление коллекций
    • Создание и удаление индексов
    • Создание и удаление представлений
    • Команды convertToCapped, collMod и renameCollection поддерживаются.
  • Во время полной+инкрементальной миграции между кластерами или от кластера к репликационному набору объекты, подлежащие миграции, нельзя удалять. В противном случае задача миграции завершится с ошибкой.
  • Если вы выберете Кластер (MongoDB 4.0+) для Тип экземпляра исходной БД, DRS будет использовать функцию MongoDB change streams во время миграции. Обратите внимание на следующее перед использованием потоков изменений:
    • Подписка на данные с использованием потоков изменений потребляет определённое количество CPU и ресурсов оперативной памяти исходной базы данных. Оцените ресурсы исходной базы данных заранее.
    • Если нагрузка на исходную базу данных высока, скорость обработки потоков изменений не успевает за скоростью генерации oplog. В результате возникает задержка синхронизации DRS.
    • Из‑за ограничений MongoDB change streams только удалить базу данных, удалить коллекцию, и переименовать DDL statements поддерживаются во время инкрементной синхронизации. Когда документы вставляются или заменяются в коллекции исходной базы данных в первый раз, индексы коллекции будут синхронизированы с целевой базой данных. Если вам не нужно синхронизировать индексы, обратитесь в техническую поддержку.
    • Типы данных DBPointer и DBRef не поддерживаются.
    • В фазе инкрементной миграции,скорость миграции может достигать до 10,000 строк в одной таблице в секунду.
    • Метод changeStream находится в ограниченном использовании.
  • Если Тип экземпляра исходной DB установлен в Кластер и Получить инкрементные данные установлен в oplog, DRS создаст несколько подзадач, основанных на количестве исходных шардов. Если Flow Control включен, настроенное значение ограничения скорости будет синхронизировано с каждой подзадачей.
  • Если индекс Time-to-Live (TTL) уже существует в коллекции исходной базы данных или создаётся во время инкрементной миграции, согласованность данных не может быть гарантирована, когда исходные и целевые базы данных находятся в разных часовых поясах или часах.
  • Значение block_compressor определяется stats().wiredTiger.creationString.block_compressor коллекции в исходной базе данных. Если целевая база данных содержит соответствующие пустые коллекции, параметры сжатия не будут перенесены. Если параметры сжатия в исходной базе данных не поддерживаются целевой базой данных, настройте параметры сжатия на основе net.compression.compressors целевой базы данных. Если версия целевой базы данных DDS 4.2, DRS не переносит параметры сжатия, потому что целевая база данных не поддерживает настройки параметров сжатия.
  • Если учетные записи и роли, подлежащие миграции, конфликтуют с записями в целевой базе данных, DRS пропустит конфликтные данные и продолжит миграцию.
  • Если сервис MongoDB исходной базы данных развернут вместе с другими сервисами на том же сервере, установите значение cacheSizeGB параметр до половины минимального простоя кэша для движка WiredTiger исходной базы данных.
  • Если источник представляет собой экземпляр набора реплик, введите информацию обо всех первичных и вторичных узлах, чтобы снизить влияние переключения первичного/вторичного узла на задачу миграции. Если вы вводите информацию о нескольких первичных и вторичных узлах, убедитесь, что все узлы принадлежат одному экземпляру набора реплик.
  • Если источник представляет собой экземпляр кластера, введите информацию о нескольких узлах mongos, чтобы снизить влияние отказа отдельного узла на задачу миграции. Кроме того, убедитесь, что все узлы mongsos принадлежат одному экземпляру кластера. Для инкрементальной миграции экземпляра кластера рекомендуется ввести информацию обо всех первичных и вторичных узлах узла шарда и убедиться, что вся информация об узлах относится к одному шару, чтобы снизить влияние переключения первичного/вторичного узла на задачу миграции. Убедитесь, что все узлы шарда принадлежат одному кластеру.
  • В некоторых сценариях миграции, чтобы предотвратить удаление существующих коллекций в целевой базе данных операцией drop database, операция drop database не будет синхронизирована с целевой базой данных.
    • Если версия исходной базы данных раньше MongoDB 3.6, выполнение команды drop database удалит коллекции только из исходной базы данных. Коллекции в целевой базе данных удалены не будут.
    • Если версия исходной базы данных MongoDB 3.6 или новее, операция drop database представлена операциями drop database и drop collection в oplog. Выполнение команды drop database удалит коллекции как из исходной, так и из целевой баз данных.
  • Для ускорения миграции удалите ненужные индексы из исходной базы данных и сохраните только необходимые индексы перед миграцией. Рекомендуется не создавать индексы для исходной базы данных во время миграции. Если индексы необходимо создать, создавайте их в фоновом режиме.
  • Чтобы предотвратить обратный цикл, не запускайте задачи, мигрирующие одну и ту же базу данных в облако и из облака одновременно.

Процедура

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

  1. На Управление онлайн миграцией странице, щелкните Создать задачу миграции.
  2. На Создать репликационный экземпляр странице, укажите имя задачи, описание и детали репликационного экземпляра, и щелкните Создать сейчас.

    • Описание информации о задаче
      Таблица 5 Информация о задаче

      Параметр

      Описание

      Имя задачи

      Имя задачи должно начинаться с буквы и состоять из 4‑50 символов. Оно может содержать только буквы, цифры, дефисы (-) и подчеркивания (_).

      Описание

      Описание может содержать до 256 символов и не может содержать специальные символы !=<>&'\"

    • Информация об экземпляре репликации
      Таблица 6 Настройки экземпляра репликации

      Параметр

      Описание

      Поток данных

      Выбрать В облако.

      Целевая база данных должна быть базой данных в текущем облаке.

      Исходный DB Engine

      Выбрать MongoDB.

      Целевой DB Engine

      Выбрать DDS.

      Тип сети

      Доступные варианты: VPC, VPN или Direct Connect, и Публичная сеть. По умолчанию значение Публичная сеть.

      • VPC подходит для миграций между облачными базами данных одного и того же аккаунта в одном регионе и VPC.
      • Публичная сеть подходит для миграций из локальных баз данных или внешних облачных баз данных в целевые базы данных.
      • VPN или Direct Connect подходит для миграций из локальных баз данных в облачные базы данных или между базами данных в разных регионах в облаке с использованием VPN, Direct Connect, Cloud Connect, VPCEP или соединения VPC peering.

      Экземпляр целевой БД

      Выберите созданный вами экземпляр БД.

      Подсеть экземпляра репликации

      Подсеть, в которой находится репликационный экземпляр. Вы также можете нажать Просмотр подсетей чтобы перейти в консоль сети и просмотреть подсеть, в которой находится экземпляр.

      По умолчанию экземпляр DRS и экземпляр целевой DB находятся в одной подсети. Вам необходимо выбрать подсеть, в которой находится экземпляр DRS, и в которой есть доступные IP‑адреса. Чтобы обеспечить успешное создание репликационного экземпляра, отображаются только подсети с включённым DHCP.

      Тип миграции

      • Полный: Этот тип миграции подходит для сценариев, при которых допускается прерывание работы сервиса. Он переносит все объекты и данные из несистемных баз данных в целевую базу данных за один раз. Объекты включают коллекции, представления и индексы.
        ПРИМЕЧАНИЕ:

        Если вы выполняете полную миграцию, не проводите операции в исходной базе данных. В противном случае данные, созданные в исходной базе данных во время миграции, не будут синхронизированы с целевой базой данных.

      • Full+Incremental: Этот тип миграции позволяет переносить данные без прерывания сервисов. После того как полная миграция инициализирует целевую базу данных, инкрементальная миграция запускается и парсит логи для обеспечения согласованности данных между исходной и целевой базами данных.
        ПРИМЕЧАНИЕ:

        Если вы выбираете Full+Incremental, данные, генерируемые во время полной миграции, будут непрерывно синхронизироваться с целевой базой данных, а источник останется доступным.

      Тип экземпляра исходной БД

      Если вы выбираете Full+Incremental для Тип миграции, установите этот параметр в соответствии с исходной базой данных.

      • Если исходная база данных является кластерным экземпляром, установите этот параметр в Кластер.
      • Если исходная база данных является набором реплик или экземпляром одиночного узла, установите этот параметр в Не кластерный.

      Получить инкрементные данные

      Если Тип экземпляра источника БД установлен в Кластер и Режим миграции установлен в Full+Incremental, вам необходимо определить, как фиксировать изменения данных во время инкрементной синхронизации. Также балансировщик источника базы данных должен быть отключён, а осиротевшие документы должны быть удалены. Для деталей см

      • oplog: Для MongoDB 3.2 и более новых версий DRS напрямую подключается к каждому шарду экземпляра источника БД для извлечения данных. Если вы выбираете этот метод, необходимо ввести информацию о подключении к каждому шару в источнике базы данных при тестировании соединения между источником базы данных и экземпляром DRS.
      • changeStream: Этот метод рекомендуется. Для MongoDB 4.0 и более новых версий DRS подключается к узлам mongos исходной базы данных для извлечения данных. Если вы выбираете этот метод, необходимо включить механизм хранения WiredTiger в исходной базе данных.

      Количество шардов источника

      Если Тип экземпляра исходной БД установлен на Кластер и Получить инкрементные данные установлен на oplog, вам необходимо ввести количество шардов исходной базы данных.

      Количество шардов источника варьируется от 2 до 64. Укажите этот параметр исходя из фактического количества шардов в исходной БД.

      Укажите EIP

      Этот параметр доступен, когда вы выбираете Публичная сеть для Тип сети. Выберите EIP для привязки к экземпляру DRS. DRS автоматически привяжет указанный EIP к экземпляру DRS и отсвободит EIP после завершения задачи. Если Тип экземпляра исходной DB установлено Кластер и Получить инкрементные данные установлено oplog, количество указанных EIP должно соответствовать количеству исходных шардов.

    • AZ
      Таблица 7 AZ задачи

      Параметр

      Описание

      AZ

      Выберите AZ, где вы хотите создать задачу DRS. Выбор AZ, содержащего исходную или целевую базу данных, может обеспечить лучшую производительность.

    • Enterprise Проект и Теги
      Таблица 8 Enterprise Project и Теги

      Параметр

      Описание

      Enterprise Проект

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

      Теги

      • Тегировать задачу. Эта конфигурация необязательна. Добавление тегов помогает лучше идентифицировать и управлять вашими задачами. Каждая задача может содержать до 20 тегов.
      • После создания задачи вы можете просмотреть детали её тегов на Теги вкладке. Для получения подробностей см. Управление тегами.
    Note

    Если задача не может быть создана, DRS сохраняет задачу по умолчанию в течение трёх дней. По истечении трёх дней задача автоматически останавливается.

  3. На Настройте исходную и целевую базы данных страница, подождите, пока будет создана репликация экземпляра. Затем укажите информацию об исходной и целевой базе данных и нажмите Проверить соединение для обеих исходных и целевых баз данных, чтобы проверить, подключены ли они к репликационному экземпляру. После успешного прохождения тестов соединения выберите флажок перед соглашением и нажмите Далее.

    • Информация об исходной базе данных
      Таблица 9 Информация об исходной базе данных

      Параметр

      Описание

      mongos IP‑адрес или доменное имя

      IP‑адрес или доменное имя исходной базы данных в IP‑адрес/доменное имя:порт формат. Порт исходной базы данных. Диапазон: 1 - 65535

      Вы можете указать не более трех групп IP-адресов или доменных имён исходной базы данных. Разделяйте несколько значений запятыми (,). Например: 192.168.0.1:8080,192.168.0.2:8080. Убедитесь, что указанные IP-адреса или доменные имена принадлежат одному шардированному кластеру.

      ПРИМЕЧАНИЕ:

      Если указано несколько IP-адресов или доменных имён, тестовое соединение будет успешным, если хотя бы один IP-адрес или доменное имя доступно. Поэтому необходимо убедиться, что IP-адрес или доменное имя указаны корректно.

      База данных аутентификации

      Имя базы данных аутентификации пользователя исходной базы данных MongoDB. Например: базой данных аутентификации по умолчанию для экземпляра DDS является admin.

      Имя пользователя mongos

      Имя пользователя узла mongos исходной базы данных MongoDB. Например, имя пользователя mongos по умолчанию для экземпляра DDS равно rwuser.

      Пароль базы данных

      Пароль для имени пользователя базы данных.

      SSL соединение

      SSL шифрует соединения между исходными и целевыми базами данных. Если SSL включён, загрузите корневой сертификат SSL CA.

      NOTE:
      • Максимальный размер одного файла сертификата, который можно загрузить, — 500 KB.
      • Если SSL отключён, ваши данные могут быть под угрозой.

      Шардированная база данных

      Введите информацию о узлах шарда базы данных MongoDB в соответствии с количеством узлов шарда кластера в исходной базе данных.

      • Задайте IP-адрес или доменное имя шардированной базы данных, соответствующее узлу шарда в исходной базе данных MongoDB. Значение находится в IP-адрес/имя домена:порт формат.
      • Задайте базу данных аутентификации шардированной базы данных именем базы данных, к которой принадлежит учётная запись узла шарда исходной базы данных MongoDB. Например, базой данных аутентификации шарда по умолчанию для экземпляра DDS является admin.
      • Установите имя пользователя шардинговой базы данных таким же, как у узла шарда в исходной базе данных MongoDB. Например, имя пользователя шарда по умолчанию для экземпляра DDS равно sharduser.
      Note

      IP-адрес, доменное имя, имя пользователя и пароль исходной базы данных зашифрованы и сохранены в DRS, и будут удалены после удаления задачи.

    • Конфигурация целевой базы данных
      Таблица 10 Настройки целевой базы данных

      Параметр

      Описание

      Имя экземпляра DB

      Экземпляр DB, выбранный при создании задачи миграции. Этот параметр нельзя изменить.

      База данных аутентификации

      Имя базы данных аутентификации. Например: база данных аутентификации по умолчанию для экземпляра DDS равна admin.

      Имя пользователя базы данных

      Имя пользователя для доступа к целевой базе данных.

      Database Password

      Пароль для имени пользователя базы данных.

      SSL Connection

      SSL шифрует соединения между исходной и целевой базами данных. Если SSL включён, загрузите корневой сертификат SSL CA.

      NOTE:
      • Максимальный размер одного файла сертификата, который можно загрузить, — 500 KB.
      • Если SSL отключён, ваши данные могут быть под угрозой.
      Note

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

  4. On the Set Task странице, выберите объекты миграции и нажмите Next.

    Table 11 Migrate Object

    Параметр

    Описание

    Контроль потока

    Вы можете выбрать, контролировать ли поток. Контроль потока применяется только в полной фазе.

    • Да

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

      Кроме того, вы можете задать временной диапазон в соответствии с требованиями вашего сервиса. Настройка скорости трафика обычно включает установку периода ограничения скорости и значения скорости трафика. Поток может контролироваться круглосуточно или в определённые временные диапазоны. Значение по умолчанию — Всегда. Можно задать максимум 10 временных диапазонов, они не могут перекрываться.

      Скорость потока должна устанавливаться в соответствии со сценарием сервиса и не может превышать 9,999 MB/s.

    • Нет

      Скорость миграции не ограничена, и исходная пропускная способность исходной базы данных используется максимально, что соответственно вызывает потребление чтения в исходной базе данных. Например, если исходная пропускная способность исходной базы данных составляет 100 MB/s и используется 80% пропускной способности, потребление I/O в исходной базе данных составляет 80 MB/s.

      ПРИМЕЧАНИЕ:
      • Режим управления потоком действует только во время полной миграции.
      • Вы также можете изменить режим управления потоком после создания задачи. Для получения подробной информации см Изменение режима управления потоком.

    Миграция учетной записи

    Учетные записи, которые подлежат миграции, можно классифицировать по следующим типам: учетные записи, которые могут быть мигрированы, и учетные записи, которые не могут быть мигрированы. Вы можете выбрать, мигрировать учетные записи или нет. Учетные записи, которые не могут быть мигрированы, или не выбранные учетные записи, не будут присутствовать в целевой базе данных. Убедитесь, что ваши сервисы не будут затронуты этими учетными записями.

    • Нет

      Во время миграции учетные записи и роли не мигрируются.

    Мигрировать объект

    В левом панеле отображаются объекты исходной базы данных, а в правом панеле — выбранные объекты. Вы можете выбрать миграцию всех объектов, таблиц или баз данных в соответствии с требованиями вашего сервиса.

    • Все: Все объекты в исходной базе данных мигрируют в целевую базу данных. После миграции имена объектов останутся такими же, как в исходной базе данных, и не могут быть изменены.
    • Таблицы: Выбранные объекты уровня таблицы будут мигрированы.
    • Базы данных: Выбранные объекты уровня базы данных будут мигрированы.

    Если исходная база данных изменена, нажмите в правом верхнем углу перед выбором объектов миграции, чтобы убедиться, что выбираемые объекты берутся из изменённой исходной базы данных.

    ПРИМЕЧАНИЕ:
    • Если вы решите не мигрировать все базы данных, миграция может завершиться с ошибкой, потому что объекты, такие как хранимые процедуры и представления, в базах данных, подлежащих миграции, могут иметь зависимости от других объектов, которые не мигрируются. Чтобы предотвратить ошибку миграции, мигрируйте все базы данных.
    • Если имя объекта содержит пробелы, пробелы перед и после имени объекта не отображаются. Если в середине имени объекта два и более последовательных пробела, отображается только один пробел.
    • Имя выбранного объекта миграции не может содержать пробелы.
    • Чтобы быстро выбрать нужные объекты базы данных, вы можете использовать функцию поиска.

  5. На Проверить задачу странице, проверьте задачу миграции.

    • Если какая‑либо проверка не проходит, изучите причину и устраните ошибку. После устранения ошибки нажмите Проверить снова.
    • Если проверка завершена и процент успешности проверки составляет 100%, нажмите Далее.
      Note

      Вы можете перейти к следующему шагу только тогда, когда все проверки успешны. Если есть элементы, требующие подтверждения, просмотрите и подтвердите детали сначала, прежде чем переходить к следующему шагу.

  6. На отображаемой странице укажите Время начала, Отправить уведомления, SMN Topic, Порог задержки (s), Запустить сравнение после миграции, Начать сейчас (только инициализация), и Остановить аномальные задачи после, подтвердите, что настроенная информация верна, и нажмите Отправить для отправки задачи.

    Таблица 12 Настройки запуска задачи

    Параметр

    Описание

    Время начала

    Установить Время начала до Запуск при создании задачи или Запуск в указанное время на основе требований сайта. The Запуск в указанное время рекомендован вариант.

    ПРИМЕЧАНИЕ:

    Задача миграции может повлиять на производительность исходных и целевых баз данных. Рекомендуется запускать задачу в непиковые часы и выделить два‑три дня для проверки данных.

    Отправлять уведомления

    Этот параметр является необязательным. Если статус, метрика задержки или данные задачи миграции аномальны, DRS отправит вам уведомление.

    Тема SMN

    Этот параметр доступен только после включения Отправить уведомления и создать топик в консоли SMN и добавить подписчика.

  7. После отправки задачи, просмотрите и управляйте ею на Управление онлайн‑миграцией странице.

    • Вы можете просмотреть статус задачи. Для получения дополнительной информации о статусе задачи см. Статусы задач.
    • Вы можете щелкнуть в правом верхнем углу, чтобы просмотреть последний статус задачи.
    • После завершения полной миграции вы можете использовать сравнение данных чтобы проверить, согласованы ли данные до и после миграции.
    • По умолчанию DRS сохраняет задачу в Конфигурация состояние в течение трёх дней. Через три дня DRS автоматически удаляет фоновые ресурсы, но статус задачи остаётся неизменным. При повторной настройке задачи DRS снова запрашивает ресурсы.
    • Для задачи в публичной сети DRS необходимо удалить фоновые ресурсы после остановки задачи. Привязанный к задаче EIP нельзя восстановить в Непривязан состояние до удаления фоновых ресурсов.