@pasha_a
Люблю ставить перед собой цели и добиваться их.

Как обеспечить отказоустойчивость БД Postgres?

Добрый день!

Разрабатываю web сервис.
Сервис написал на Java(Spring), фронтенд - Javascript, база данных Postgres 10.4
Крутиться это все на Ubuntu 16.04
Очень желательно чтобы сервис был доступен 24 часа 7 дней в неделю.

Основное назначение БД это хранение структуры данных (которая меняется нечасто) и логирование всех операций,
производимых с данными (SQL БД была выбрана ввиду того, что с данными удобно работать посредством реляционной БД, а сами логи тоже имеют довольно разветвленную структуру, связанную между собой и нужно осуществлять различные хитрые запросы с JOIN и т.п.).

Надежность и отказоустойчивость, если я правильно понимаю, будет состоять из нескольких составляющих:
- надежность железа (в том числе интернет соединение),
- надежность БД,
- надежность самого сервиса, который крутиться на JVM.

Чтобы не создавать излишне масштабный вопрос, я хотел бы сначала понять насколько надежна СУБД Postgres.

В частности меня интересует как правильно обеспечить надежность и безотказность ее работы?

Планируемые мероприятия (в меру моего понимания вещей):
- планирую делать ежедневный автоматический бекап самой базы данных (с помощью скриптов в ночное время),
Старые бекапы по истечению какого-то промежутка времени будут удаляться.
- с помощью какого-то скрипта или утилитки мониторить доступность базы данных и, в случае проблем с доступностью, перезапускать/запускать саму СУБД.

Посоветуйте что еще можно предпринять чтобы обеспечить надежную работу БД.
Возможно есть какие-то best-practices какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам.
  • Вопрос задан
  • 555 просмотров
Пригласить эксперта
Ответы на вопрос 3
Melkij
@Melkij
PostgreSQL DBA
как правильно обеспечить надежность и безотказность ее работы?

Использовать адекватное железо и не мешать базе работать шаловливыми ручками.

доступен 24 часа 7 дней в неделю.

бекап

Объясните, пожалуйста, как это по вашему мнению между собой связано?
Бекапы необходимы, но как они связаны с высокой доступностью?

в случае проблем с доступностью, перезапускать/запускать саму СУБД.

Простой вопрос: зачем?
Если база сложилась и даже не смогла подняться самостоятельно - значит проблема капительная и разбираться надо детально. Рестартом по кругу вы можете скорее сделать совсем плохо, чем что-либо починить.
При том обычно проблемы начинаются от того что разработчики выкатили новую версию приложения и та начинает делать что-то странное. Например, забыли сделать индекс на 50гб табличку и засунули запрос с поиском по ней на главную сайта. Рестартом базы это, разумеется, не исправляется. А делает только больнее.

Многолетней давности pg_postmaster_start_time() впечатлять не буду - мы периодически ставим минорные апдейты на свои базы. И вам тоже весьма рекомендую обновиться до 10.7 или лучше уже на следующих выходных сразу до 10.8.

А так, если не трогать - то годами будет работать. Мониторинг и алерты от него, разумеется, нужны. Какая-то автоматика при наступлении алерта - обычно приносит куда больше головной боли, чем помогает.

какие операции, запросы или их комбинации нежелательны для БД и могут привести к проблемам.

Большая часть инцидентов с недоступностью сервиса с точки зрения приложения - про уровни блокировок. Кто-нибудь попробует сделать create index вместо create index concurrently и привет ожидание блокировки на всю запись в таблицу. Большинство форм alter table сюда же, но они и чтение заблокируют.
Ответ написан
Комментировать
Xuxicheta
@Xuxicheta
инженер
Ответ написан
Комментировать
@nrgian
Никак.

Можно только приблизится.

Master-slave, к примеру, поможет не потерять данные PostgreSQL, но это не означает, что система корректно переключится на полноценную работу со slave при выходе из строя master. Принимать решение о переключении придется вручную.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы