Безопасность в Managed Service for Sharded PostgreSQL

• Как обеспечивается безопасность данных?

• Не утекают ли учетные данные через роутер?

• Как настроить резервное копирование?

• Как обеспечить высокую доступность?

• Что происходит при перегрузках?

• Как обрабатывается отмена запросов?

• Есть ли риски дублирования запросов при использовании балансировщика перед роутерами?

• Как ограничить доступ к административной консоли?

Как обеспечивается безопасность данных?Как обеспечивается безопасность данных?

Sharded PostgreSQL хранит только метаданные о расположении данных. За безопасность данных отвечает сервис Managed Service for PostgreSQL, при этом:

• Поддерживается шифрование трафика — TLS 1.3 для всех соединений (клиент ↔ роутер ↔ шард).
• Доступен аудит — логи доступа хранятся в сервисе Yandex Audit Trails в течение 30 дней. Подробнее о просмотре логов в кластере Managed Service for Sharded PostgreSQL.

Не утекают ли учетные данные через роутер?Не утекают ли учетные данные через роутер?

Нет, данные не утекают. Риски аналогичны использованию пулера подключений (например, Odyssey). Данные передаются через Sharded PostgreSQL, но практики безопасности соответствуют стандартам Yandex Cloud.

Как настроить резервное копирование?Как настроить резервное копирование?

Резервное копирование запускается автоматически для всех задействованных кластеров. Опционально вы можете задать время начала резервного копирования и выбрать срок хранения резервных копий. Подробнее о настройке резервного копирования в Managed Service for Sharded PostgreSQL.

Как обеспечить высокую доступность?Как обеспечить высокую доступность?

Чтобы обеспечить высокую доступность кластера Managed Service for Sharded PostgreSQL:

• Создавайте шарды таким образом, чтобы каждый шард (то есть кластер Managed Service for PostgreSQL) включал не менее трех хостов (мастер и реплики), расположенных в разных зонах доступности.
• Для кластеров Managed Service for Sharded PostgreSQL со стандартным шардированием создайте не менее трех хостов INFRA в разных зонах доступности.
• Для кластеров Managed Service for Sharded PostgreSQL с расширенным шардированием создайте не менее трех хостов COORDINATOR и трех хостов ROUTER в разных зонах доступности.

Что происходит при перегрузках?Что происходит при перегрузках?

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

Например, кластер получает 95% запросов на запись и 5% на чтение. Если параметр конфигурации роутера default_target_session_attrs = read-only, то запросы на чтение равномерно распределяются между репликами. Если в какой-то момент реплика становится недоступной (SELECT pg_is_in_recovery(); не выполняется в заданное время), сервис перестает отправлять запросы к реплике и проверяет ее статус. Как только реплика снова отвечает, отправка запросов к ней возобновляется.

Как обрабатывается отмена запросов?Как обрабатывается отмена запросов?

Приложение прерывает текущее соединение с роутером, открывает новое и отправляет роутеру cancel-сообщение с идентификатором запроса. Роутер получает cancel-сообщение и передает его на шард, которому адресован запрос.

Есть ли риски дублирования запросов при использовании балансировщика перед роутерами?Есть ли риски дублирования запросов при использовании балансировщика перед роутерами?

Да. Если клиент разрывает соединение и балансировщик повторяет запрос, Sharded PostgreSQL обработает его как новый, что может привести к дублированию (например, для INSERT). Рекомендуется использовать идемпотентные операции или реализовать механизм дедупликации на уровне приложения.

Как ограничить доступ к административной консоли?Как ограничить доступ к административной консоли?

Доступ к административной консоли ограничен по умолчанию. Подключиться к консоли можно только с TLS при помощи пароля.

Пароль для доступа к административной консоли задается при создании кластера. При необходимости вы можете изменить пароль на работающем кластере.