Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В этой статье описывается, как перенести базу данных PostgreSQL из Google Cloud SQL для PostgreSQL в Azure Database для PostgreSQL онлайн.
Служба миграции в База данных Azure для PostgreSQL — это полностью управляемая служба, интегрированная в портал Azure и Azure CLI. Он предназначен для упрощения перехода на сервер База данных Azure для PostgreSQL.
- Предварительные условия
- Выполните миграцию
- Отслеживайте ход миграции.
- Переключение
- Проверьте миграцию после завершения
Предварительные условия
Чтобы завершить миграцию, вам потребуется следующее:
Перед началом миграции с помощью службы миграции База данных Azure для PostgreSQL важно выполнить следующие предварительные требования, специально предназначенные для сценариев миграции через Интернет.
- Проверка исходной версии
- Установка test_decoding — исходная настройка
- Настройка целевой установки
- Включение CDC в качестве источника
- Настройка настройки сети
- Включение расширений
- Проверка параметров сервера
- Проверка пользователей и ролей
Проверка исходной версии
Исходная версия сервера PostgreSQL должна быть 9.5 или более поздней.
Если исходная версия PostgreSQL меньше 9.5, перед началом миграции обновите ее до версии 9.5 или более поздней.
Примечание.
Сервис миграции в базе данных Azure для PostgreSQL поддерживает подключения с помощью IP-адреса для исходного сервера Google Cloud SQL для PostgreSQL. Формат myproject:myregion:myinstance
не поддерживается.
Установка test_decoding — настройка источников
- test_decoding получает WAL через логический механизм декодирования и декодирует его в текстовые представления выполненных операций.
- В Google Cloud SQL для PostgreSQL подключаемый модуль test_decoding предварительно установлен и готов к логической репликации. Это позволяет легко настраивать слоты логической репликации и выполнять потоковую передачу изменений журналов транзакций (WAL), упрощая такие варианты использования, как запись измененных данных (CDC) или репликация во внешние системы.
- Дополнительные сведения о подключаемом модуле для декодирования тестов см. в документации по PostgreSQL.
Настройка целевой установки
- Перед миграцией необходимо создать Azure Database for PostgreSQL – Flexible server.
- Номер SKU, подготовленный для базы данных Azure для PostgreSQL — гибкого сервера, должен соответствовать источнику.
- Чтобы создать новую базу данных Azure для PostgreSQL, посетите гибкий сервер базы данных Azure для PostgreSQL.
Включение CDC в качестве источника
-
test_decoding
Подключаемый модуль логического декодирования записывает измененные записи из источника. - Чтобы убедиться, что у пользователя миграции есть необходимые привилегии репликации, выполните следующую команду SQL:
Alter user <<username>> with REPLICATION;
Перейдите к экземпляру Google Cloud SQL PostgreSQL в Google Cloud Console, выберите имя экземпляра, чтобы открыть страницу сведений, нажмите кнопку "Изменить" и в разделе "Флаги" измените следующие флаги:
- Установка флага
cloudsql.logical_decoding = on
- Задайте для флага
max_replication_slots
значение больше одного; значение должно быть больше числа баз данных, выбранных для миграции. - Задайте для флага
max_wal_senders
значение больше одного. Оно должно быть по крайней мере таким же, какmax_replication_slots
, и число отправителей, уже используемых в вашем экземпляре. - Флаг
wal_sender_timeout
завершает неактивные подключения репликации, если они дольше указанного количества миллисекунд. Установка значения 0 (ноль) отключает механизм времени ожидания и является допустимым параметром для миграции.
- Установка флага
На целевом гибко настроенном сервере, чтобы предотвратить нехватку места для хранения журналов во время онлайн-миграции, убедитесь, что у вас достаточно места в табличном пространстве с помощью зарезервированного управляемого диска. Чтобы добиться этого, отключите параметр
azure.enable_temp_tablespaces_on_local_ssd
сервера в течение срока миграции и восстановите его в исходном состоянии после миграции.
Настройка настройки сети
Настройка сети имеет решающее значение для правильной работы службы миграции. Убедитесь, что исходный сервер PostgreSQL может взаимодействовать с целевым сервером База данных Azure для PostgreSQL. Следующие конфигурации сети необходимы для успешной миграции.
Для получения информации о настройке сети см. Руководство по сетям для службы миграции.
Включение расширений
Чтобы обеспечить успешную миграцию с помощью службы миграции в База данных Azure для PostgreSQL, может потребоваться проверить расширения для исходного экземпляра PostgreSQL. Расширения предоставляют функциональные возможности и функции, которые могут потребоваться для приложения. Перед началом процесса миграции проверьте расширения в исходном экземпляре PostgreSQL.
В целевом экземпляре гибкого сервера Базы данных Azure для PostgreSQL включите поддерживаемые расширения, которые определены в исходном экземпляре PostgreSQL.
Дополнительные сведения см. в разделе "Расширения" в База данных Azure для PostgreSQL.
Примечание.
При внесении изменений в shared_preload_libraries
параметр требуется перезапуск.
Проверка параметров сервера
Эти параметры не переносятся автоматически в целевую среду и должны быть настроены вручную.
Сопоставьте значения параметров сервера из исходной базы данных PostgreSQL с базой данных Azure для PostgreSQL, получив доступ к разделу "Параметры сервера" в портале Azure и вручную обновив соответствующие значения.
Сохраните изменения параметров и перезапустите База данных Azure для PostgreSQL, чтобы применить новую конфигурацию при необходимости.
Проверка пользователей и ролей
При миграции в База данных Azure для PostgreSQL важно решить проблему миграции пользователей и ролей отдельно, так как им требуется ручное вмешательство:
Миграция пользователей и ролей вручную. Пользователи и связанные с ними роли должны быть перенесены вручную в База данных Azure для PostgreSQL. Чтобы упростить этот процесс, можно использовать
pg_dumpall
служебную программу с флагом--globals-only
для экспорта глобальных объектов, таких как роли и учетные записи пользователей. Выполните следующую команду, заменив<<username>>
фактическое имя пользователя и<<filename>>
требуемое имя выходного файла:pg_dumpall --globals-only -U <<username>> -f <<filename>>.sql
Ограничение на роли суперпользователя: База данных Azure для PostgreSQL не поддерживает роли суперпользователя. Таким образом, перед миграцией пользователям с привилегиями суперпользователя должны быть удалены эти привилегии. Убедитесь, что разрешения и роли настроены соответствующим образом.
Выполнив следующие действия, вы можете убедиться, что учетные записи пользователей и роли правильно перенесены в База данных Azure для PostgreSQL без возникновения проблем, связанных с ограничениями суперпользователя.
Отключите высокую доступность (надежность) и реплики чтения в целевой системе
Отключение высокого уровня доступности (надежности) и чтение реплик в целевой среде является важным. Эти функции должны быть включены только после завершения миграции.
Следуя этим рекомендациям, вы можете гарантировать плавный процесс миграции без добавленных переменных, представленных высокой доступностью и репликациями чтения. После завершения миграции и стабильной базы данных вы можете включить эти функции для повышения доступности и масштабируемости среды базы данных в Azure.
Выполните миграцию
Вы можете перенести посредством портала Azure или Azure CLI.
Портал Azure предоставляет простой и интуитивно понятный интерфейс на основе мастера, который поможет вам выполнить миграцию. Следуя инструкциям, описанным в этом руководстве, вы можете легко перенести базу данных в гибкий сервер Базы данных Azure для PostgreSQL и воспользоваться ее мощными функциями и масштабируемостью.
Чтобы выполнить миграцию с помощью портал Azure, сначала настройте задачу миграции, подключитесь к источнику и целевому объекту, а затем выполните миграцию.
Настройка задачи миграции
Служба миграции поставляется с простым пошаговым процессом на портале Azure. Вот как начать работу:
Откройте веб-браузер и перейдите на портал. Введите свои учетные данные для входа. Панель мониторинга службы является представлением по умолчанию.
Перейдите к целевому объекту в рамках Гибкого сервера Базы данных Azure для PostgreSQL.
На вкладке "Обзор гибкого сервера" в меню слева, прокрутите вниз до пункта "Миграция" и выберите его.
Нажмите кнопку "Создать ", чтобы перейти из Google Cloud SQL для PostgreSQL на гибкий сервер Базы данных Azure для PostgreSQL. Если вы впервые используете службу миграции, пустая сетка появится с запросом на начало первой миграции.
Если вы уже настроили миграции в целевой базе данных Azure для PostgreSQL, таблица содержит сведения о выполненных попытках миграции.
Выберите кнопку Создать. Затем вы пройдете через ряд вкладок, управляемых мастером, чтобы выполнить миграцию в целевой объект Azure Database для PostgreSQL из исходного экземпляра PostgreSQL.
Настройка
Первая вкладка — вкладка "Настройка ", где пользователю необходимо предоставить сведения о миграции, например тип источника имени миграции, чтобы инициировать миграцию.
Имя миграции — это уникальный идентификатор для каждой операции миграции в этот целевой объект в рамках Гибкого сервера. Это поле принимает только буквенно-цифровые символы и не принимает специальные символы, кроме дефиса (-). Имя не может начинаться с дефиса и должно быть уникальным для целевого сервера. Две операции миграции в один и тот же целевой объект в рамках Гибкого сервера не могут иметь одинаковые имена.
Тип исходного сервера— в зависимости от источника PostgreSQL можно выбрать соответствующий тип источника, например облачную службу PostgreSQL, локальную установку или виртуальную машину.
Параметр миграции позволяет выполнять проверки перед активацией миграции. Вы можете выбрать любой из следующих вариантов:
- Проверка. Проверяет готовность сервера и базы данных к миграции в целевой объект.
- Миграция — пропускает проверки и запускает миграцию.
- Проверка и миграция— выполняет проверку перед активацией миграции. Миграция активируется только в том случае, если нет сбоев проверки.
Выбор вариантов Проверка или Проверка и миграция всегда рекомендуется при выполнении валидации до миграции. Для получения информации о валидации перед миграцией см. эту документацию.
- Режим миграции позволяет выбрать режим миграции. Оффлайн — это параметр по умолчанию.
Нажмите кнопку "Далее: подключение к источнику".
Выбор сервера среды выполнения
Сервер среды выполнения миграции — это специализированная функция в службе миграции, предназначенная для работы в качестве промежуточного сервера во время миграции. Это отдельный гибкий экземпляр базы данных Azure для PostgreSQL, который не является целевым сервером, но используется для упрощения миграции баз данных из исходной среды, доступной только через частную сеть.
Для получения дополнительной информации о сервере среды выполнения посетите сервер среды выполнения миграции.
Подключение к источнику
Вкладка "Подключение к источнику " предлагает указать сведения, связанные с источником, выбранным на вкладке "Настройка", который является источником баз данных.
- Имя сервера— укажите имя узла или IP-адрес исходного экземпляра PostgreSQL.
- Порт — номер порта исходного сервера
- Имя входа администратора сервера — имя пользователя исходного сервера PostgreSQL
- Пароль — пароль исходного сервера PostgreSQL
- Режим SSL— поддерживаемые значения предпочтительнее и обязательны. Если SSL на сервере Source PostgreSQL имеет значение OFF, используйте SSLMODE=prefer. Если SSL на исходном сервере имеет значение ON, используйте SSLMODE=require. Значения SSL можно определить в файле Postgresql.conf.
- Проверка подключения— выполняет тест подключения между целевым объектом и источником. После успешного подключения пользователи смогут продолжить следующий шаг. В противном случае необходимо определить сетевые проблемы между целевым объектом и источником и проверить имя пользователя или пароль для источника. Установка тестового подключения занимает несколько минут.
После успешного тестового подключения нажмите кнопку "Далее: выбрать целевой объект миграции"
Выбор целевого объекта миграции
На вкладке "Выбор целевого объекта миграции" отображаются метаданные для целевого объекта гибкого сервера, например имя подписки, группа ресурсов, имя сервера, расположение и версия PostgreSQL.
- Имя администратора — имя администратора целевого сервера PostgreSQL
- Пароль — пароль целевого сервера PostgreSQL
-
Настраиваемое полное доменное имя или IP-адрес (необязательно): настраиваемое полное доменное имя/IP-адрес является необязательным и может использоваться, если целевой объект находится за пользовательским DNS-сервером или имеет пользовательские пространства имен DNS, что делает его доступным только через определенные полные доменные имена или IP-адреса. Например, это может включать такие записи, как
flexibleserver.example.com
,198.1.0.2
или полное доменное имя PostgreSQL, напримерflexibleserver.postgres.database.azure.com
, если пользовательский DNS-сервер содержит DNS-зонуpostgres.database.azure.com
или перенаправляет запросы для этой зоны на168.63.129.16
, где полное доменное имя разрешается в общедоступной или частной зоне DNS Azure. - Проверка подключения — выполняет тест подключения между целевым объектом и источником. После успешного подключения пользователи смогут продолжить следующий шаг. В противном случае необходимо определить сетевые проблемы между целевым объектом и источником и проверить имя пользователя или пароль для целевого объекта. Проверка подключения занимает несколько минут, чтобы установить соединение между целевым объектом и источником.
После успешного тестового подключения нажмите кнопку Next: Select Database(s) for Migration (Выбор баз данных) для миграции
Выбор баз данных для миграции
На этой вкладке список пользовательских баз данных находится на исходном сервере, выбранном на вкладке установки. Вы можете выбрать и перенести до восьми баз данных в одной попытке миграции. Если существует более восьми пользовательских баз данных, процесс миграции повторяется между исходными и целевыми серверами для следующего набора баз данных.
После выбора баз данных нажмите кнопку "Далее: Сводка"
Итоги
На вкладке "Сводка " приведены все сведения о источнике и целевом объекте для создания проверки или миграции. Просмотрите сведения и нажмите кнопку "Пуск".
Отслеживайте ход миграции.
После нажатия кнопки "Пуск" появится уведомление через несколько секунд, указывающее, что проверка или создание миграции успешно выполнено. Затем вы будете автоматически перенаправлены на страницу миграции гибкого сервера, где будет добавлена новая запись для недавно созданной проверки или миграции.
Сетка, отображающая миграцию, содержит следующие столбцы: имя, состояние, режим миграции, тип миграции, исходный сервер, тип исходного сервера, базы данных, длительность и время начала. Записи отображаются в порядке убывания времени начала с последней записью в верхней части. Для обновления состояния проверки или миграции можно использовать кнопку обновления. Выберите имя миграции в сетке, чтобы просмотреть связанные сведения.
При создании проверки или миграции процесс переходит в состояние InProgress и подложку PerformingPreRequisiteSteps. Рабочий процесс занимает 2–3 минуты, чтобы настроить инфраструктуру миграции и сетевые подключения.
Сведения о переносе
На вкладке "Настройка" выбран параметр миграции в качестве "Миграция" и "Проверка". В этом сценарии проверки выполняются сначала перед началом миграции. После завершения PerformingPreRequisiteSteps рабочий процесс переходит в подсостояние идёт проверка.
- Если проверка имеет ошибки, миграция переходит в состояние сбоя .
- Если проверка завершается без ошибок, начинается миграция и рабочий процесс переходит в подстаток миграции данных.
Результаты проверки и миграции можно просмотреть на уровне экземпляра и базы данных.
Некоторые возможные состояния миграции:
Состояния миграции
Государство | Описание |
---|---|
InProgress | Выполняется настройка инфраструктуры миграции или выполняется фактическая миграция данных. |
Отменено | Миграция отменена или удалена. |
Неудачно | Миграция не удалась. |
Сбой проверки | Проверка не пройдена. |
Успешно | Миграция прошла успешно и завершена. |
WaitForUserAction | Применимо только для миграции через Интернет. Ожидание действия пользователя для выполнения переключения. |
Подсостояния миграции
Подсостояние | Описание |
---|---|
ВыполнениеПредварительныхШагов | Настройка инфраструктуры выполняется для миграции данных. |
Проверка в процессе выполнения | Проверка выполняется. |
MigratingData | Выполняется миграция данных. |
ЗавершениеМиграции | Миграция находится на заключительных этапах завершения. |
Завершено | Миграция завершена. |
Неудачно | Миграция не удалась. |
Подсостояния валидации
Подсостояние | Описание |
---|---|
Неудачно | Ошибка валидации. |
Успешно | Проверка выполнена успешно. |
Предупреждения | Проверка отображается в предупреждении. |
Переключение
Если есть как "Миграция", так и "Проверка и миграция", выполнение миграции через интернет требует дополнительного шага: пользователь должен выполнить действие "Переключение". После завершения копирования или клонирования базовых данных миграция переходит к состоянию WaitingForUserAction
и подсостоянию WaitingForCutoverTrigger
. В этом состоянии пользователь может инициировать переход на портале, выбрав миграцию.
Прежде чем инициировать переключение, важно убедиться в том, что:
Записи в источник остановлены —
Latency
значение равно 0 или близко к 0. СведенияLatency
можно получить на экране сведений о миграции, как показано ниже:latency
Значение уменьшается до 0 или близко к 0Значение
latency
указывает, когда целевой объект последний раз синхронизирован с источником. На этом этапе запись в источник данных может быть остановлена, и можно инициировать процесс переключения. В случае, если на исходном источнике большой трафик, рекомендуется сначала остановить операции записи, чтобы показательLatency
приблизился к 0, а затем инициировать переключение на другой источник. Операция переключения применяет все ожидающие изменения из источника на целевой объект и завершает миграцию. Если вы активируете "Cutover" даже при ненулевойLatency,
, репликация останавливается до этого момента. Все данные остаются на источнике до момента переключения на целевой объект. Предположим, что задержка составила 15 минут в точке переключение, поэтому все измененные данные за последние 15 минут применяются к целевому объекту. Время зависит от очереди изменений, произошедших за последние 15 минут. Поэтому рекомендуется, чтобы задержка достигла нуля или почти нуля, прежде чем выполнить переключение.Миграция переходит в состояние
Succeeded
, когда подстатMigrating Data
или переключение режимов (при онлайн-миграции) успешно завершается. Если вMigrating Data
подсостоянии возникает проблема, миграция переходит вFailed
состояние.
Проверьте миграцию после завершения
После завершения баз данных необходимо вручную проверить данные между источником и целевым объектом и убедиться, что все объекты в целевой базе данных успешно созданы.
После миграции можно выполнить следующие задачи:
- Проверьте данные на гибком сервере и убедитесь, что это точная копия исходного источника.
- После проверки включите параметр высокой доступности на гибком сервере по мере необходимости.
- Измените номер SKU гибкого сервера в соответствии с потребностями приложения. Для этого изменения требуется перезапуск сервера базы данных.
- При изменении параметров сервера из значений по умолчанию в исходном экземпляре скопируйте эти значения параметров сервера на гибком сервере.
- Скопируйте другие параметры сервера, такие как теги, оповещения и правила брандмауэра (если применимо), из исходного экземпляра на гибкий сервер.
- Внесите изменения в приложение, чтобы указать строку подключения на сервер с гибкими настройками.
- Внимательно отслеживайте производительность базы данных, чтобы узнать, требуется ли настройка производительности.