Управление пользователями БД

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы получить список пользователей кластера, выполните команду:

$ yc managed-postgresql user list
     --cluster-name <имя кластера>

Имя кластера можно запросить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы создать пользователя в кластере, выполните команду:

$ yc managed-postgresql user create <имя пользователя>
     --cluster-name <имя кластера>
     --password=<пароль для пользователя>
     --permissions=<список баз, к которым пользователь должен иметь доступ>
     --conn-limit=<максимальное количество соединений для пользователя>

В этой команде указаны только основные настройки пользователя.

Чтобы задать настройки СУБД для пользователя, воспользуйтесь параметрами, описанными в разделе Настройки СУБД.

Имя кластера можно запросить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы изменить пароль пользователя, выполните команду:

$ yc managed-postgresql user update <имя пользователя>
     --cluster-name=<имя кластера>
     --password=<новый пароль>

Имя кластера можно запросить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Из интерфейса командной строки можно изменить настройки пользователя:

1. Чтобы настроить права пользователя на доступ к определенным базам данных, выполните команду, перечислив список имен баз данных с помощью параметра --permissions:

   $ yc managed-postgresql user update <имя пользователя>
        --cluster-name=<имя кластера>
        --permissions=<список баз, к которым пользователь должен иметь доступ>
   

   Имя кластера можно запросить со списком кластеров в каталоге.

   Эта команда предоставляет пользователю доступ к базам данных, указанным в списке.

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

2. Чтобы изменить настройки PostgreSQL для пользователя, передайте параметры, отвечающие за требуемые настройки, в команде:

   $ yc managed-postgresql user update <имя пользователя>
        --cluster-name=<имя кластера>
        --<настройка 1>=<значение 1>
        --<настройка 2>=<значение 2>
        --<настройка 3>=<список значений>
        ...
   

   Имя кластера можно запросить со списком кластеров в каталоге.

Если у вас еще нет интерфейса командной строки Яндекс.Облака, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Чтобы удалить пользователя, выполните команду:

$ yc managed-postgresql user delete <имя пользователя>
     --cluster-name <имя кластера>

Имя кластера можно запросить со списком кластеров в каталоге.

Доступны следующие настройки:

• --сonn-limit — максимальное допустимое количество соединений для пользователя.

  В сессионном пулинге (session pooling) эта настройка ограничивает количество соединений пользователя к каждому хосту в PostgreSQL-кластере.
  При использовании этого типа пулинга необходимо, чтобы значение настройки было не меньше суммы всех соединений, которые могут быть открыты бэкендами сервиса, использующего PostgreSQL. При этом важно помнить, что каждое открытое серверное соединение немного замедляет работу PostgreSQL на OLTP-нагрузке (Online Transaction Processing).

  В транзакционном пулинге (transaction pooling) эта настройка ограничивает количество соединений пользователя, которые одновременно находятся в транзакции. При использовании этого типа пулинга пользователь может открыть тысячи соединений, но одновременно работать смогут только N соединений, где N — значение настройки.

  Все, описанное ниже, справедливо для сессионного пулинга:

  • При добавлении пользователя Managed Service for PostgreSQL по умолчанию резервирует для него 50 подключений к каждому хосту в PostgreSQL-кластере. Минимальное количество подключений на пользователя — 10.
  • Суммарное количество подключений, зарезервированных для пользователей, не должно превышать значение параметра max_connections, который был указан при создании кластера. При этом нужно учитывать, что Managed Service for PostgreSQL резервирует 15 подключений для служебных пользователей на каждом PostgreSQL-хосте. Например, если для кластера задан параметр "max_connections": 100, то вы можете зарезервировать не больше 85 подключений на каждый хост кластера для пользователей.
  • Рекомендуется разнести разные сервисы, использующие PostgreSQL, по разным пользователям и задать нужное значение настройки для каждого пользователя.
    Таким образом, если при проблемах в одном сервисе начнет создаваться большое количество соединений, другие сервисы не будут затронуты и смогут создавать соединения к PostgreSQL.

• --default-transaction-isolation — для каждой транзакции в SQL устанавливается уровень изоляции. Эта настройка определяет уровень изоляции, который будет устанавливаться по умолчанию для новых транзакций SQL.

  Допустимые значения:

  • transaction-isolation-read-committed (по умолчанию) — запрос видит только те строки, которые были зафиксированы до начала его выполнения.

  • transaction-isolation-read-uncommitted — поведение этого уровня изоляции в PostgreSQL идентично transaction-isolation-read-committed.

  • transaction-isolation-repeatable-read — все запросы в текущей транзакции видят только те строки, которые были зафиксированы перед первым выполненным в этой транзакции запросом на выборку или изменение данных.

  • transaction-isolation-serializable — обеспечивает самый строгий уровень изоляции из всех приведенных выше

    Все запросы в текущей транзакции видят только те строки, которые были зафиксированы перед первым выполненным в этой транзакции запросом на выборку или изменение данных. Если наложение операций чтения и записи параллельных сериализуемых транзакций может привести к ситуации, невозможной при последовательном их выполнении, произойдет откат одной из транзакций с ошибкой «сбой сериализации».

  Подробнее об уровнях изоляции см. в документации PostgreSQL.

• --login — включает или выключает возможность входа пользователя на кластер PostgreSQL.

  Значение по умолчанию: true (пользователю разрешен вход на кластер).

• --lock-timeout — максимальная длительность ожидания (в миллисекундах) любым оператором получения блокировки таблицы, индекса, строки или другого объекта базы данных. Если ожидание не закончилось за указанное время, оператор прерывается.

  Минимальное значение и значение по умолчанию: 0 (контроль длительности отключен, ожидать получения блокировки можно сколь угодно долго).

• --log-statement — фильтр команд SQL, которые должны записываться в лог для указанного пользователя:

  • log-statement-none (по умолчанию) — фильтр отключен, команды SQL не записываются в лог.
  • log-statement-ddl — в лог записываются команды SQL, которые позволяют изменять определения данных (такие как CREATE, ALTER, DROP и другие).
  • log-statement-mod — в лог записываются команды SQL, попадающие под фильтр log-statement-ddl, и команды, позволяющие изменять данные (такие как INSERT, UPDATE и другие).
  • log-statement-all — в лог записываются все команды SQL.

  Подробнее см. в документации PostgreSQL.

• --log-min-duration-statement — настройка логирования длительности выполнения команд SQL.

  В лог записывается продолжительность выполнения всех команд, время обработки которых равно или превышает указанное в значении настройки количество миллисекунд. Например, при значении настройки 500 в лог не попадет выражение, выполнявшееся 300 миллисекунд, а выражение, выполнявшееся 2000 миллисекунд — попадет.

  Значение 0 заставляет записывать продолжительность работы всех команд.

  Значение -1 (по умолчанию) отключает запись продолжительности выполнения команд.

  Рекомендуется определить для каждого сервиса и соответствующего ему пользователя, что считается медленным выполнением запроса, и задать соответствующее значение настройки, чтобы логировать «тяжелые» запросы от сервиса. Например, для веб-сервиса медленным может считаться запрос, выполняющийся более одной секунды, а для сервиса построения отчетов — запрос, выполняющийся более 10 минут.

  Подробнее см. в документации PostgreSQL.

• --synchronous-commit — эта настройка определяет, будет ли СУБД выполнять операцию подтверждения транзакции синхронно.

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

  Допустимые значения:

  • synchronous-commit-off — транзакция подтверждается, даже если данные еще не попали в WAL (Write Ahead Log). Синхронной записи нет, данные о транзакции могут буть потеряны в результате сбоя дисковой подсистемы.
  • synchronous-commit-on (по умолчанию) — транзакция подтверждается, если WAL записан на диск мастера и на диск синхронной реплики.
  • synchronous-commit-local — транзакция подтверждается, если WAL записан на диск мастера.
  • synchronous-commit-remote-apply — транзакция подтверждается, если WAL записан на диск мастера, синхронная реплика приняла WAL и применила изменения из него.
  • synchronous-commit-remote-write — транзакция подтверждается, если WAL записан на диск мастера, синхронная реплика приняла WAL и передала его операционной системе для записи на диск. В случае потери дисковой системы мастера и сбоя операционной системы на реплике данные транзакции с таким уровнем синхронизации могут быть утеряны.

  Подробнее см. в документации PostgreSQL.

• --temp-file-limit — максимальный объем дискового пространства (в килобайтах), который один процесс сможет использовать для временных файлов. Транзакция, которая попытается превысить этот предел, будет отменена.

  Большие запросы из-за их размера выполняются не в оперативной памяти, а на диске. Слишком большие запросы могут нагрузить диск и помешать выполнению других запросов. Эта настройка предотвращает выполнение запросов, которые могут сильно повлиять на производительность, ограничивая размер временных файлов.

  Значение по умолчанию: -1 (нет ограничений).

  Подробнее см. в документации PostgreSQL.