Обновление базы данных PostgreSQL с помощью дампа и восстановление

  • Статья

Область применения: отдельный сервер Базы данных Azure для PostgreSQL

Внимание

База данных Azure для PostgreSQL — одиночный сервер находится на пути выхода на пенсию. Настоятельно рекомендуется выполнить обновление до База данных Azure для PostgreSQL — гибкий сервер. Дополнительные сведения о миграции на База данных Azure для PostgreSQL — гибкий сервер см. в статье "Что происходит с одним сервером База данных Azure для PostgreSQL?".

Примечание.

Концепции, описанные в этой документации, применимы как к Базе данных Azure для PostgreSQL —отдельный сервер, так и к Базе данных Azure для PostgreSQL — гибкий сервер.

Вы можете обновить сервер PostgreSQL, развернутый в Базе данных Azure для PostgreSQL, перенеся базы данных на сервер более поздней основной версии, используя приведенные ниже методы.

  • Автономный метод с использованием PostgreSQL pg_dump и pg_restore, при котором во время переноса данных возникает простой. В этом документе рассматривается именно этот метод обновления и переноса.
  • Сетевой метод с использованием Database Migration Service (DMS). Этот метод обеспечивает сокращение времени простоя миграции и поддерживает синхронизацию целевой базы данных с исходной, и вы можете выбирать, когда выполнять отключение. Однако существует несколько предварительных условий и ограничений для использования DMS. Дополнительные сведения см. в документации по DMS.
  • Метод обновления основной версии на месте с помощью База данных Azure для PostgreSQL — гибкий сервер. На месте функция обновления основной версии выполняет обновление основной версии сервера с помощью щелчка мыши. Это упрощает процесс обновления, минимизируя нарушения доступа пользователей и приложений к серверу. Обновления на месте — это более простой способ обновления основной версии экземпляра, так как он сохраняет имя сервера и другие параметры текущего сервера после обновления и не требует миграции данных или изменений в приложениях строка подключения. Обновления на месте выполняются быстрее и требуют меньшего времени простоя, чем перенос данных.

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

База данных или сценарий Дамп или восстановление (автономно) DMS (в сети)
У вас небольшая база данных, и вы можете позволить себе простой при обновлении. X
Небольшие базы данных (< 10 ГБ) X X
Средние базы данных (10–100 ГБ) X X
Большие базы данных (> 100 ГБ) X
Допускается простой при обновлении (независимо от размера базы данных) X
Возможно ли выполнение предварительных условий DMS, включая перезагрузку? X
Можно ли избежать операций DDL и незанесенных в журнал таблиц во время процесса обновления? X

Это руководство содержит несколько методов автономной миграции и примеры, демонстрирующие, как можно выполнить миграцию с исходного сервера на целевой сервер, на котором работает более поздняя версия PostgreSQL.

Примечание.

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

Предварительные условия для использования дампа и восстановления для Базы данных Azure для PostgreSQL

Чтобы приступить к выполнению этого руководства, вам потребуются следующее:

  • Исходный сервер базы данных PostgreSQL с более ранней версией ядра, которое требуется обновить.
  • Целевой сервер базы данных PostgreSQL с требуемой основной версией Базы данных Azure для PostgreSQL на отдельном сервере или Базы данных Azure для PostgreSQL на гибком сервере.
  • Клиентская система PostgreSQL для выполнения команд dump и restore. Рекомендуется использовать более высокую версию базы данных. Например, если вы обновляетесь с PostgreSQL версии 9.6 до 11, используйте клиент PostgreSQL версии 11.
    • Это может быть клиент Linux или Windows, на котором установлена среда PostgreSQL и программы командной строки pg_dump и pg_restore.
    • Кроме того, можно использовать Azure Cloud Shell или выбрать Azure Cloud Shell в строке меню в правом верхнем углу портала Azure. Перед выполнением команд dump и restore потребуется выполнить вход в учетную запись: az login.
  • Клиент PostgreSQL лучше всего запускать в том же регионе, что и исходный и целевой серверы.

Дополнительные сведения и рекомендации

  • Строку подключения к исходным и целевым базам данных можно найти, щелкнув "Строки подключения" на портале.
  • Возможно, на сервере выполняется несколько баз данных. Список баз данных можно найти, подключившись к исходному серверу и выполнив команду \l.
  • Создайте соответствующие базы данных на целевом сервере баз данных или добавьте параметр -C в команду pg_dump, которая создает базы данных.
  • Не следует обновлять azure_maintenance или базы данных шаблонов. Если вы внесли какие-либо изменения в базы данных шаблонов, можно перенести эти изменения или внести их в целевую базу данных.
  • Ознакомьтесь с приведенными выше таблицами, чтобы определить, какая база данных подходит для этого режима миграции.
  • Если вы хотите использовать Azure Cloud Shell, обратите внимание на то, что время ожидания сеанса истекает через 20 минут. Если размер Вашей базы данных составляет < 10 ГБ, вы можете выполнить обновление без истечения времени ожидания сеанса. В противном случае вам, возможно, придется держать сеанс открытым другими способами, например, нажимая любую клавишу каждые 10–15 минут.

Пример базы данных, используемый в этом руководстве

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

Description Value
Исходный сервер (версии 9.5) pg-95.postgres.database.azure.com
База данных-источник bench5gb
Размер базы данных-источника 5 ГБ
Имя пользователя источника pg@pg-95
Целевой сервер (версии 11) pg-11.postgres.database.azure.com
Целевая база данных bench5gb
Имя целевого пользователя pg@pg-11

Примечание.

Гибкий сервер поддерживает PostgreSQL 11 и более поздней версии. Кроме того, имя пользователя гибкого сервера не требуется @dbservername.

Обновление баз данных с помощью автономных методов миграции

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

  • Если вы используете тот же пароль для источника и целевой базы данных, можно задать PGPASSWORD=yourPassword переменную среды. После этого вам не придется указывать пароль при каждом выполнении команд, таких как psql, pg_dump и pg_restore. Аналогичным образом можно настроить дополнительные переменные, например PGUSER, PGSSLMODE и т. д. (см. раздел Переменные среды PostgreSQL).

  • Если серверу PostgreSQL требуются TLS/SSL-соединения (они используются по умолчанию на серверах Базы данных Azure для PostgreSQL), задайте переменную среды PGSSLMODE=require, чтобы инструмент pg_restore подключался через протокол TLS. Без протокола TLS может отобразиться такая ошибка: FATAL: SSL connection is required. Please specify SSL options and retry.

  • В командной строке Windows выполните команду SET PGSSLMODE=require перед выполнением команды pg_restore. В Linux или Bash выполните команду export PGSSLMODE=require перед выполнением команды pg_restore.

Внимание

Действия и методы, описанные в этом документе, — дать некоторые примеры команд pg_dump/pg_restore и не представляют всех возможных способов выполнения обновлений. Перед их использованием в рабочей среде рекомендуется протестировать и проверить команды в тестовой среде.

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

Роли (пользователи) — это глобальные объекты, которые необходимо перенести отдельно в новый кластер перед восстановлением базы данных. Можно использовать двоичный файл pg_dumpall с параметром -r (--roles-only) для создания дампа. Чтобы дампать все роли с паролями из исходного отдельного сервера, выполните следующие действия.

pg_dumpall -r --host=mySourceServer --port=5432 --username=myUser@mySourceServer --database=mySourceDB > roles.sql

Чтобы дампать все имена ролей без паролей с исходного гибкого сервера: 

pg_dumpall -r --no-role-passwords --host=mySourceServer --port=5432 --username=myUser --database=mySourceDB > roles.sql

Внимание

В База данных Azure для PostgreSQL — пользователи гибкого сервера не могут получить доступ к таблице pg_authid, содержащей сведения об идентификаторах авторизации базы данных вместе с паролями пользователя. Поэтому получение паролей для пользователей невозможно. Рекомендуется использовать Azure Key Vault для безопасного хранения секретов.

Отредактируйте roles.sql и удалите ссылки NOSUPERUSER и NOBYPASSRLS перед восстановлением содержимого с помощью psql на целевом сервере:

psql -f roles.sql --host=myTargetServer --port=5432 --username=myUser --dbname=postgres

Скрипт дампа не должен выполняться полностью без ошибок. В частности, поскольку скрипт выдает CREATE ROLE для каждой роли, существующей в исходном кластере, определенно, чтобы получить ошибку "роль уже существует" для суперпользователя начальной загрузки, например azure_pg_admin или azure_superuser. Эта ошибка безвредна, ее можно игнорировать. Использование параметра --clean может привести к появлению дополнительных сообщений о безвредных ошибках для несуществующих объектов, но их можно минимизировать, добавив --if-exists.

Метод 1. Использование pg_dump и psql

Этот метод состоит из двух этапов. Во-первых, создайте дамп файла SQL с исходного сервера с помощью pg_dump. Вторым шагом является импорт файла на целевой сервер с помощью psql. Дополнительные сведения см. в документе Перенос с использованием экспорта и импорта.

Метод 2. Использование pg_dump и pg_restore

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

Метод 3. Использование потоковой передачи данных дампа в целевую базу данных

Если у вас нет клиента PostgreSQL или вы хотите использовать Azure Cloud Shell, можно использовать этот метод. Дамп базы данных передается непосредственно на целевой сервер базы данных и не сохраняет дампа в клиенте. Этот метод можно использовать для клиента с ограниченным хранилищем, и его даже можно выполнять из Azure Cloud Shell.

  1. Убедитесь, что база данных существует на целевом сервере, с помощью команды \l. Если база данных не существует, создайте базу данных.

     psql "host=myTargetServer port=5432 dbname=postgres user=myUser password=###### sslmode=mySSLmode"

    postgres> \l   
postgres> create database myTargetDB;

  2. Запустите создание дампа и восстановите в одной командной строке с помощью канала.

    pg_dump -Fc --host=mySourceServer --port=5432 --username=myUser --dbname=mySourceDB | pg_restore  --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB

    Например,

    pg_dump -Fc --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb | pg_restore --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb

  3. После завершения процесса обновления (миграции) можно протестировать приложение на целевом сервере.

  4. Повторите эту процедуру для всех баз данных на сервере.

Например, в следующей таблице показано время, затраченное на миграцию с помощью метода потоковой передачи дампа. Пример данных заполняется с помощью pgbench. Так как база данных может иметь разное количество объектов с различными размерами, чем созданные pgbench таблицы и индексы, настоятельно рекомендуется протестировать дамп и восстановить базу данных, чтобы понять фактическое время, необходимое для обновления базы данных.

Размер базы данных Примерное затраченное время
1 ГБ 1–2 минуты
5 ГБ 8–10 минут
10 ГБ 15-20 минут
50 ГБ 1–1,5 часа
100 ГБ 2,5–3 часа

Метод 4. Использование параллельного создания дампа и восстановления

Этот метод можно рассматривать, если в базе данных имеется несколько больших таблиц и необходимо распараллелить процесс создания дампа и восстановления этой базы данных. Кроме того, в клиентской системе должно быть достаточно места для размещения резервных дампов. Этот параллельный процесс создания дампа и восстановления сокращает время, необходимое для завершения всей миграции. Например, миграция базы данных pgbench размером в 50 ГБ методами 1 и 2 заняла 1–1,5 часа, тогда как на ее перенос этим методом потребовалось меньше 30 минут.

  1. Для каждой базы данных на исходном сервере создайте соответствующую базу данных на целевом сервере.

    psql "host=myTargetServer port=5432 dbname=postgres user=myuser password=###### sslmode=mySSLmode"

    postgres> create database myDB;

    Например,

    psql "host=pg-11.postgres.database.azure.com port=5432 dbname=postgres user=pg@pg-11 password=###### sslmode=require"
psql (12.3 (Ubuntu 12.3-1.pgdg18.04+1), server 13.3)
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.

postgres> create database bench5gb;
postgres> \q

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

    pg_dump -Fd -v --host=sourceServer --port=5432 --username=myUser --dbname=mySourceDB -j 4 -f myDumpDirectory

    Например,

    pg_dump -Fd -v --host=pg-95.postgres.database.azure.com --port=5432 --username=pg@pg-95 --dbname=bench5gb -j 4 -f dump.dir

  3. Затем восстановите резервную копию на целевом сервере.

    $ pg_restore -v --no-owner --host=myTargetServer --port=5432 --username=myUser --dbname=myTargetDB -j 4 myDumpDir

    Например,

    $ pg_restore -v --no-owner --host=pg-11.postgres.database.azure.com --port=5432 --username=pg@pg-11 --dbname=bench5gb -j 4 dump.dir

Совет

Описанный в этом документе процесс можно также использовать для обновления Базы данных Azure для PostgreSQL на Гибком сервере. Основное отличие заключается в том, что строка подключения для целевого гибкого сервера не содержит @dbName. Например, если имя пользователя — pg, то имя пользователя отдельного сервера в строке подключения будет иметь значение pg@pg-95, а при использовании гибкого сервера можно просто указать pg.

После обновления или миграции

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

postgres=> analyze;
ANALYZE

Следующие шаги

  • Убедившись, что целевая база данных работает должным образом, можно удалить старый сервер базы данных.
  • Только для Базы данных Azure для PostgreSQL на отдельном сервере. Если вы хотите использовать ту же конечную точку базы данных, что и исходный сервер, то после удаления старого сервера базы данных-источника можно создать реплику чтения с именем старого сервера базы данных. После установления состояния стабильной репликации можно будет остановить реплику, что сделает сервер реплики независимым сервером. Дополнительные сведения см. в разделе Репликация.

Внимание

Настоятельно рекомендуется протестировать новую обновленную версию PostgreSQL, прежде чем использовать ее непосредственно для рабочей среды. Это включает сравнение параметров сервера между источником более старой версии и целевым объектом новой версии. Убедитесь, что они совпадают, и проверьте новые параметры, которые были добавлены в новой версии. Сведения о различиях между версиями можно найти здесь.