Перенос базы данных PostgreSQL с помощью дампа и ее восстановление
Базу данных PostgreSQL можно извлечь в файл дампа с помощью pg_dump. Затем необходимо использовать pg_restore для восстановления базы данных PostgreSQL из файла архива, созданного pg_dump .
Предварительные требования
Прежде чем приступить к выполнению этого руководства, необходимы следующие компоненты:
-
с правилами брандмауэра, разрешающими доступ к этом серверу.
- Установленные программы командной строки pg_dump и pg_restore.
Создание файла дампа, содержащего необходимые для загрузки данные
Чтобы создать резервную копию базы данных PostgreSQL локально или на виртуальной машине, выполните следующую команду:
Например, если имеется локальный сервер с базой данных testdb, запустите на нем следующее:
Восстановление данных в целевую базу данных
После создания целевой базы данных можно воспользоваться командой pg_restore с параметром --dbname , чтобы восстановить данные в целевую базу данных из файла дампа.
При включении параметра --no-owner все объекты, созданные во время восстановления, будут присвоены пользователю, отмеченному --username . Дополнительные сведения см. в документации по PostgreSQL.
На серверах базы данных Azure для PostgreSQL соединения TLS и SSL включены по умолчанию. Если сервер PostgreSQL требует соединения TLS или SSL, но не содержит их, задайте переменную среды PGSSLMODE=require чтобы утилита pg_restore могла подключаться с помощью TLS. Без протокола TLS может появиться ошибка "FATAL: SSL connection is required. Please specify SSL options and retry." (Критическая ошибка: необходимо соединение SSL. Настройте SSL и повторите попытку). В командной строке Windows выполните команду SET PGSSLMODE=require перед выполнением команды pg_restore . В Linux или Bash выполните команду export PGSSLMODE=require перед выполнением команды pg_restore .
В этом примере необходимо восстановить данные из файла дампа testdb.dump в базу данных mypgsqldb на целевом сервере mydemoserver.postgres.database.azure.com.
Ниже приведен пример использования этого pg_restore для одиночного сервера:
Ниже приведен пример использования этого pg_restore для гибкого сервера:
Оптимизация процесса миграции
Один из способов миграции существующей базы данных PostgreSQL в службу баз данных Azure для PostgreSQL — это резервное копирование базы данных в источнике и ее восстановление в Azure. Чтобы свести к минимуму время, необходимое для завершения миграции, можно использовать следующие параметры с командами резервного копирования и восстановления.
Подробные сведения о синтаксисе см. в статьях о pg_dump и pg_restore.
Для резервного копированияСоздайте резервную копию с использованием параметра -Fc , чтобы можно было выполнять восстановление параллельно. Это позволит ускорить процесс. Пример:
Для восстановленияПереместите файл резервной копии на виртуальную машину Azure в том же регионе, в котором находится сервер базы данных Azure для PostgreSQL, на который выполняется миграция. Выполните pg_restore из этой виртуальной машины, чтобы снизить задержку в сети. Создание виртуальной машины с ускоренной сетью.
Откройте файл дампа, чтобы убедиться в том, что инструкции создания индекса находятся после вставки данных. Если это не так, переместите инструкции создания индекса после вставленных данных. Это должно быть сделано по умолчанию, но рекомендуется дополнительно проверить и подтвердить.
Для параллелизации восстановления необходимо выполнить восстановление с параметрами -Fc и -j (с номером). Указанное вами число — это количество ядер на целевом сервере. Вы также можете попробовать установить вдвое большее количество ядер целевого сервера, чтобы оценить нагрузку.
Ниже приведен пример использования этого pg_restore для одиночного сервера:
Ниже приведен пример использования этого pg_restore для гибкого сервера:
Файл дампа также можно отредактировать, добавив в его начале команду set synchronous_commit = off; , а в конце — команду set synchronous_commit = on; . Если не включить ее в конце, это может привести к последующей потере данных прежде, чем приложения изменят данные.
Перед восстановлением рассмотрите возможность выполнения следующих действий на целевом сервере Базы данных Azure для PostgreSQL.
Отключите отслеживание производительности запросов. Эти статистические данные не требуются во время миграции. Это можно сделать, установив для параметров pg_stat_statements.track , pg_qs.query_capture_mode и pgms_wait_sampling.query_capture_mode значение NONE .
Используйте SKU с высоким объемом ресурсов вычисления и памяти, например модель 32 vCore Memory Optimized (32 виртуальных ядра с оптимизацией для операций в памяти), чтобы ускорить миграцию. Вы можете легко вернуться к предпочитаемому SKU после завершения восстановления. Чем выше номер SKU, тем большего параллелизма можно достичь, увеличив значение соответствующего параметра -j в команде pg_restore .
Увеличьте число операций ввода-вывода в секунду на целевом сервере — это может улучшить производительность восстановления. Вы можете подготовить больше операций ввода-вывода в секунду, увеличив объем хранилища на сервере. Этот параметр необратим, но стоит принять во внимание, будет ли большее количество операций ввода-вывода в секунду полезным для вашей рабочей нагрузки в будущем.
Не забудьте проверить и протестировать эти команды в тестовой среде, прежде чем использовать их в рабочей среде.