PostgreSQL как платформенный сервис¶
Требования применяются к production PostgreSQL, предоставляемому приложению как
платформенный сервис. Общие требования к data services и backup определены в
смежных инфраструктурных документах. Уровни обязательности определены в
корневом README.md.
INF-DAT-002. Роль приложения¶
Уровень: MUST
Применяется к: доступу приложения к production PostgreSQL
Runtime приложения должен использовать отдельную login-role с правами только на необходимые database, schema, tables и operations. Эта роль не должна владеть кластером, создавать роли или databases либо изменять schema, если изменение schema не является явно заявленным runtime-контрактом.
Обоснование¶
Минимальная runtime-role ограничивает последствия дефекта приложения данными и операциями его собственного контракта.
Проверка¶
- запрос membership, ownership и grants runtime-role;
- негативный тест создания роли и database, а также изменения schema вне явно заявленного runtime-контракта;
- негативный доступ к чужой database и schema.
Исключения¶
Операция расширения, требующая повышенных прав, должна выполняться одноразовой административной identity с отдельным approval; её credential должен быть отозван после операции.
INF-DAT-010. Бюджет соединений PostgreSQL¶
Уровень: MUST
Применяется к: клиентским соединениям production PostgreSQL
Платформа должна задать конечный предел соединений и резерв для администрирования, репликации, мониторинга и восстановления. Сумма максимальных соединений всех одновременно возможных экземпляров приложений, jobs и служебных клиентов, включая перекрытие старой и новой версии при rollout и клиентов при failover, не должна превышать доступный клиентский бюджет.
Каждый pool должен иметь конечные размер и время ожидания. Исчерпание бюджета должно возвращать наблюдаемую ошибку или ограничивать нагрузку, а не создавать неограниченное число новых соединений.
Обоснование¶
Независимо допустимые pool способны совместно исчерпать PostgreSQL и заблокировать административное восстановление.
Проверка¶
- расчёт бюджета по server limit, резерву и максимальному числу клиентов;
- rollout и failover с максимальным числом экземпляров;
- нагрузочный тест исчерпания pool и проверка наблюдаемого результата.
Исключения¶
Connection proxy MAY централизовать клиентский budget, если его downstream pool также имеет конечный предел и сохраняет административный резерв PostgreSQL.
INF-DAT-011. Failover и fencing PostgreSQL¶
Уровень: MUST
Применяется к: production PostgreSQL профиля high-availability
Topology должна переживать каждый заявленный в failure_tolerance отказ.
Переключение primary должно быть автоматизировано, а прежний primary должен
терять возможность принимать запись до допуска нового primary. Клиенты должны
обнаруживать новый primary без одновременной записи в обе стороны разделения.
Для данных в области architecture:DATA-BACK-001 режим репликации и критерий
подтверждения commit должны ограничивать потерю подтверждённых транзакций
значением Recovery Point Objective (RPO) проекта. Для воспроизводимых данных
должны быть объявлены максимальная потеря и срок реконструкции.
Обоснование¶
Автоматическое продвижение без fencing создаёт два primary, а режим репликации без связи с RPO оставляет потерю подтверждённых данных неопределённой.
Проверка¶
- failover под непрерывной записью и измерение восстановления относительно SLO;
- network partition с негативной записью в прежний primary;
- сверка подтверждённых транзакций и фактической потери с RPO;
- повторное присоединение прежнего primary без расхождения timeline.
Исключения¶
Не допускаются для fencing. Профиль single-instance находится вне области
требования.
INF-DAT-015. Identity миграции PostgreSQL¶
Уровень: MUST
Применяется к: изменению schema production PostgreSQL
Миграция должна выполняться отдельной identity через управляемую release- операцию. Identity должна быть ограничена целевыми database и schema и не должна создавать или изменять роли, чужие database и schema. Она не должна передаваться runtime приложения после завершения миграции.
Результат операции должен связывать release, версию schema и использованную identity без записи credential.
Обоснование¶
DDL-полномочия не нужны runtime приложения, а отдельная identity делает изменение schema ограниченной и аудируемой release-операцией.
Проверка¶
- запрос grants migration identity;
- выполнение и аудит миграции целевой schema;
- негативное изменение чужой database, schema и роли;
- проверка отсутствия migration credential у runtime workload.
Исключения¶
Операция расширения, недоступная ограниченной migration identity, MAY выполняться одноразовой административной identity с отдельным approval и отзывом credential после операции.