В бета версии PostgreSQL 8.4 в утилите pg_restore появилась поддержка возможности загрузки дампа
в несколько параллельных потоков. Например, загрузка дампа базы размером 300 Гб на 8-ядерном сервере
занимала стандартным образом 12 часов, при распараллеливании процесса загрузки на 8 потоков,
время загрузи сократилось до 3 часов. Полная перезагрузка дампа базы может понадобиться например при миграции
с PostgreSQL 8.2 на 8.3 или при переходе с 32- на 64-разрядную сборку системы.Огромным плюсом является и то, что параллельный вариант pg_restore
из ветки 8.4 прекрасно работает с ветками 8.2 и 8.3.
Рассмотрим процесс миграции с 8.2 на 8.3. На рабочей машине дополнительно установим в отдельную директорию бета версию 8.4:
./configure --prefix=/usr/local/pgsql84
make
make install
Создаем дамп работающей базы PostgreSQL 8.2, использую утилиту pg_dump из состава PostgreSQL 8.3:
/usr/local/pgsql83/bin/pg_dump -F c -v -f my_db.dump my_database
В зависимости от конфигурации дополнительно может потребоваться сделать дамп ролей:
/usr/local/pgsql83/bin/pg_dumpall -g -f my_roles.dump
Восстанавливаем роли:
/usr/local/pgsql83/bin/psql -f my_roles.dump postgres
Запускаем процесс параллельного восстановления базы, число потоков задается через опцию -j, в нашем случае
используется загрузка в 8 потоков. При указании большого числа потоков нужно быть уверенным, что система
ввода/вывода не окажется узким местом, т.е. база размещена на высокопроизводительном хранилище:
/usr/local/pgsql84/bin/pg_restore -F c -j 8 -v -C -f my_db.dump
Дополнительно можно упомянуть, что в рамках проекта EnterpriseDB ведется разработка утилиты pg_migrator
(http://pgfoundry.org/projects/pg-migrator/), позволяющей осуществлять перенос базы на новый сервер
без остановки работы СУБД. Но pg_migrator к сожалению находится еще на стадии альфа тестирования.
Некоторые советы по оптимизации процесса создания дампа и его восстановления:
* Во время восстановления можно отключить fsync режим и autovacuum, значительно увеличить размер памяти
(до 1 Гб если памяти много), заданный в параметрах конфигурации work_mem и maintenance_work_mem,
при этом размер wal_buffers и checkpoint_segments также нужно увеличить до 16 или 32 Мб;
* При наличии больших GIN или GiST индексов, время восстановления которых нередко занимает 75% от всего времени
восстановления, если без этих индексов можно себе позволить немного поработать, имеет смысл разделить
процесс восстановления на две стадии: восстановление первичных данных, запуск БД в продакшин,
восстановление GIN или GiST индексов уже на работающей базе.
* Всегда следует использовать pg_dump из более новой версии PostgreSQL, а не из старой, апгрейд которой производится.
* Для продакшин систем, время и наличие возможных подводных камней стоит предварительно оценить,
выполнив тестовые dump/restore без остановки первичной базы;
URL: http://it.toolbox.com/blogs/database-soup/using-84-parallel-...
Обсуждается: https://www.opennet.ru/tips/info/2067.shtml
