Как защитить базу postgres от ошибочного запроса?

Question

[Евгений Петров]

Всем привет!

Вопрос, который никак не дает заснуть: вот к примеру есть многомиллионная база, настроена репликация на случай выхода мастера из строя. Однако, репликация не поможет, если администратор базы ошибочно сделал неправильный запрос (к примеру UPDATE без WHERE, ну мало ли, человеческий фактор), так как все запросы к мастеру идут также к ведомому и в результате получаем тыкву из двух баз (потом конечно кое-кого повесят). Каким образом можно защититься от подобного рода ошибок?

Comments

[Евгений Петров]

user_of_toster, бекапы делаются раз в сутки, но за сутки пройдут тысячи операции, которые могут быть потеряны

[Fallenyasha]

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

Ну а если уж совсем кривые руки у админа, то можно нарисовать простенькую веб морду для выполнения запросов изменения и там валидировать все что можно накосячить, но проще сразу повесить :)

[Евгений Петров]

Fallenyasha, :)
благодарю всех, мысли поставлены в нужном направлении, пойду-ка их применять)

Answer 1

[Сергей Горностаев]

Бэкапы и обязательно ревью всех мутирующих запросов.

Comments

[Евгений Петров]

спасибо за ответ, бекапы делаются раз в сутки, но за сутки пройдут тысячи операции, которые могут быть потеряны

[Сергей Горностаев]

Евгений Петров, их можно делать и чаще.

[Slava Rozhnev]

Евгений Петров, Я пользуюсь WAL-G. Настроил бэкапы каждые 5 мин.

Answer 2

[ky0]

Можно настроить вторую реплику с отсрочкой применения изменений (recovery_min_apply_delay). Ну а вообще - бэкапы и не лазить лишний раз суперюзером в базу.

Answer 3

[Василий Банников]

к примеру UPDATE без WHERE, ну мало ли, человеческий фактор

Каким образом можно защититься от подобного рода ошибок?

1. Бэкапы
2. Ограничить человеческий фактор
- Делать как можно меньше запросов вручную
- Ограничить круг людей, которые могут это регулярно делать
- Убрать соблазн сделать запись вручную (в datagrip можно поставить галочку на базу, как read-only и без подтверждения не получится послать туда запрос не на чтение)

Comments

[Евгений Петров]

ограничить человеческий фактор - это ладно, но вот написан некий код, где разраб забыл указать WHERE, ну да, запрос сначала тестируется, но все же как-то просочился в продакшн и тогда писец)

[Сергей Горностаев]

Евгений Петров, от "просачивающегося" в прод не защитится. Крупнейшие мировые компании в серьёзнейших продуктах регулярно попадают на очень неприятные последствия багов, проскочивших ревью.

[Василий Банников]

Евгений Петров, от просачивания на 100% защититься нельзя. Вернее можно, но тогда надо будет делать ревью каждой строчки кода и фиксировать на бумаге каждого ревьюера и их отчёты по ней. + потом проводить независимое ревью на ревью, аудиты, покрывать абсолютно всё исчерпывающими тестами, ревьюить их тоже, проводить ещё формальную верификацию всего кода и тп.
Примерно так и делают при разработке ПО для самолётов, ракет, АЭС и всяких атомных бомб например.
Правда скорость разработки тогда упадёт на дно, а цена улетит в космос.

[Евгений Петров]

Я понял в каком направлении идти, Всем спасибо в обсуждении вопроса :)