Миграция с помощью службы воспроизведения журналов (LRS)
Служба воспроизведения журналов (LRS) — это средство, которое позволяет пользовательским миграциям баз данных с локальных СЕРВЕРОВ SQL Server в Управляемый экземпляр SQL в облаке. Он использует технологию доставки журналов и полезен в тех случаях, когда требуется больше элементов управления, если не требуется простой или когда служба Azure Data Migration Service не может использоваться.
LRS можно использовать непосредственно с помощью командлетов PowerShell, командлетов CLI или API для ручной сборки и оркестрации миграции баз данных в Управляемый экземпляр SQL. Ниже приведены некоторые причины, по которым следует рассмотреть возможность использования LRS:
- Дополнительные возможности контроля над проектом миграции базы данных
- Мало допустимости простоя при переходе на миграцию
- Неспособность установить исполняемый файл DMS в среде
- Отсутствие доступа к файлам к резервным копиям базы данных
- Неспособность открывать сетевые порты из среды в Azure
Общие сведения о типах миграции
Для LRS доступны два режима миграции.
| Режим | Description | Рекомендуется для | Доступность цепочки резервных копий |
|---|---|---|---|
| Автозавершение | Автоматически завершает миграцию при восстановлении последнего файла резервной копии. | Пассивные рабочие нагрузки | Вся цепочка резервных копий должна быть доступна заранее |
| Непрерывные | Непрерывно сканирует новые файлы резервного копирования и восстанавливает их, что позволяет перехватывать данные. | Активные рабочие нагрузки | Цепочку резервного копирования можно добавить во время миграции |
Независимо от режима, планируйте выполнить миграцию в течение 30 дней, так как задание LRS будет автоматически отменено после этого времени.
Защита процесса миграции
Для запуска LRS необходимо иметь одну из следующих ролей Azure: владелец подписки, Управляемый экземпляр SQL участник или пользовательская роль с разрешениемMicrosoft.Sql/managedInstances/databases/*.
Требуется учетная запись Хранилище BLOB-объектов Azure и работает в качестве промежуточного хранилища для файлов резервного копирования между экземпляром SQL Server и Управляемый экземпляр SQL. Чтобы использовать хранилище BLOB-объектов Azure с брандмауэром, требуется другая конфигурация. Необходимо добавить подсеть Управляемый экземпляр SQL в правила брандмауэра виртуальной сети учетной записи хранения с помощью делегирования подсети MI и конечной точки службы служба хранилища. Кроме того, для доступа к учетной записи Хранилище BLOB-объектов Azure можно использовать маркер SAS или управляемое удостоверение, но не оба.
Повышение производительности резервного копирования и восстановления
Вы можете разделить полные и разностные резервные копии на несколько файлов, а не использовать один файл, чтобы повысить производительность резервного копирования и восстановления. Это связано с тем, что для параллельного чтения или записи нескольких файлов уменьшается время, необходимое для завершения операции резервного копирования или восстановления.
Кроме того, включение сжатия резервных копий может повысить скорость сетевой передачи. Сжатые резервные копии меньше размера, что означает, что они занимают меньше времени для передачи по сети. Это может быть особенно полезно при передаче больших резервных копий в Azure или из нее.
Настоятельно рекомендуется включить CHECKSUM резервное копирование, даже если это не требуется. Управляемый экземпляр SQL выполняет проверка целостности для резервных копий без CHECKSUMнеобходимости увеличивать время восстановления базы данных. Включив CHECKSUM, можно ускорить операции восстановления.