Поделиться через

Рекомендации по pg_dump и pg_restore для База данных Azure для PostgreSQL — гибкий сервер

  • Статья

ОБЛАСТЬ ПРИМЕНЕНИЯ: База данных Azure для PostgreSQL — гибкий сервер

В этой статье рассматриваются варианты и рекомендации по ускорению pg_dump и pg_restore. Он также объясняет лучшие конфигурации сервера для выполнения pg_restore.

Рекомендации по pg_dump

С помощью программы pg_dump можно извлечь гибкую базу данных сервера База данных Azure для PostgreSQL в файл скрипта или архивный файл. Некоторые из параметров командной строки, которые можно использовать для уменьшения общего времени дампа с помощью pg_dump, перечислены в следующих разделах.

Формат каталога (-Fd)

Этот параметр выводит архив формата каталога, который можно ввести в pg_restore. По умолчанию выходные данные сжимаются.

Параллельные задания(-j)

С помощью pg_dump можно одновременно запускать задания дампа с помощью параметра параллельных заданий. Этот параметр сокращает общее время дампа, но увеличивает нагрузку на сервер базы данных. Рекомендуется прибыть к параллельному значению задания после тщательного мониторинга метрик исходного сервера, таких как использование ЦП, памяти и операций ввода-вывода (входные и выходные операции в секунду).

При настройке значения для параметра параллельных заданий pg_dump требуется следующее:

  • Число подключений должно совпадать с числом параллельных заданий +1, поэтому не забудьте задать соответствующее max_connections значение.
  • Число параллельных заданий должно быть меньше или равно количеству виртуальных ЦП, выделенных для сервера базы данных.

Сжатие (-Z0)

Этот параметр задает уровень сжатия, используемый. Ноль означает, что сжатие не выполняется. Нулевое сжатие во время процесса pg_dump может помочь в повышении производительности.

Табличные большие двоичные объекты и вакуумирование

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

select schemaname,relname,n_dead_tup,n_live_tup,round(n_dead_tup::float/n_live_tup::float*100) dead_pct,autovacuum_count,last_vacuum,last_autovacuum,last_autoanalyze,last_analyze from pg_stat_all_tables where n_live_tup >0;

Столбец dead_pct в этом запросе — это процент мертвых кортежей по сравнению с динамическими кортежами. Большое dead_pct значение таблицы может указывать на то, что таблица не является правильно вакуумной. Дополнительные сведения см. в разделе "Настройка autovacuum" в База данных Azure для PostgreSQL — гибкий сервер.

Для каждой определенной таблицы можно выполнить ручной анализ вакуума, выполнив следующие действия:

vacuum(analyze, verbose) <table_name>

Использование сервера PITR

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

Для больших баз данных можно создать сервер восстановления на определенный момент времени (PITR) с рабочего сервера и выполнить процесс pg_dump на сервере PITR. Выполнение pg_dump в PITR будет холодным процессом выполнения. Компромисс в этом подходе заключается в том, что вы не будете беспокоиться о дополнительном использовании ЦП, памяти и операций ввода-вывода, который поставляется с процессом pg_dump, который выполняется на фактическом рабочем сервере. Вы можете запустить pg_dump на сервере PITR, а затем удалить сервер PITR после завершения процесса pg_dump.

Синтаксис для pg_dump

Используйте следующий синтаксис для pg_dump:

pg_dump -h <hostname> -U <username> -d <databasename> -Fd -j <Num of parallel jobs> -Z0 -f sampledb_dir_format

Рекомендации по pg_restore

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

Параллельное восстановление

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

Параметры сервера

При восстановлении данных на новом сервере или нерабочем сервере можно оптимизировать следующие параметры сервера перед запуском pg_restore:

work_mem = 32 МБ
max_wal_size = 65536 (64 ГБ)
checkpoint_timeout = 3600 #60min
maintenance_work_mem = 2097151 (2 ГБ)
autovacuum = off
wal_compression = в

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

Примечание.

Следуйте приведенным выше рекомендациям только в том случае, если достаточно памяти и дискового пространства. Если у вас есть небольшой сервер с 2, 4 или 8 виртуальными ядрами, задайте соответствующие параметры.

Другие вопросы

  • Отключите высокий уровень доступности перед запуском pg_restore.
  • Анализ всех таблиц, перенесенных после завершения восстановления.

Синтаксис для pg_restore

Используйте следующий синтаксис для pg_restore:

pg_restore -h <hostname> -U <username> -d <db name> -Fd -j <NUM> -C <dump directory>

  • -Fd: формат каталога.
  • -j: количество заданий.
  • -C: Запустите выходные данные с помощью команды, чтобы создать саму базу данных, а затем повторно подключиться к ней.

Ниже приведен пример отображения этого синтаксиса:

pg_restore -h <hostname> -U <username> -j <Num of parallel jobs> -Fd -C -d <databasename> sampledb_dir_format

Рекомендации по виртуальным машинам

Создайте виртуальную машину в одном регионе и зоне доступности, предпочтительно, где у вас есть целевые и исходные серверы. Или, как минимум, создайте виртуальную машину ближе к исходному серверу или целевому серверу. Рекомендуется использовать Azure Виртуальные машины с высокопроизводительной локальной SSD.

Дополнительные сведения об номерах SKU см. в следующих статье:

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