Из MongoDB в DDS

Эта статья полезна?

Язык статьи: Русский

Страница переведена автоматически и может содержать неточности. Рекомендуем сверяться с английской версией.

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

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

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

db.version()

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

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

Table 2 Разрешение учетной записи базы данных
Тип	Полная миграция	Полная+инкрементальная миграция
Пользователь исходной базы данных	Набор реплик: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для admin базы данных. Single node: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin. Cluster: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных config. Для миграции учетных записей и ролей исходной базы данных пользователи исходной и целевой баз данных должны иметь разрешение read для system.users и system.roles системные таблицы базы данных admin.	Replica set: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных local. Single node: Пользователь исходной базы данных должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных local. Cluster: Пользователь узла mongos должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных config. Пользователь шард-узла должен иметь разрешение readAnyDatabase для базы данных admin и разрешение read для базы данных local. Для миграции учетных записей и ролей исходной базы данных пользователи исходной и целевой баз данных должны иметь разрешение read для system.users и system.roles системные таблицы базы данных admin.
Пользователь целевой базы данных	Пользователь, подключающийся к целевой базе данных, должен иметь разрешение dbAdminAnyDatabase базы данных admin и разрешение readWrite целевой базы данных. Если целевая база данных является кластерным экземпляром, пользователь базы данных должен иметь разрешение clusterManager для базы данных admin.

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"}])
```

Supported Migration Objects

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

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

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

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

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

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

Таблица 4 Предосторожности
Тип	Ограничения
Ограничения для исходной базы данных	Исходный объект не может быть GeminiDB Mongo экземпляр. Имя исходной базы данных не может содержать /\.$ или пробелы. Имя коллекции и имя представления не могут начинаться с система. или содержать знак доллара ($). При миграции нескольких исходных баз данных в одну и ту же целевую базу данных имя базы данных, подлежащей миграции, должно быть уникальным. Набор реплик: экземпляр MongoDB replica set должен быть доступен и иметь первичные узлы. Если необходимо выполнить инкрементную миграцию для одноузлового экземпляра, исходная база данных должна быть экземпляром DDS с одним узлом в текущем облаке.
Restrictions on usage	General Во время миграции не изменяйте и не удаляйте имена пользователей, пароли и разрешения исходных и целевых баз данных, а также не меняйте порты исходных и целевых баз данных. Во время миграции не изменяйте целевую базу данных (включая, но не ограничиваясь операциями DDL и DML), которая мигрируется. Во время миграции откат данных, вызванный переключением primary/standby исходной базы данных, не поддерживается. Во время миграции документы размером более 16 МБ в исходной базе данных нельзя вставлять или обновлять. Во время миграции не запускайте sh.moveChunk() в исходной базе данных. В противном случае мигрированные данные будут неконсистентными. Полная миграция Во время запуска задачи и полной миграции не выполняйте DDL‑операции в исходной базе данных. В противном случае задача может стать аномальной. Инкрементальная миграция Во время инкрементальной миграции коллекций рекомендуется не переименовывать коллекции. Для обеспечения производительности миграции в фазе инкрементальной задачи выполняется конкурентный повтор на уровне набора. В следующих сценариях поддерживается только однопоточная запись, и конкурентный повтор не поддерживается: Индекс коллекции содержит уникальный ключ. Значение capped атрибута коллекции равно true. В любом из перечисленных сценариев задержка задачи может увеличиться. Сравнение данных Рекомендуется сравнивать данные в часы невысокой загрузки исходной базы данных, чтобы предотвратить ложное сообщение о несогласованных данных и сократить влияние на исходную базу данных и задачи DRS. Во время инкрементной синхронизации, если данные записываются в исходную базу данных, результаты сравнения могут быть несогласованными. При сравнении строк, если в инстансе кластера существует осиротевший документ или мигрируются фрагменты, количество возвращённых строк неверно, а результаты сравнения несогласованы. Для деталей см Официальная документация MongoDB.
Другие ограничения	Если исходная база данных не находится в инстансе кластера, во время инкрементной миграции поддерживаются следующие операции и команды: Создание и удаление баз данных Добавление, удаление и обновление документов Создание и удаление коллекций Создание и удаление индексов Создание и удаление представлений Поддерживаются команды convertToCapped, collMod и renameCollection. Во время полной+инкрементальной миграции между кластерами или из кластера в репликационный набор объекты, подлежащие миграции, не могут быть удалены. В противном случае задача миграции завершится неудачей. Если вы выбираете Кластер (MongoDB 4.0+) для Тип экземпляра исходной DB, DRS будет использовать функцию MongoDB change streams во время миграции. Обратите внимание на следующее перед использованием change streams: Подписка на данные с помощью change streams потребляет определённое количество CPU и памяти исходной базы данных. Оцените ресурсы исходной базы данных заранее. Если нагрузка на исходную базу данных высока, скорость обработки change streams не успевает за скоростью генерации oplog. В результате возникает задержка синхронизации DRS. Из-за ограничений MongoDB change streams, только удалить базу данных, удалить коллекцию, и переименовать DDL‑операторы поддерживаются во время инкрементной синхронизации. Когда документы вставляются или заменяются в коллекции исходной базы данных впервые, индексы коллекции будут синхронизированы с целевой базой данных. Если вам не нужно синхронизировать индексы, обратитесь в техническую поддержку. Типы данных DBPointer и DBRef не поддерживаются. В фазе инкрементной миграции,скорость миграции может достигать до 10 000 строк в одной таблице в секунду. В настоящее время только пользователи из белого списка могут использовать Change Streams. Если Тип экземпляра исходной 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, чтобы снизить влияние отказа отдельного узла на задачу миграции. Кроме того, убедитесь, что все узлы mongos принадлежат одному и тому же экземпляру кластера. Для инкрементальной миграции экземпляра кластера рекомендуется ввести информацию обо всех первичных и вторичных узлах шарда и убедиться, что вся информация об узлах относится к одному шарду, чтобы снизить влияние переключения первичного/вторичного узла на задачу миграции. Убедитесь, что все шарды принадлежат одному кластеру. В некоторых сценариях миграции, чтобы предотвратить удаление существующих коллекций в целевой базе данных операцией drop database, операция drop database не будет синхронизироваться с целевой базой данных. Если версия исходной базы данных ранее MongoDB 3.6, выполнение команды drop database удалит коллекции только из исходной базы данных. Коллекции в целевой базе данных не будут удалены. Если версия исходной базы данных MongoDB 3.6 или новее, операция drop database представлена операциями drop database и drop collection в oplog. Выполнение команды drop database удалит коллекции как из исходной, так и из целевой баз данных. Чтобы ускорить миграцию, удалите ненужные индексы из исходной базы данных и сохраните только необходимые индексы перед миграцией. Рекомендуется не создавать индексы для исходной базы данных во время миграции. Если индексы необходимо создать, создавайте их в фоновом режиме. Чтобы предотвратить обратный переход, не запускайте задачи, мигрирующие одну и ту же базу данных в облако и из облака одновременно.

Процедура

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

На Online Migration Management странице, нажмите Create Migration Task.

На Create Replication Instance странице, укажите имя задачи, описание и детали экземпляра репликации, и нажмите Create Now.

Task information description

Table 5 Task information
Parameter	Description
Task Name	Имя задачи должно начинаться с буквы и содержать от 4 до 50 символов. Оно может включать только буквы, цифры, дефисы (-) и знаки подчёркивания (_).
Описание	Описание может содержать до 256 символов и не может содержать специальные символы !=<>&'\"

Информация о репликации экземпляра

Таблица 6 Настройки репликации экземпляра
Параметр	Описание
Поток данных	Выбрать В облако. База данных назначения должна находиться в текущем облаке.
Исходный движок БД	Выбрать MongoDB.
Движок БД назначения	Выбрать DDS.
Тип сети	Доступные варианты: VPC, VPN или Direct Connect, и Общедоступная сеть. По умолчанию значение Общедоступная сеть. VPC подходит для миграций между облачными базами данных одной учетной записи в одном регионе и VPC. Общедоступная сеть подходит для миграций из локальных баз данных или внешних облачных баз данных в целевые базы данных. VPN или Direct Connect подходит для миграций из локальных баз данных в облачные базы данных или между базами данных в разных регионах в облаке с использованием VPN, Direct Connect, Cloud Connect, VPCEP или соединения VPC peering.
Экземпляр БД назначения	Выберите созданный вами экземпляр БД.
Подсеть экземпляра репликации	Подсеть, в которой находится экземпляр репликации. Вы также можете нажать Просмотр подсетей чтобы перейти в сетевую консоль и просмотреть подсеть, в которой находится экземпляр. По умолчанию, экземпляр DRS и целевой экземпляр DB находятся в одной подсети. Необходимо выбрать подсеть, в которой находится экземпляр DRS, и в которой имеются доступные IP-адреса. Чтобы обеспечить успешное создание экземпляра репликации, отображаются только подсети с включённым DHCP.
Тип миграции	Полный: Этот тип миграции подходит для сценариев, когда допускается прерывание сервиса. Он переносит все объекты и данные в нестандартных базах данных в целевую базу данных одновременно. Объекты включают наборы, представления и индексы. NOTE: Если вы выполняете полную миграцию, не выполняйте операции в исходной базе данных. В противном случае данные, сгенерированные в исходной базе данных во время миграции, не будут синхронизированы с целевой базой данных. Full+Incremental: Этот тип миграции позволяет переносить данные без прерывания сервисов. После того как полная миграция инициализирует целевую базу данных, запускается инкрементальная миграция и парсит логи, чтобы обеспечить согласованность данных между исходной и целевой базами данных. ПРИМЕЧАНИЕ: Если вы выберете Full+Incremental, данные, генерируемые во время полной миграции, будут непрерывно синхронизироваться с целевой базой данных, и источник останется доступным.
Тип экземпляра исходной БД	Если вы выберете Full+Incremental для Тип миграции, установите этот параметр на основе исходной базы данных. Если исходная база данных является кластерным экземпляром, установите этот параметр в Cluster. Если исходная база данных является набором реплик или экземпляром одиночного узла, установите этот параметр в Не кластерный.
Получить инкрементные данные	Если Тип экземпляра исходной DB установлен в Кластер и Режим миграции установлен в Полный+Инкрементный, вам необходимо определить, как фиксировать изменения данных во время инкрементной синхронизации. Также балансировщик исходной базы данных должен быть отключен и осиротевшие документы должны быть удалены. Для подробностей см oplog: Для MongoDB 3.2 или более новых версий DRS напрямую подключается к каждому шарду исходного экземпляра DB для извлечения данных. Если вы выбираете этот метод, вам необходимо ввести информацию о подключении к каждому шару в исходной базе данных при тестировании соединения между исходной базой данных и экземпляром DRS. changeStream: Этот метод рекомендуется. Для MongoDB 4.0 и новее DRS подключается к узлам mongs исходной базы данных для извлечения данных. Если вы выбираете этот метод, необходимо включить движок хранения WiredTiger в исходной базе данных.
Количество шардов источника	Если Тип экземпляра DB источника установлен Кластер и Получить инкрементные данные установлен oplog, необходимо ввести количество шардов исходной базы данных. Количество шардов источника варьируется от 2 до 64. Укажите этот параметр в зависимости от фактического количества шардов в исходной DB.
Укажите EIP	Этот параметр доступен, когда вы выбираете Общедоступная сеть для Тип сети. Выберите EIP, который будет привязан к экземпляру DRS. DRS автоматически привяжет указанный EIP к экземпляру DRS и отсоединит EIP после завершения задачи. Если Тип экземпляра исходной DB установлен в Кластер и Получить инкрементные данные установлен в oplog, число указанных EIP должно соответствовать количеству исходных шардов.

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

Enterprise проект и Теги

Таблица 8 Enterprise Проект и Теги
Параметр	Описание
Enterprise Проект	Enterprise проект, который вы хотите использовать для централизованного управления вашими облачными ресурсами и участниками. Выберите Enterprise проект из выпадающего списка. Проект по умолчанию default.
Теги	Теги задачу. Эта конфигурация необязательна. Добавление тегов помогает лучше идентифицировать и управлять вашими задачами. Каждая задача может иметь до 20 тегов. После создания задачи вы можете просмотреть детали её тегов на Теги вкладке. Подробности см. Управление тегами.

Note

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

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

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

Таблица 9 Информация об исходной базе данных
Параметр	Описание
mongos IP адрес или доменное имя	IP-адрес или доменное имя исходной базы данных в IP-адрес/Доменное имя:порт формат. Порт исходной базы данных. Диапазон: 1 - 65535 Можно ввести не более трёх групп IP‑адресов или доменных имён исходной базы данных. Несколько значений разделяйте запятыми (,). Например: 192.168.0.1:8080,192.168.0.2:8080. Убедитесь, что указанные IP‑адреса или доменные имена принадлежат одному шардированному кластеру. NOTE: Если введено несколько IP‑адресов или доменных имён, тестовое соединение считается успешным, если доступен хотя бы один IP‑адрес или доменное имя. Поэтому необходимо убедиться, что IP‑адрес или доменное имя указаны правильно.
База данных аутентификации	Имя базы данных аутентификации пользователя исходной базы данных MongoDB. Например: База данных аутентификации по умолчанию экземпляра DDS является admin.
mongos Имя пользователя	Имя пользователя узла mongos исходной базы данных MongoDB. Например, имя пользователя mongos по умолчанию экземпляра DDS является rwuser.
Пароль базы данных	Пароль для имени пользователя базы данных.
SSL Соединение	SSL шифрует соединения между исходной и целевой базами данных. Если SSL включён, загрузите корневой сертификат SSL CA. ПРИМЕЧАНИЕ: Максимальный размер отдельного файла сертификата, который можно загрузить, составляет 500 KB. Если SSL отключён, ваши данные могут быть под угрозой.
Шардированная база данных	Введите информацию о узлах шарда MongoDB базы данных в соответствии с числом узлов шарда кластера в исходной базе данных. Установите IP-адрес или доменное имя шардированной базы данных на тот же, что и у узла шарда в исходной базе данных MongoDB. Значение находится в IP-адрес/Доменное имя:Порт формат. Установите базу данных аутентификации шардированной базы данных в имя базы данных, к которой принадлежит аккаунт узла шарда исходной базы данных MongoDB. Например, базой данных аутентификации по умолчанию для шарда экземпляра DDS является admin. Установите имя пользователя шардированной базы данных таким же, как имя узла шарда в исходной базе данных MongoDB. Например, имя пользователя шарда по умолчанию для экземпляра DDS — sharduser.

Note

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

Конфигурация целевой базы данных

Таблица 10 Настройки целевой базы данных
Параметр	Описание
Имя экземпляра DB	Экземпляр DB, выбранный при создании задачи миграции. Этот параметр нельзя изменить.
База данных аутентификации	Имя базы данных аутентификации. Например: По умолчанию база данных аутентификации экземпляра DDS — admin.
Имя пользователя базы данных	Имя пользователя для доступа к целевой базе данных.
Пароль базы данных	Пароль для имени пользователя базы данных.
SSL-соединение	SSL шифрует соединения между исходной и целевой базами данных. Если SSL включён, загрузите корневой сертификат SSL CA. NOTE: Максимальный размер одного файла сертификата, который можно загрузить, — 500 КБ. Если SSL отключён, ваши данные могут быть под угрозой.

Note

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

На Установить задачу странице, выберите объекты миграции и нажмите Далее.

Таблица 11 Мигрировать объект
Параметр	Описание
Управление потоком	Вы можете выбрать, контролировать ли поток. Управление потоком применяется только в полной фазе. Да Вы можете задать максимальную скорость миграции, которая зависит от условий сети. Во время миграции скорость миграции каждой задачи (или каждой подзадачи в режиме многозадачности) не будет превышать установленный вами порог. Кроме того, вы можете задать диапазон времени в соответствии с требованиями вашего сервиса. Настройка скорости трафика обычно включает установку периода ограничения скорости и значения скорости трафика. Поток может контролироваться круглосуточно или в определённые временные диапазоны. Значение по умолчанию — Всегда. Можно задать максимум 10 временных диапазонов, они не могут пересекаться. Скорость потока должна быть установлена в соответствии со сценарием сервиса и не может превышать 9,999 MB/s. Нет Скорость миграции не ограничена, и исходящая полоса пропускания исходной базы данных используется максимально, что вызывает соответствующее потребление чтения на исходной базе данных. Например, если исходящая полоса пропускания исходной базы данных составляет 100 MB/s и используется 80% полосы, то потребление I/O на исходной базе данных равно 80 MB/s. ПРИМЕЧАНИЕ: Режим управления потоком действует только во время полной миграции. Вы также можете изменить режим управления потоком после создания задачи. Для деталей см Изменение режима управления потоком.
Миграция учетной записи	Учетные записи, подлежащие миграции, можно классифицировать по следующим типам: учетные записи, которые могут быть мигрированы, и учетные записи, которые не могут быть мигрированы. Вы можете выбрать, мигрировать учетные записи или нет. Учетные записи, которые нельзя мигрировать, или не выбранные учетные записи, не будут существовать в целевой базе данных. Убедитесь, что ваши сервисы не будут затронуты этими учетными записями. Да Если вам нужно мигрировать учетные записи, см Миграция учетных записей. Нет Во время миграции учетные записи и роли не мигрируют.
Migrate Object	В левой панели отображаются объекты исходной базы данных, а в правой панели — выбранные объекты. Вы можете выбрать миграцию всех объектов, таблиц или баз данных в зависимости от требований вашего сервиса. All: Все объекты в исходной базе данных мигрируются в целевую базу данных. После миграции имена объектов останутся такими же, как в исходной базе данных, и их нельзя будет изменить. Tables: Выбранные объекты уровня таблицы будут мигрированы. Databases: Выбранные объекты уровня базы данных будут мигрированы. Если исходная база данных изменена, нажмите в правом верхнем углу перед выбором объектов миграции, чтобы гарантировать, что выбираемые объекты взяты из изменённой исходной базы данных. NOTE: Если вы решите не мигрировать все базы данных, миграция может завершиться неудачей, поскольку объекты, такие как хранимые процедуры и представления, в базах данных, подлежащих миграции, могут иметь зависимости от других объектов, которые не мигрируются. Чтобы предотвратить сбой миграции, мигрируйте все базы данных. Если имя объекта содержит пробелы, пробелы до и после имени объекта не отображаются. Если в середине имени объекта находятся два или более последовательных пробела, отображается только один пробел. Имя выбранного объекта миграции не может содержать пробелы. Для быстрого выбора нужных объектов базы данных можно использовать функцию поиска.

На Check Task странице, проверьте задачу миграции.
- Если какая-либо проверка не прошла, проанализируйте причину и исправьте ошибку. После исправления ошибки нажмите Check Again.
- Если проверка завершена и коэффициент успешности проверки составляет 100%, нажмите Next.
  Note
  Вы можете перейти к следующему шагу только когда все проверки завершились успешно. Если есть элементы, требующие подтверждения, сначала просмотрите и подтвердите детали, а затем переходите к следующему шагу.

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

Таблица 12 Настройки запуска задачи
Параметр	Описание
Время начала	Установить Время начала по Запуск при создании задачи или Запуск в указанное время в зависимости от требований сайта. The Запуск в указанное время опция рекомендуется. NOTE: Миграционная задача может повлиять на производительность исходных и целевых баз данных. Рекомендуется запускать задачу в непиковые часы и зарезервировать два‑три дня для проверки данных.
Отправка уведомлений	Этот параметр необязателен. Если статус, метрика задержки или данные миграционной задачи являются аномальными, DRS отправит вам уведомление.
Тема SMN	Этот параметр доступен только после включения Отправка уведомлений и создать тему в консоли SMN и добавить подписчика.

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

Родительская тема: В облако

Предыдущая статья

От схемы MySQL и логической таблицы к DDM

Следующая статья

С PostgreSQL на PostgreSQL

Эта статья полезна?

Поддержка Юридические документы