pg_dump и pg_restore на гигантских базах данных - PullRequest
Новая
       20

pg_dump и pg_restore на гигантских базах данных

0 голосов
/ 14 марта 2019

У меня сейчас задача улучшить структуру базы данных. Для этого мы хотим эффективно сбросить и восстановить одну гигантскую базу данных. ( около 1 ТБ и растет )

Чтобы проверить вещи с этой базой данных, мы хотели перенести эту базу данных на другой сервер-узел, и это через pg_dump и pg_restore.

Мы работаем с сервером v10 (https://www.postgresql.org/docs/10/app-pgdump.html)), поэтому мы ограничены их возможными параметрами. Также требуется для выгрузки полной базы данных, а не только ее частей.

Для этого я попробовал пару подходов, эти источники очень помогли:

и прежде всего:

Проблема в том, что вы можете улучшить только одно из этих заданий, но не оба одновременно.

Дело 1

Дамп в формате каталога очень быстрый ( ~ 1 час ), но восстановление не происходит. 

pg_dump --blobs --dbname="$DBNAME" --file=$DUMPDIR --format=directory --host=$SERVERHOSTNAME --jobs=$THREADS --port=$SERVERPORT--username="$SERVERUSERNAME"
pg_restore --clean --create --format=directory --jobs=$THREADS --host=$SERVERHOSTNAME --port=$SERVERPORT --username="$SERVERUSERNAME" "./"

Проблема этого метода восстановления заключается в том, что, хотя я назначил ему несколько ядер, он использует только одно, при этом на ядре сервера используется только 4% ЦП.

Дело 2

Дамп в пользовательском формате чрезвычайно медленный, поэтому сервер даже не смог завершить его за ночь (время ожидания сеанса). 

pg_dump --blobs --compress=9 --dbname="$dbname" --file="$DUMPDIR/db.dump" --format=custom --host=$SERVERHOSTNAME --port=$SERVERPORT --username=$SERVERUSERNAME

Итак, я имел в виду разные подходы:

  1. сбросить с помощью подхода # 1, затем преобразовать его (как?) И использовать более быстрый метод восстановления (вариант # 2?)
  2. Одновременное создание нескольких дампов на разных ядрах, но с разными схемами (всего их 6), а затем их объединение (как?)

По словам автора, указанного выше, трубопровод кажется неэффективным способом сброса.

У кого-нибудь есть больше опыта в этом? И полезны ли мои подходы или у вас есть совершенно другое решение?

О, прежде чем я забуду: в настоящее время мы ограничены 5 ТБ на нашем внешнем сервере, и внутренний сервер, на котором работает БД, не должен раздутаться с фрагментами данных, даже временно.

1 Ответ

0 голосов
/ 14 марта 2019

Параллельная pg_restore с форматом каталога должна ускорить обработку.

Если этого не произойдет, я подозреваю, что большая часть данных находится в одной большой таблице, которая pg_restore (и pg_dump) не может распараллелить.

Убедитесь, что вы отключили сжатие (-z 0) для повышения скорости (если у вас нет слабой сети).

Вы можете быть значительно быстрее с файловой системой онлайнрезервное копирование:

  • pg_basebackup простое, но не может быть распараллелено.

  • Использование low-API уровня , вы можете распараллелить резервное копирование с операционной системой или методами хранения.

Недостатком является то, что при резервном копировании файловой системы вы можете копировать только весь кластер базы данных.

...