Управление пользователями БД
Вы можете добавлять и удалять пользователей, а также управлять их индивидуальными настройками.
Получить список пользователей
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера, затем выберите вкладку Пользователи.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы получить список пользователей кластера, выполните команду:
$ yc managed-postgresql user list
--cluster-name <имя кластера>
Имя кластера можно запросить со списком кластеров в каталоге.
Добавить пользователя
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Пользователи.
- Нажмите кнопку Добавить.
- Введите имя пользователя базы данных и пароль (от 8 до 128 символов).
- Выберите одну или несколько баз данных, к которым должен иметь доступ пользователь:
- Выберите базу данных из выпадающего списка База данных.
- Нажмите кнопку Добавить справа от выпадающего списка.
- Повторите два предыдущих шага, пока не будут выбраны все требуемые базы данных.
- Чтобы удалить базу, добавленную по ошибке, нажмите значок справа от имени базы в перечне Права.
- Задайте настройки СУБД для пользователя.
- Нажмите кнопку Добавить.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы создать пользователя в кластере, выполните команду:
$ yc managed-postgresql user create <имя пользователя>
--cluster-name <имя кластера>
--password=<пароль для пользователя>
--permissions=<список баз, к которым пользователь должен иметь доступ>
--conn-limit=<максимальное количество соединений для пользователя>
В этой команде указаны только основные настройки пользователя.
Чтобы задать настройки СУБД для пользователя, воспользуйтесь параметрами, описанными в разделе Настройки СУБД.
Имя кластера можно запросить со списком кластеров в каталоге.
Примечание
Сразу после создания пользователь получает только привилегию CONNECT
для выбранных баз данных, и не может выполнять никакие операции с базами данных. Чтобы дать пользователю доступ к базам, назначьте ему нужные привилегии или роли.
Изменить пароль
Чтобы изменить пароль пользователя:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Пользователи.
- Нажмите значок и выберите пункт Изменить пароль.
- Задайте новый пароль и нажмите кнопку Изменить.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы изменить пароль пользователя, выполните команду:
$ yc managed-postgresql user update <имя пользователя>
--cluster-name=<имя кластера>
--password=<новый пароль>
Имя кластера можно запросить со списком кластеров в каталоге.
Изменить настройки пользователя
Примечание
Привилегии и роли PostgreSQL не затрагиваются этими настройками и настраиваются отдельно.
О том, как задать привилегии и роли для пользователя, читайте в разделе Назначение привилегий и ролей пользователям.
Чтобы изменить настройки пользователя:
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Пользователи.
- Нажмите значок и выберите пункт Настройки.
- Настройте права пользователя на доступ к определенным базам данных:
- Чтобы предоставить доступ к требуемым базам данных:
- Выберите базу данных из выпадающего списка База данных.
- Нажмите кнопку Добавить справа от выпадающего списка.
- Повторите два предыдущих шага, пока не будут выбраны все требуемые базы данных.
- Чтобы отозвать доступ к определенной базе, удалите ее из перечня Права, нажав значок справа от имени базы.
- Чтобы предоставить доступ к требуемым базам данных:
- Измените настройки PostgreSQL для пользователя в разделе Настройки СУБД.
- Нажмите кнопку Сохранить.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Из интерфейса командной строки можно изменить настройки пользователя:
-
Чтобы настроить права пользователя на доступ к определенным базам данных, выполните команду, перечислив список имен баз данных с помощью параметра
--permissions
:$ yc managed-postgresql user update <имя пользователя> --cluster-name=<имя кластера> --permissions=<список баз, к которым пользователь должен иметь доступ>
Имя кластера можно запросить со списком кластеров в каталоге.
Эта команда предоставляет пользователю доступ к базам данных, указанным в списке.
Чтобы отозвать доступ к определенной базе, исключите ее имя из списка и передайте команде обновленный список.
-
Чтобы изменить настройки PostgreSQL для пользователя, передайте параметры, отвечающие за требуемые настройки, в команде:
$ yc managed-postgresql user update <имя пользователя> --cluster-name=<имя кластера> --<настройка 1>=<значение 1> --<настройка 2>=<значение 2> --<настройка 3>=<список значений> ...
Имя кластера можно запросить со списком кластеров в каталоге.
Удалить пользователя
- Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
- Нажмите на имя нужного кластера и выберите вкладку Пользователи.
- Нажмите значок и выберите пункт Удалить.
Если у вас еще нет интерфейса командной строки Yandex.Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name
или --folder-id
.
Чтобы удалить пользователя, выполните команду:
$ yc managed-postgresql user delete <имя пользователя>
--cluster-name <имя кластера>
Имя кластера можно запросить со списком кластеров в каталоге.
Примеры
Создание пользователя с настройкой «только чтение»
Допустим, нужно добавить в существующий кластер нового пользователя user2
, причем:
- пользователь должен иметь доступ к базе данных db1 кластера, в том числе:
- к таблице
Products
в схеме по умолчаниюpublic
; - ко всем таблицам схемы
myschema
;
- к таблице
- доступ должен осуществляться в режиме «только чтение» (readonly), без возможности изменения настроек.
Для этого выполните следующие действия:
-
Создайте пользователя с именем
user2
. При этом выберите базы данных, к которым должен иметь доступ пользователь. -
Подключитесь к базе данных db1 с помощью учетной записи владельца БД.
-
Выполните команды:
GRANT SELECT ON public.Products TO user2; GRANT SELECT ON ALL TABLES IN SCHEMA myschema TO user2; GRANT USAGE ON SCHEMA myschema TO user2;
-
Для отзыва выданных привилегий выполните команды:
REVOKE SELECT ON public.Products FROM user2; REVOKE SELECT ON ALL TABLES IN SCHEMA myschema FROM user2; REVOKE USAGE ON SCHEMA myschema FROM user2;
Дополнительные настройки
Эти настройки влияют на поведение PostgreSQL при работе с запросами пользователя.
Доступны следующие настройки:
-
Conn 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.
Допустимые значения:
-
read committed
(по умолчанию) — запрос видит только те строки, которые были зафиксированы до начала его выполнения. -
read uncommitted
— поведение этого уровня изоляции в PostgreSQL идентичноread committed
. -
repeatable read
— все запросы в текущей транзакции видят только те строки, которые были зафиксированы перед первым выполненным в этой транзакции запросом на выборку или изменение данных. -
serializable
— обеспечивает самый строгий уровень изоляции из всех приведенных выше.Все запросы в текущей транзакции видят только те строки, которые были зафиксированы перед первым выполненным в этой транзакции запросом на выборку или изменение данных. Если наложение операций чтения и записи параллельных сериализуемых транзакций может привести к ситуации, невозможной при последовательном их выполнении, произойдет откат одной из транзакций с ошибкой «сбой сериализации».
Подробнее об уровнях изоляции см. в документации PostgreSQL.
-
-
Synchronous commit — эта настройка определяет, будет ли СУБД выполнять операцию подтверждения транзакции синхронно.
Синхронность операции означает, что кластер будет ждать выполнения синхронных операций, гарантирующих различные уровни сохранности и видимости данных в кластере, прежде чем подтвердить транзакцию клиенту.
Допустимые значения:
off
— транзакция подтверждается, даже если данные еще не попали в WAL (Write Ahead Log). Синхронной записи нет, данные о транзакции могут буть потеряны в результате сбоя дисковой подсистемы.on
(по умолчанию) — транзакция подтверждается, если WAL записан на диск мастера и на диск синхронной реплики.local
— транзакция подтверждается, если WAL записан на диск мастера.remote_apply
— транзакция подтверждается, если WAL записан на диск мастера, синхронная реплика приняла WAL и применила изменения из него.remote_write
— транзакция подтверждается, если WAL записан на диск мастера, синхронная реплика приняла WAL и передала его операционной системе для записи на диск. В случае потери дисковой системы мастера и сбоя операционной системы на реплике данные транзакции с таким уровнем синхронизации могут быть утеряны.
Подробнее см. в документации PostgreSQL.
-
Lock timeout — максимальная длительность ожидания (в миллисекундах) любым оператором получения блокировки таблицы, индекса, строки или другого объекта базы данных. Если ожидание не закончилось за указанное время, оператор прерывается.
Минимальное значение и значение по умолчанию:
0
(контроль длительности отключен, ожидать получения блокировки можно сколь угодно долго). -
Log statement — фильтр команд SQL, которые должны записываться в лог для указанного пользователя:
none
(по умолчанию) — фильтр отключен, команды SQL не записываются в лог.ddl
— в лог записываются команды SQL, которые позволяют изменять определения данных (такие какCREATE
,ALTER
,DROP
и другие).mod
— в лог записываются команды SQL, попадающие под фильтрddl
, и команды, позволяющие изменять данные (такие какINSERT
,UPDATE
и другие).all
— в лог записываются все команды SQL.
Подробнее см. в документации PostgreSQL.
-
Log min duration statement — настройка логирования длительности выполнения команд SQL.
В лог записывается продолжительность выполнения всех команд, время обработки которых равно или превышает указанное в значении настройки количество миллисекунд. Например, при значении настройки
500
в лог не попадет выражение, выполнявшееся 300 миллисекунд, а выражение, выполнявшееся 2000 миллисекунд — попадет.Значение
0
заставляет записывать продолжительность работы всех команд.Значение
-1
(по умолчанию) отключает запись продолжительности выполнения команд.Рекомендуется определить для каждого сервиса и соответствующего ему пользователя, что считается медленным выполнением запроса, и задать соответствующее значение настройки, чтобы логировать «тяжелые» запросы от сервиса. Например, для веб-сервиса медленным может считаться запрос, выполняющийся более одной секунды, а для сервиса построения отчетов — запрос, выполняющийся более 10 минут.
Подробнее см. в документации PostgreSQL.
-
Temp file limit — максимальный объем дискового пространства (в килобайтах), который один процесс сможет использовать для временных файлов. Транзакция, которая попытается превысить этот предел, будет отменена.
Большие запросы из-за их размера выполняются не в оперативной памяти, а на диске. Слишком большие запросы могут нагрузить диск и помешать выполнению других запросов. Эта настройка предотвращает выполнение запросов, которые могут сильно повлиять на производительность, ограничивая размер временных файлов.
Значение по умолчанию:
-1
(нет ограничений).Подробнее см. в документации PostgreSQL.
Доступны следующие настройки:
-
--с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.