На початку я використовував pg_dumpзвичайний формат за замовчуванням. Я був непросвітлений.

Дослідження показали мені покращення часу та розміру файлу за допомогою pg_dump -Fc | gzip -9 -c > dumpfile.gz. Я був просвітлений.

Коли прийшов час створювати базу даних заново,

# create tablespace dbname location '/SAN/dbname';
# create database dbname tablespace dbname;
# alter database dbname set temp_tablespaces = dbname;

% gunzip dumpfile.gz              # to evaluate restore time without a piped uncompression
% pg_restore -d dbname dumpfile   # into a new, empty database defined above

Я відчував себе непросвітленим: відновлення зайняло 12 годин, щоб створити базу даних, яка є лише часткою того, чим вона стане:

# select pg_size_pretty(pg_database_size('dbname'));
47 GB

Оскільки передбачається, що ця база даних складатиме кілька терабайт, мені зараз потрібно поглянути на підвищення продуктивності.

Будь ласка, просвіти мене.

Спочатку перевірте, чи отримуєте ви розумну продуктивність вводу-виводу за допомогою налаштування диска. Потім переконайтесь, що установка PostgreSQL налаштована належним чином. Зокрема, shared_buffersслід правильно встановити, maintenance_work_memзбільшити під час відновлення, full_page_writesвимкнути під час відновлення, wal_buffersзбільшити до 16 МБ під час відновлення, checkpoint_segmentsзбільшити до приблизно 16 під час відновлення, у вас не повинно бути необгрунтованого входу (як реєстрація кожного виконаного оператора), auto_vacuumслід відключити під час відновлення.

Якщо ви використовуєте 8.4, а також експериментуйте з паралельним відновленням, параметр --jobs для pg_restore.

Покращити дамп та відновлення pg

PG_DUMP | завжди використовуйте каталог-формат і -jпараметри

time pg_dump -j 8 -Fd -f /tmp/newout.dir fsdcm_external

PG_RESTORE | завжди використовуйте налаштування для postgres.conf і format-directory і -joptions

work_mem = 32MB
shared_buffers = 4GB
maintenance_work_mem = 2GB
full_page_writes = off
autovacuum = off
wal_buffers = -1

time pg_restore -j 8 --format=d -C -d postgres /tmp/newout.dir/

Два питання / ідеї:

1. Вказавши -Fc, вихід pg_dump вже стискається. Стиснення не є максимальним, тому ви можете знайти певну економію місця за допомогою "gzip -9", але я б поклався на пари, що цього недостатньо, щоб гарантувати додатковий час (і введення / виведення), який використовується для стиснення та розтискання версії резервної копії -Fc .

2. Якщо ви використовуєте PostgreSQL 8.4.x, ви можете потенційно прискорити відновлення за допомогою резервної копії -Fc за допомогою нової опції командного рядка pg_restore "-j n", де n = кількість паралельних з'єднань для відновлення. Це дозволить pg_restore завантажувати більше даних однієї таблиці або генерувати більше одного індексу одночасно.

Припускаю, вам потрібна резервна копія, а не серйозне оновлення бази даних.

Для резервного копіювання великих баз даних замість цього слід налаштувати безперервне архівуванняpg_dump .

1. Налаштуйте архівування WAL .

2. Робіть базові резервні копії, наприклад, щодня, використовуючи
   psql template1 -c "select pg_start_backup('`date +% F-% T``))" rsync -a --delete / var / lib / pgsql / data / / var / backups / pgsql / base / psql template1 - c "виберіть pg_stop_backup ()" `

Відновлення було б таким же простим, як відновлення журналів бази даних та WAL, не старших за pg_start_backupчас, з місця резервного копіювання та запуску Postgres. І це буде набагато швидше.

zcat dumpfile.gz | pg_restore -d db_name

Видаляє повний запис нестиснених даних на диск, який на сьогодні є вашим вузьким місцем.

Як ви, можливо, здогадалися просто з того факту, що стиснення резервної копії призводить до швидшої продуктивності, ваша резервна копія пов’язана з операціями вводу-виводу. Це не повинно дивувати, оскільки резервне копіювання майже завжди буде пов'язане з введенням / виведенням. Стискання даних обмінює навантаження вводу-виводу для завантаження процесора, а оскільки більшість процесорів простоюють під час передачі даних монстра, стиснення виходить як чистий виграш.

Отже, щоб пришвидшити час резервного копіювання / відновлення, вам потрібно швидше введення-виведення. Окрім реорганізації бази даних, щоб вона не була єдиним величезним екземпляром, це майже все, що ви можете зробити.