Базы данных на DevOps-собеседовании

Если индекс есть, а запрос медленный, причин обычно четыре. В условии функция или приведение типа: lower(email) не попадает в индекс по email. У колонки всего пара значений вроде «оплачен — не оплачен». В составном индексе первой стоит не та колонка. Или таблица настолько маленькая, что прочитать её целиком дешевле.

В режиме transaction ломается всё, что живёт в сессии: SET на всю сессию, временные таблицы, advisory-блокировки (их приложение берёт само по своему ключу). Следующая транзакция может уйти в другое серверное соединение, где ничего этого нет. Если сказать про это самому, не дожидаясь вопроса, ответ сильно выигрывает.

Частоту checkpoint выбирают между двумя бедами. Частые checkpoint больше пишут на диск. Редкие удлиняют восстановление после падения: журнал приходится проигрывать с более давнего места.

Split-brain — это когда два сервера одновременно считают себя мастером и оба принимают запись. Не дают ему случиться кворум в etcd (без большинства лидером не стать) и watchdog, который перезагружает ноду, если Patroni на ней завис и не успел снять роль мастера. И про цену: при асинхронной репликации переключение быстрое, но транзакции, не доехавшие до реплики, пропадут. Синхронная их сохранит, но каждый коммит будет ждать реплику.

Хороший ответ заканчивается вопросом к бизнесу: сколько данных можно потерять (RPO) и за сколько нужно подняться (RTO). От этих двух чисел зависит, хватит ли ночного pg_dump. И две вещи стоит сказать самому. Реплика не бэкап: ошибочный DELETE доедет и до неё. А бэкап, из которого ни разу не пробовали восстановиться, бэкапом не считается.

Согласованность из ACID и из CAP — разные вещи. В ACID речь о правилах внутри одной базы, в CAP — о том, одинаковые ли данные видят узлы распределённой системы.