WAL-G поддерживает бекапы с реплик, блочные инкрементальные, tablespace-ы и конечно ротацию старых бекапов. А ещё параллельную загрузку WAL в обе стороны. Производительность тоже можете протестировать, скорее всего время восстановления у нас будет минимальным. Pull request-ы в документацию приветствуются :)
Спасибо за обзор! Я хотел добавить что на Highload будет ещё Golang Conf. А там будет доклад Дениса и Кирилла про SPQR. А он тоже про Postgres! Они уже делали этот доклад на PGConf.Ru, но с тех пор они целый год работали и много чего дописали :)
Ровно всё это, кроме мержа дельт у нас в WAL-G есть :)
А ещё, например, есть backup for catchup — мы умеем накладывать дельту поверх существующей базы :)
pg_probackup — замечательная система, там есть очень эффективные дельта копии. Они сделаны существенно лучше чем у нас, потому что написав систему на С они могут слинковаться с PG. Ещё одним важным преимуществом pg_probackup может быть платная вендорская поддержка. Мы в WAL-G оказываем бесплатную поддержку на GitHub, но все понимают что это не то же самое.
Преимущества WAL-G довольно простые — много разных облачных хранилищ и скорость. Мы руководствуемся простой идеей — дёшево бекапить, быстро восстанавливать. Ну и вам не нужно отдельное железо под WAL-G, это оооочень простая система. Которая ещё умеет MySQL, MongoDB, FoundationDB и всякое такое.
Там, кстати, есть ещё один скрипт который хотелось бы затащить внутрь.
Вот есть у нас кластер, типа patroni. В нём есть primary, и какие-то реплики.
Сейчас у нас в питонячем скрипте реплики координируются через ЗК чтобы выбрать какой из узлов снимает бекап: в последнюю очередь с primary, но лучше с реплики. Из реплик лучше выбирать не ту что в syncronous_standby_names. Среди прочих нужно выбрать реплику с максимальным LSN. Нетривиально, да?
Вот хочется чтобы эта логика тоже была поддержана на стороне WAL-G.
Крон писать самим что-то не хочется.
В остальном — всё так, да.
В MDB Я.Облака по крону Python-скрипт запускает WAL-G для бекапа, а потом для удаления, рассчитывая время границы окна удаления. Так было сделано во времена WAL-E и никто не спрашивал «почему?». По-другому просто не получалось. А потом просто руки не доходили — в сообществе всем норм, в Я.Облаке всё уже настроено.
Нужно впилить в backup-push всю функциональность delete, я согласен. Политики delete нужно расширить, но вот надо хорошо подумать. Мы сами используем политику «гарантированно сохранить не менее 7 суток назад», которая не представлена родными WAL-G политиками.
У нас есть в принципе руки разработчиков-студентов для реализации фич, полезных сообществу. Но 1. Ими надо руководить очень сильно прикладывая ум к верхнеуровневому проектированию, они пишут код слишком быстро 2. Они появляются в семестре и не предоставляют никаких гарантий того что результат будет (качество результата проверяют мэйнтейнеры и полурезультата просто не будет). Вот с этими ограничениями мы, после обсуждения, можем добавить примерно любые фичи.
Шардирование масштабируется горизонтально, мультимастер для этого не нужен. Пострес XL, емнип, не мультимастер. BDR или PgPro multimaster могут быть примерами.
Извините за занудство.
Идея нескольких пишущих лидеров подразумевает, что все актуальные реплики должны произвести запись всех операций.
Иными словами, никакой мультимастер не масштабируется горизонтально по записи.
PreCommitfest придумал Николай Шаплов. Я только отразил эту волну смыслов, а реальные действия начал Мамонт, Мария и другие организаторы из ПгПро.
С реплики заведётся без ключей, инкрементальные бекапы включаются WALG_MAX_DELTA_STEPS - максимальное количество инкрементов в цепочке. Tablespace никак настраивать не надо, они просто работают, но можно настроить как в WAL-E https://github.com/wal-g/wal-g/blob/master/docker/pg_tests/scripts/tests/wale_tablespace_compatibility_test.sh
Параллельная загрузка никакой настройки не требует (можно concurrency и лимиты покрутить если хочется).
WAL-G поддерживает бекапы с реплик, блочные инкрементальные, tablespace-ы и конечно ротацию старых бекапов. А ещё параллельную загрузку WAL в обе стороны. Производительность тоже можете протестировать, скорее всего время восстановления у нас будет минимальным. Pull request-ы в документацию приветствуются :)
Спасибо за обзор! Я хотел добавить что на Highload будет ещё Golang Conf. А там будет доклад Дениса и Кирилла про SPQR. А он тоже про Postgres! Они уже делали этот доклад на PGConf.Ru, но с тех пор они целый год работали и много чего дописали :)
К сожалению, я пока только доцент в УрФУ, просто перевожу на английский как Associate Professor :) Докторская лежит на полке 4 год...
flashback не сложно написать, только ведь он не дальше последнего вакуума. С такими ограничениями он полезен?
А ещё, например, есть backup for catchup — мы умеем накладывать дельту поверх существующей базы :)
Преимущества WAL-G довольно простые — много разных облачных хранилищ и скорость. Мы руководствуемся простой идеей — дёшево бекапить, быстро восстанавливать. Ну и вам не нужно отдельное железо под WAL-G, это оооочень простая система. Которая ещё умеет MySQL, MongoDB, FoundationDB и всякое такое.
Вот есть у нас кластер, типа patroni. В нём есть primary, и какие-то реплики.
Сейчас у нас в питонячем скрипте реплики координируются через ЗК чтобы выбрать какой из узлов снимает бекап: в последнюю очередь с primary, но лучше с реплики. Из реплик лучше выбирать не ту что в syncronous_standby_names. Среди прочих нужно выбрать реплику с максимальным LSN. Нетривиально, да?
Вот хочется чтобы эта логика тоже была поддержана на стороне WAL-G.
В остальном — всё так, да.
В MDB Я.Облака по крону Python-скрипт запускает WAL-G для бекапа, а потом для удаления, рассчитывая время границы окна удаления. Так было сделано во времена WAL-E и никто не спрашивал «почему?». По-другому просто не получалось. А потом просто руки не доходили — в сообществе всем норм, в Я.Облаке всё уже настроено.
Нужно впилить в backup-push всю функциональность delete, я согласен. Политики delete нужно расширить, но вот надо хорошо подумать. Мы сами используем политику «гарантированно сохранить не менее 7 суток назад», которая не представлена родными WAL-G политиками.
У нас есть в принципе руки разработчиков-студентов для реализации фич, полезных сообществу. Но 1. Ими надо руководить очень сильно прикладывая ум к верхнеуровневому проектированию, они пишут код слишком быстро 2. Они появляются в семестре и не предоставляют никаких гарантий того что результат будет (качество результата проверяют мэйнтейнеры и полурезультата просто не будет). Вот с этими ограничениями мы, после обсуждения, можем добавить примерно любые фичи.
Про это есть доклад Гоши Рылова на pgconf.ru pgconf.ru/2020/271756
Извините за занудство.
Иными словами, никакой мультимастер не масштабируется горизонтально по записи.