Всеми руками поддерживаю использование одиссея в кач-ве пулера соединений для постгреса, но, справедливости ради
Как известно, PgBouncer — однопоточный...
...но ведь нормально параллелится с помощью so_reuseport даже в пределах одного контейнера. Не рассматривали ли такой вариант, и почему отмели, если рассматривали?
Избавились мы от double hop, перейдя на деплой пуллера сайдкаром к мастеру.
откладывать на сутки применение WAL параметром recovery_min_apply_delay. Реплика будет эквивалентна бэкапу, сделанному сутки назад. Тогда бэкапы ведь не понадобятся
Это вариант, но он потребует удержания на мастере всех WAL-архивов в течение последних суток, это чревато высоким потреблением места на мастере и может быть очень болезненным для нагруженных по записи баз. Кроме того, дополнительная реплика потребует ресурсов, как вычислительных, так и места на диске, сильно большего, чем нужно для хранения сжатых бэкапов.
Процесс pg_receivewal ведь может получать журнальные данные без задержки и даже синхронно и даже подтверждать транзакции, точно также как синхронная реплика. Это даже отменит необходимость физической реплики.
По сути это будет почти полноценная репликация — pg_receivewal получает WAL'ы с мастера, используя ту же самую потоковую репликацию, что и обычные реплики, с тем лишь исключением, что pg_receivewal не применяет WAL'ы на локальные данные. Если у него включить сжатие, добавить периодический pg_basebackup — то вполне получится самодельный инструмент для резервного копирования =) Отдельно, правда, придется подумать над восстановлением (если нужно восстанавливаться не на тот хост, где находятся бэкапы), и над надёжностью хранения самих бэкапов.
Тем не менее, у WAL-G будет сразу несколько плюсов относительно такого подхода: параллельная архивация/восстановление сильно ускоряют процесс, эффективное сжатие сэкономит место, а хранение данных в S3, у которого под капотом erasure coding, даёт высокую надёжность хранения данных.
Что касается рисков по доступу хакеров к S3, то эта проблема обычно решается политиками доступа S3: мы можем разрешить сервисному аккаунту доступ только на запись в S3, запретив действия по удалению, и включить версионирование данных, таким образом попытки перезаписи объектов не приведут к потере важных данных.
значит ли это, что после восстановления гарантированно будут потеряны последние транзакции объемом до 16Мб?
Небольшая часть транзакций при восстановлении неизбежно будет потеряна в силу асинхронной природы архивации WAL'ов, но это может быть и меньше 16Мб — это зависит от размеров WAL-файлов и частоты их сброса на диск.
Для ненагруженных баз, где WAL'ы заполняются не так часто, имеет смысл выставлять параметр archive_timeout, согласно которому сервер будет переключаться на новый WAL после указанного таймаута.
Это позволит сделать расчёты RPO (recovery point objective) более предсказуемыми — можно будет говорить, например, о потере до последних 5 минут записей с момента наступления инцидента.
если после восстановления транзакции теряются, то, наверное, администраторы для production не захотят его использовать.
Восстановление из бэкапа — это всегда механизм чрезвычайной ситуации, когда данные в исходной СУБД испорчены/удалены.
Он не отменяет необходимости настройки физической синхронной репликации, если потеря даже единичных транзакций критична для бизнеса. Но и репликация не отменяет необходимости в бэкапах: случайное удаление данных, баг в миграциях приложения после обновления — всё это может привести к тому, что даже отказоустойчивый кластер с синхронной репликацией на 3 ДЦ станет полностью неработоспособным и потребуется восстановление из бэкапа.
Если говорим наиболее частой практике — ежедневных бэкапах без непрерывной архивации, то при восстановлении мы неизбежно потеряем до 24 часов транзакций. С непрерывной архивацией WAL'ов мы потерю 24 часов уменьшаем до единиц/десятков минут, что звучит намного привлекательнее для важных баз данных.
Всеми руками поддерживаю использование одиссея в кач-ве пулера соединений для постгреса, но, справедливости ради
...но ведь нормально параллелится с помощью so_reuseport даже в пределах одного контейнера. Не рассматривали ли такой вариант, и почему отмели, если рассматривали?
Боль понятная, но почему бы не использовать .spec.trafficDistribution: PreferSameZone в сервисе перед пулерами? Который https://kubernetes.io/docs/concepts/services-networking/service/#traffic-distribution
Это вариант, но он потребует удержания на мастере всех WAL-архивов в течение последних суток, это чревато высоким потреблением места на мастере и может быть очень болезненным для нагруженных по записи баз. Кроме того, дополнительная реплика потребует ресурсов, как вычислительных, так и места на диске, сильно большего, чем нужно для хранения сжатых бэкапов.
По сути это будет почти полноценная репликация — pg_receivewal получает WAL'ы с мастера, используя ту же самую потоковую репликацию, что и обычные реплики, с тем лишь исключением, что pg_receivewal не применяет WAL'ы на локальные данные. Если у него включить сжатие, добавить периодический pg_basebackup — то вполне получится самодельный инструмент для резервного копирования =) Отдельно, правда, придется подумать над восстановлением (если нужно восстанавливаться не на тот хост, где находятся бэкапы), и над надёжностью хранения самих бэкапов.
В целом подход имеет место быть, его емнип даже реализовали в Barman: https://docs.pgbarman.org/release/3.16.2/user_guide/architectures.html#backup-strategies
Тем не менее, у WAL-G будет сразу несколько плюсов относительно такого подхода: параллельная архивация/восстановление сильно ускоряют процесс, эффективное сжатие сэкономит место, а хранение данных в S3, у которого под капотом erasure coding, даёт высокую надёжность хранения данных.
Что касается рисков по доступу хакеров к S3, то эта проблема обычно решается политиками доступа S3: мы можем разрешить сервисному аккаунту доступ только на запись в S3, запретив действия по удалению, и включить версионирование данных, таким образом попытки перезаписи объектов не приведут к потере важных данных.
Небольшая часть транзакций при восстановлении неизбежно будет потеряна в силу асинхронной природы архивации WAL'ов, но это может быть и меньше 16Мб — это зависит от размеров WAL-файлов и частоты их сброса на диск.
Для ненагруженных баз, где WAL'ы заполняются не так часто, имеет смысл выставлять параметр
archive_timeout, согласно которому сервер будет переключаться на новый WAL после указанного таймаута.Это позволит сделать расчёты RPO (recovery point objective) более предсказуемыми — можно будет говорить, например, о потере до последних 5 минут записей с момента наступления инцидента.
Восстановление из бэкапа — это всегда механизм чрезвычайной ситуации, когда данные в исходной СУБД испорчены/удалены.
Он не отменяет необходимости настройки физической синхронной репликации, если потеря даже единичных транзакций критична для бизнеса. Но и репликация не отменяет необходимости в бэкапах: случайное удаление данных, баг в миграциях приложения после обновления — всё это может привести к тому, что даже отказоустойчивый кластер с синхронной репликацией на 3 ДЦ станет полностью неработоспособным и потребуется восстановление из бэкапа.
Если говорим наиболее частой практике — ежедневных бэкапах без непрерывной архивации, то при восстановлении мы неизбежно потеряем до 24 часов транзакций. С непрерывной архивацией WAL'ов мы потерю 24 часов уменьшаем до единиц/десятков минут, что звучит намного привлекательнее для важных баз данных.