Comments 23
72 часа за год — это много :)
у меня основное время при разворачивании базы занимает создание индексов.
реально помогает задирание maintenance_work_mem и отключание автовакуума
у меня основное время при разворачивании базы занимает создание индексов.
реально помогает задирание maintenance_work_mem и отключание автовакуума
А если накинуть еще 4 ядра в виртуалку и заливать дамп в 16 потоков?
А почему не используете directory format и многопоточный дамп как его плюшку? Ну и если уж жать-разжимать gzip-ом, так использовать многопоточный pigz
А почему решили не использовать pg_basebackup?
В случае его использования время развертывания будет примерно равно времени копирования файлов.
Из минусов — так можно делать только целиком для кластера и версии PG должны быть одинаковые.
В случае его использования время развертывания будет примерно равно времени копирования файлов.
Из минусов — так можно делать только целиком для кластера и версии PG должны быть одинаковые.
не знаю как в postgres(наверно можно сделать), но в mysql самое быстрое это останавливать mysql и подменять файлы базы. Если стоит ssd или raid, то за пару минут в вас будет копироваться база.
А вообще для dev-среды эффективнее всего просто останавливать базу и полностью заменять файлы. Получится моментально. Если, конечно, применимо. Постгрес в контейнер, дамп выкачали по http, распаковали pigz-ом, подсунули новый volume контейнеру и все. Никаких томительных часов ожидания, пока на медленном диске виртуалки индексы прожуются
pg_dump -Fc db
Имеет смысл явно указывать уровень сжатия. Например pg_dump -Fc -Z 1 db
По умолчанию для -Fc он стоит в 6, что нагружает проц и увеличивает время бекапа
А ещё есть zstd, который в 4 раза быстрее zlib при той же степени сжатия.
pg_basebackup не пробовали?
Как вариант, можно настроить в привилигерованном lxc контейнере реплику и использовать ее в качестве образа для легковесных overlayfs контейнеров. То есть мастер транслирует wal логи на lxc реплику. Когда мы хотим себе полигон, просто делаем lxc-copy с типом overlayfs (легковесный снимок основного lxc контейнера, который пишет только разность относительно замороженного слоя), переводим postgresql overlayfs копии в боевой режим и экспериментируем на здоровье. Должно происходить мгновенно. Была статья на хабре, где парень что-то похожее на эту схему делал, только на btrfs
просто направить запакованный файл напрямую в psql с помощью zcat
Не везде есть. Но практически везде есть gzip -cd.
Краткое содержание статьи — прочитали мануал и нашли опции -Fc и -j. Нелохо.
Но вот что реально помогло сэкономить время на бекап\восстановление в нашем проекте:
как правило, в размерах таблиц в базе соблюдается принцип 20/80. Оказалось что для dev 80 не нужны (обычно это стата). Так вот гораздо более полезной было открытие опции (опять же, из манулов) --exclude-table с выкидывание ненужных таблиц из бекапа и последующим их созданием с минимально необхоимым для дев контентом.
Но вот что реально помогло сэкономить время на бекап\восстановление в нашем проекте:
как правило, в размерах таблиц в базе соблюдается принцип 20/80. Оказалось что для dev 80 не нужны (обычно это стата). Так вот гораздо более полезной было открытие опции (опять же, из манулов) --exclude-table с выкидывание ненужных таблиц из бекапа и последующим их созданием с минимально необхоимым для дев контентом.
Как раз тоже занимаюсь анализированием pg_dump — pg_restore. Столкнулся со странным поведением второй команды Почему-то при восстановлении в логи ругаутся ошибками[archiver (db)] could not execute query: ERROR: relation «table_1» does not exist.
При восстановлении одной таблицы ругается на отсутствие другой, на отсутствие директорий, отсутствие индексов.
В итоге восстановление просто не завершается. И в текстовом формате дампил, и в бинарном. Ничего не понимаю…
При восстановлении одной таблицы ругается на отсутствие другой, на отсутствие директорий, отсутствие индексов.
В итоге восстановление просто не завершается. И в текстовом формате дампил, и в бинарном. Ничего не понимаю…
спасибо автору за полезную статью (переводу), когда планируется 2 часть.
Варианты увеличение скорости:
1) Взять SSD, на нем же быстрее будет идти разработка.
2) Бэкапить снапшотом и вытаскиванием файлов баз. Потом просто подключать файлы в базу.
3) Зеркалить репликой с мастер базы на слейв. Затем просто оторвать слейв и сделать его девом. К мастеру подключить новый слейв, к моменту когда будет нужен новый дев — база уже докатится.
Хотя конечно без структуры вашей фермы разработки и продакшена сложно сказать как лучше оптимизировать.
1) Взять SSD, на нем же быстрее будет идти разработка.
2) Бэкапить снапшотом и вытаскиванием файлов баз. Потом просто подключать файлы в базу.
3) Зеркалить репликой с мастер базы на слейв. Затем просто оторвать слейв и сделать его девом. К мастеру подключить новый слейв, к моменту когда будет нужен новый дев — база уже докатится.
Хотя конечно без структуры вашей фермы разработки и продакшена сложно сказать как лучше оптимизировать.
Мы делаем zfs снапшотами, всё моментально, причём на продакшн, причём база 300 гигов а не 30. А уж для dev очевидно что dump-restore это совершенно не нужно, просто держать копию базы где-то и подпихивать её не знаю, симлинком каким-нибудь.
В особенности если это используется для тестирования, рекомендую просто подготовить Docker образ, и откатываться к любой закоммиченной точке в течении единичных секунд.
Sign up to leave a comment.
Ускоряем восстановление бэкапов в PostgreSQL