Comments 41
Уже давно известно, что делать бэкапы в SQL-дампы (используя pg_dump или pg_dumpall) – не самая хорошая идея.
А почему?
потому что нет point-in-time, как минимум.
Обычно через него делают дамп всей базы целиком, соответственно размер бэкапа на больших базах будет внушительный, а из этого следует что бэкапить хотя бы каждый час этим способом – не рационально. Поэтому обычно все делают бэкапы раз в сутки, ночью. Но если что-то произойдет с базой/сервером в течении дня, то все данные за этот промежуток будут утеряны.
В случае с описаным в статье способом бэкапа – все изменения, которые попали в WAL (Write-ahead Log) и выгрузились через archive_command – улетят в облако. И когда будете восстанавливаться – они подтянутся через restore_command, поэтому шанс потерять что-то крайне мал.
Плюс ещё раньше всех пугали блокировками на уровне базы, когда делается pg_dump. Но как сейчас там дела – я точно не знаю.
В случае с описаным в статье способом бэкапа – все изменения, которые попали в WAL (Write-ahead Log) и выгрузились через archive_command – улетят в облако. И когда будете восстанавливаться – они подтянутся через restore_command, поэтому шанс потерять что-то крайне мал.
Плюс ещё раньше всех пугали блокировками на уровне базы, когда делается pg_dump. Но как сейчас там дела – я точно не знаю.
Сейчас во время бэкапа всё работает нормально. Версия 10 и 11 Постгреса.
В целом аргументация понятна. В моём случае эти факторы не критичны, я уж испугался что pg_dump ненадёжна или что-то в этом духе.
В целом аргументация понятна. В моём случае эти факторы не критичны, я уж испугался что pg_dump ненадёжна или что-то в этом духе.
Надежность тут тоже имеет место быть, вероятно.
В логах наката может быть проверка целостности контрольными суммами.
В логах наката может быть проверка целостности контрольными суммами.
У pg_dump есть проблема с выгрузкой больших объектов. Много примеров можно нагуглить по "pg_dump invalid memory alloc request".
Сейчас во время бэкапа всё работает нормально. Версия 10 и 11 Постгреса.То есть можно менять схему данных во время выполнения pg_dump?
Потому что дамп это нисколько не бэкап и не может называться таковым.
Потому что это не бэкап, а дамп.
Кстати zalando прикрутили к своему постгрес оператору logical_backup c pg_dumpall
Ох уж этот юниксвэй. Половина конфигурации лежит в json, половина в crontab.
Во-первых, неудобно, что сразу в одном месте все не видно. А неудобно => дорого поддерживать, т.к. любой новый сотрудник будет дольше с этим разбираться.
Во-вторых, не очень понятны преимущества выноса удаления старых бекапов в crontab. Более логичной выглядит идея удалять и проверять их тогда, когда создается новый файл. (т.к. чаще всего именно в этот момент старый бекап становится не нужен. а сама операция удаления дешевая по io ресурсам и нет смысла ее откладывать на малозагруженное время сервера).
В-третьих, ну почему же не сделали параметр у wal-g delete, чтобы просто указать «3 дня назад от текущей даты»? Очевидно, что это частоиспользуемый параметр (как и удаление по количеству бекапов). Вот зачем каждого админа заставляют писать эту математику с датой и ее форматированием?
Во-первых, неудобно, что сразу в одном месте все не видно. А неудобно => дорого поддерживать, т.к. любой новый сотрудник будет дольше с этим разбираться.
Во-вторых, не очень понятны преимущества выноса удаления старых бекапов в crontab. Более логичной выглядит идея удалять и проверять их тогда, когда создается новый файл. (т.к. чаще всего именно в этот момент старый бекап становится не нужен. а сама операция удаления дешевая по io ресурсам и нет смысла ее откладывать на малозагруженное время сервера).
В-третьих, ну почему же не сделали параметр у wal-g delete, чтобы просто указать «3 дня назад от текущей даты»? Очевидно, что это частоиспользуемый параметр (как и удаление по количеству бекапов). Вот зачем каждого админа заставляют писать эту математику с датой и ее форматированием?
Крон писать самим что-то не хочется.
В остальном — всё так, да.
В MDB Я.Облака по крону Python-скрипт запускает WAL-G для бекапа, а потом для удаления, рассчитывая время границы окна удаления. Так было сделано во времена WAL-E и никто не спрашивал «почему?». По-другому просто не получалось. А потом просто руки не доходили — в сообществе всем норм, в Я.Облаке всё уже настроено.
Нужно впилить в backup-push всю функциональность delete, я согласен. Политики delete нужно расширить, но вот надо хорошо подумать. Мы сами используем политику «гарантированно сохранить не менее 7 суток назад», которая не представлена родными WAL-G политиками.
У нас есть в принципе руки разработчиков-студентов для реализации фич, полезных сообществу. Но 1. Ими надо руководить очень сильно прикладывая ум к верхнеуровневому проектированию, они пишут код слишком быстро 2. Они появляются в семестре и не предоставляют никаких гарантий того что результат будет (качество результата проверяют мэйнтейнеры и полурезультата просто не будет). Вот с этими ограничениями мы, после обсуждения, можем добавить примерно любые фичи.
Про это есть доклад Гоши Рылова на pgconf.ru pgconf.ru/2020/271756
В остальном — всё так, да.
В MDB Я.Облака по крону Python-скрипт запускает WAL-G для бекапа, а потом для удаления, рассчитывая время границы окна удаления. Так было сделано во времена WAL-E и никто не спрашивал «почему?». По-другому просто не получалось. А потом просто руки не доходили — в сообществе всем норм, в Я.Облаке всё уже настроено.
Нужно впилить в backup-push всю функциональность delete, я согласен. Политики delete нужно расширить, но вот надо хорошо подумать. Мы сами используем политику «гарантированно сохранить не менее 7 суток назад», которая не представлена родными WAL-G политиками.
У нас есть в принципе руки разработчиков-студентов для реализации фич, полезных сообществу. Но 1. Ими надо руководить очень сильно прикладывая ум к верхнеуровневому проектированию, они пишут код слишком быстро 2. Они появляются в семестре и не предоставляют никаких гарантий того что результат будет (качество результата проверяют мэйнтейнеры и полурезультата просто не будет). Вот с этими ограничениями мы, после обсуждения, можем добавить примерно любые фичи.
Про это есть доклад Гоши Рылова на pgconf.ru pgconf.ru/2020/271756
Там, кстати, есть ещё один скрипт который хотелось бы затащить внутрь.
Вот есть у нас кластер, типа patroni. В нём есть primary, и какие-то реплики.
Сейчас у нас в питонячем скрипте реплики координируются через ЗК чтобы выбрать какой из узлов снимает бекап: в последнюю очередь с primary, но лучше с реплики. Из реплик лучше выбирать не ту что в syncronous_standby_names. Среди прочих нужно выбрать реплику с максимальным LSN. Нетривиально, да?
Вот хочется чтобы эта логика тоже была поддержана на стороне WAL-G.
Вот есть у нас кластер, типа patroni. В нём есть primary, и какие-то реплики.
Сейчас у нас в питонячем скрипте реплики координируются через ЗК чтобы выбрать какой из узлов снимает бекап: в последнюю очередь с primary, но лучше с реплики. Из реплик лучше выбирать не ту что в syncronous_standby_names. Среди прочих нужно выбрать реплику с максимальным LSN. Нетривиально, да?
Вот хочется чтобы эта логика тоже была поддержана на стороне WAL-G.
есть barman если хотите как сервис
Отличный пост.
P.S. Перед командой wal-g надо держать команду timeout, потому что если S3 недоступен, то WAL-G будет висеть.
https://github.com/wal-g/wal-g/issues/635
А чем данный инструмент лучше pg_probackup?
Вся статья об этом.
Вкратце:
Вкратце:
- поддержка выгрузки бэкапов в 5 различных хранилищ;
- создание «дельта» бэкпов, которые включат только те журналы, где были изменения (чтоб не делать копию всего кластера целиком каждый раз);
- сжатие бэкапов тремя методами (но лучше использовать Brotli);
- очистка хранилища несколькими методами, в том числе лимитируя количество оставляемых копий или оставляя бэкапы за определенный срок.
Извините, но вы не о том. Я о продукте компании postgres pro. Там и дельта бекапы и очистка хранилища и сжатие и удаленное копирование. Так по мне, их инструмент удобнее. Вы же, вероятно, подумали о pg_basebackup.
Да, прощу прощения – бегло прочитал и подумал что вы о pg_basebackup.
Инструмент от postgres pro я не использовал, но судя по документации – его чуть сложнее сконфигурировать и у него есть только локальный бэкап (нельзя в S3 сразу выгружать).
Если вы использовали pg_probackup, то можете поделиться тем, что у него сделано хорошо и какие там есть киллер-фичи?
Инструмент от postgres pro я не использовал, но судя по документации – его чуть сложнее сконфигурировать и у него есть только локальный бэкап (нельзя в S3 сразу выгружать).
Если вы использовали pg_probackup, то можете поделиться тем, что у него сделано хорошо и какие там есть киллер-фичи?
Сразу оговорюсь.Если показалось, что я пытаюсь занизить один продукт, а другой хвалить, это не так. Ведь чем больше инструментов, тем лучше. Меня заинтересовала ваша статья и я сам обязательно поизучаю WAL-G. Насчет «сложнее конфигурировать» не соглашусь. Вы создаете своим скриптом отдельный файл с жесткой структурой, в pg_pro достаточно все параметры передать в одной строке и конфигурационный файл сам создаётся. Насчет отличий (это, что я увидел, возможно такие же возможности вы просто не упомянули в статье)
* Удаление старых копий автоматически, при создании новой. В конфигурационном файле можно создать количество копий или время хранения. Все что не вписывается в политику хранения будет удалено.
* Удаление всех архивных wal файлов, которые относятся к ранее удаленным архивам.
* Автоматическая валидация архива при его создании.
* Возможность создания страничных архивов (PAGE), которые выполняются быстрее DELTA архивов.
* Архивирование и восстановление в несколько потоков, что при больших базах важно
* Архивирование WAL файлов не просто в несколько потоков, но и порциями. Так можно настроить, чтобы за одну обработку команды «archive_command » в архив улетало 100 файлов в 12 потоков. (тут надо пояснить если система «ОЧЕНЬ» высоконагружена, может возникнуть ситуация, что WAL файлы могут создаваться быстрее чем они архивируются. Таким образом, чтобы создать копию вам придется ждать 30 минут или несколько часов, чтобы все файлы были на месте. Именно эта фишка позволяет миновать данной ситуации. Если интересно почитайте github.com/postgrespro/pg_probackup/issues/209).
* Архивирование по SSH.
* Объединение нескольких копий в одну. Таким образом, если у вас объем данных большой, вы однажды можете создать полный бекап, потом делать инкрементальные бекапы и объединять их с полным. (читал на ветке GIT у разработчиков некоторые пользуются этим. У конторы полный бекап делается 2 или 3 суток, поэтому они его делают очень редко и пользуются объединением).
* Ну и разработчики отзывчивые. Реагируют моментально.
* Удаление старых копий автоматически, при создании новой. В конфигурационном файле можно создать количество копий или время хранения. Все что не вписывается в политику хранения будет удалено.
* Удаление всех архивных wal файлов, которые относятся к ранее удаленным архивам.
* Автоматическая валидация архива при его создании.
* Возможность создания страничных архивов (PAGE), которые выполняются быстрее DELTA архивов.
* Архивирование и восстановление в несколько потоков, что при больших базах важно
* Архивирование WAL файлов не просто в несколько потоков, но и порциями. Так можно настроить, чтобы за одну обработку команды «archive_command » в архив улетало 100 файлов в 12 потоков. (тут надо пояснить если система «ОЧЕНЬ» высоконагружена, может возникнуть ситуация, что WAL файлы могут создаваться быстрее чем они архивируются. Таким образом, чтобы создать копию вам придется ждать 30 минут или несколько часов, чтобы все файлы были на месте. Именно эта фишка позволяет миновать данной ситуации. Если интересно почитайте github.com/postgrespro/pg_probackup/issues/209).
* Архивирование по SSH.
* Объединение нескольких копий в одну. Таким образом, если у вас объем данных большой, вы однажды можете создать полный бекап, потом делать инкрементальные бекапы и объединять их с полным. (читал на ветке GIT у разработчиков некоторые пользуются этим. У конторы полный бекап делается 2 или 3 суток, поэтому они его делают очень редко и пользуются объединением).
* Ну и разработчики отзывчивые. Реагируют моментально.
Большое спасибо за пояснения! Такие дискуссии очень к месту, потому что другие уже исходя из опыта нескольких людей смогут выбрать для себя что-то подходящее.
Ровно всё это, кроме мержа дельт у нас в WAL-G есть :)
А ещё, например, есть backup for catchup — мы умеем накладывать дельту поверх существующей базы :)
А ещё, например, есть backup for catchup — мы умеем накладывать дельту поверх существующей базы :)
У probackup ещё есть возможность вытаскивать из бекапа кластера только одну БД.
мммм, а WAL они потом тоже на 1 БД накатывают?
Думаю будет полезно упомянуть, что подобную функциональность поддерживает и pgbackrest
pgbackrest.org/user-guide.html#restore/option-db-include
pgbackrest.org/user-guide.html#restore/option-db-include
pg_probackup — замечательная система, там есть очень эффективные дельта копии. Они сделаны существенно лучше чем у нас, потому что написав систему на С они могут слинковаться с PG. Ещё одним важным преимуществом pg_probackup может быть платная вендорская поддержка. Мы в WAL-G оказываем бесплатную поддержку на GitHub, но все понимают что это не то же самое.
Преимущества WAL-G довольно простые — много разных облачных хранилищ и скорость. Мы руководствуемся простой идеей — дёшево бекапить, быстро восстанавливать. Ну и вам не нужно отдельное железо под WAL-G, это оооочень простая система. Которая ещё умеет MySQL, MongoDB, FoundationDB и всякое такое.
Преимущества WAL-G довольно простые — много разных облачных хранилищ и скорость. Мы руководствуемся простой идеей — дёшево бекапить, быстро восстанавливать. Ну и вам не нужно отдельное железо под WAL-G, это оооочень простая система. Которая ещё умеет MySQL, MongoDB, FoundationDB и всякое такое.
Спасибо за статью. Я никогда не слышал о данном продукте. Для полноты картины хотелось бы видеть вариант кофигерации для Google Cloud Storage.
Не использовал хранилище от гугла, но если судить по разделу настроек в репе, то нужно добавить в конфиг параметр WALG_GS_PREFIX и настроить авторизацию с помощью GCE/GKE.
Добрый день! А что вы как автор имели ввиду написав «нужно написать как минимум пару трёхколёсных велосипедов, чтобы всё это работало»?
У меня возник такой вопрос, потому что я достаточно много прочитал в других источниках, что pg_dump работает не всегда корректно. Но по поводу использования pg_basebackup я не видел никаких нареканий.
У меня возник такой вопрос, потому что я достаточно много прочитал в других источниках, что pg_dump работает не всегда корректно. Но по поводу использования pg_basebackup я не видел никаких нареканий.
Доброго времени!
Про велосипеды я имел что как минимум заливку в какое-то хранилище (S3) – придётся писать самостоятельно. Но сюда же можно добавить и удаление старых резервных копий, особенно очистку wal'ов, которые создаются с помощью archive_command.
Проще говоря – лучше взять что-то готовое и научиться его использовать, тем более что оно уже протестировано в условиях Яндекса :)
Про велосипеды я имел что как минимум заливку в какое-то хранилище (S3) – придётся писать самостоятельно. Но сюда же можно добавить и удаление старых резервных копий, особенно очистку wal'ов, которые создаются с помощью archive_command.
Проще говоря – лучше взять что-то готовое и научиться его использовать, тем более что оно уже протестировано в условиях Яндекса :)
В крон разве не надо добавить пользователя postgres от которого и выполнять задачу? Иначе же не будет найден конфиг базы
Sign up to leave a comment.
WAL-G: бэкапы и восстановление СУБД PostgreSQL