Yandex.Cloud
  • Сервисы
  • Почему Yandex.Cloud
  • Сообщество
  • Тарифы
  • Документация
  • Связаться с нами
Подключиться
Yandex Managed Service for PostgreSQL
  • Начало работы
  • Пошаговые инструкции
    • Все инструкции
    • Информация об имеющихся кластерах
    • Создание кластера
    • Подключение к базе данных
    • Остановка и запуск кластера
    • SQL-запросы в консоли управления
    • Изменение настроек кластера и базы данных
    • Подключение к DataLens
    • Управление хостами PostgreSQL
    • Управление базами данных
    • Управление PostgreSQL-расширениями
    • Управление пользователями БД
    • Назначение привилегий и ролей
    • Управление резервными копиями
    • Удаление кластера
    • Миграция базы данных в Yandex.Cloud
    • Создание логической реплики Аmazon RDS для PostgreSQL в Managed Service for PostgreSQL
  • Сценарии использования
    • Создание кластера PostgreSQL для 1С
  • Концепции
    • Взаимосвязь ресурсов сервиса
    • Классы хостов
      • Действующие классы хостов
      • Архив
        • До 1 июня 2020 года
      • Использование устаревших классов хостов
    • Сеть в Managed Service for PostgreSQL
    • Квоты и лимиты
    • Типы хранилища
    • Резервные копии
    • Назначение ролей
    • Репликация
    • Поддерживаемые клиенты
  • Управление доступом
  • Правила тарификации
    • Действующие правила
    • Архив
      • До 1 января 2019 года
      • С 1 января до 1 марта 2019 года
      • С 1 марта 2019 года до 1 февраля 2020 года
  • Справочник API
    • Аутентификация в API
    • gRPC
      • Обзор
      • BackupService
      • ClusterService
      • DatabaseService
      • ResourcePresetService
      • UserService
      • OperationService
    • REST
      • Обзор
      • Backup
        • Обзор
        • get
        • list
      • Cluster
        • Обзор
        • addHosts
        • backup
        • create
        • delete
        • deleteHosts
        • get
        • list
        • listBackups
        • listHosts
        • listLogs
        • listOperations
        • move
        • restore
        • start
        • startFailover
        • stop
        • update
        • updateHosts
      • Database
        • Обзор
        • create
        • delete
        • get
        • list
        • update
      • ResourcePreset
        • Обзор
        • get
        • list
      • User
        • Обзор
        • create
        • delete
        • get
        • grantPermission
        • list
        • revokePermission
        • update
      • Operation
        • Обзор
        • get
  • Вопросы и ответы
    • Общие вопросы
    • Вопросы о PostgreSQL
    • Все вопросы на одной странице
  1. Пошаговые инструкции
  2. Управление пользователями БД

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

  • Получить список пользователей
  • Добавить пользователя
  • Изменить пароль
  • Изменить настройки пользователя
  • Удалить пользователя
  • Примеры
    • Создание пользователя с настройкой «только чтение»
  • Дополнительные настройки

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

Получить список пользователей

Консоль управления
CLI
  1. Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
  2. Нажмите на имя нужного кластера, затем выберите вкладку Пользователи.

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

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

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

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

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

Добавить пользователя

Консоль управления
CLI
  1. Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
  2. Нажмите на имя нужного кластера и выберите вкладку Пользователи.
  3. Нажмите кнопку Добавить.
  4. Введите имя пользователя базы данных и пароль (от 8 до 128 символов).
  5. Выберите одну или несколько баз данных, к которым должен иметь доступ пользователь:
    1. Выберите базу данных из выпадающего списка База данных.
    2. Нажмите кнопку Добавить справа от выпадающего списка.
    3. Повторите два предыдущих шага, пока не будут выбраны все требуемые базы данных.
    4. Чтобы удалить базу, добавленную по ошибке, нажмите значок справа от имени базы в перечне Права.
  6. Задайте настройки СУБД для пользователя.
  7. Нажмите кнопку Добавить.

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

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

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

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

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

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

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

Примечание

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

Изменить пароль

Консоль управления
CLI

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

  1. Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
  2. Нажмите на имя нужного кластера и выберите вкладку Пользователи.
  3. Нажмите значок и выберите пункт Изменить пароль.
  4. Задайте новый пароль и нажмите кнопку Изменить.

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

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

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

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

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

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

Примечание

Привилегии и роли PostgreSQL не затрагиваются этими настройками и настраиваются отдельно.

О том, как задать привилегии и роли для пользователя, читайте в разделе Назначение привилегий и ролей пользователям.

Консоль управления
CLI

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

  1. Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
  2. Нажмите на имя нужного кластера и выберите вкладку Пользователи.
  3. Нажмите значок и выберите пункт Настройки.
  4. Настройте права пользователя на доступ к определенным базам данных:
    1. Чтобы предоставить доступ к требуемым базам данных:
      1. Выберите базу данных из выпадающего списка База данных.
      2. Нажмите кнопку Добавить справа от выпадающего списка.
      3. Повторите два предыдущих шага, пока не будут выбраны все требуемые базы данных.
    2. Чтобы отозвать доступ к определенной базе, удалите ее из перечня Права, нажав значок справа от имени базы.
  5. Измените настройки PostgreSQL для пользователя в разделе Настройки СУБД.
  6. Нажмите кнопку Сохранить.

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

По умолчанию используется каталог, указанный в профиле 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
  1. Перейдите на страницу каталога и выберите сервис Managed Service for PostgreSQL.
  2. Нажмите на имя нужного кластера и выберите вкладку Пользователи.
  3. Нажмите значок и выберите пункт Удалить.

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

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

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

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

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

Примеры

Создание пользователя с настройкой «только чтение»

Допустим, нужно добавить в существующий кластер нового пользователя user2, причем:

  • пользователь должен иметь доступ к базе данных db1 кластера, в том числе:
    • к таблице Products в схеме по умолчанию public;
    • ко всем таблицам схемы myschema;
  • доступ должен осуществляться в режиме «только чтение» (readonly), без возможности изменения настроек.

Для этого выполните следующие действия:

  1. Создайте пользователя с именем user2. При этом выберите базы данных, к которым должен иметь доступ пользователь.

  2. Подключитесь к базе данных db1 с помощью учетной записи владельца БД.

  3. Выполните команды:

    GRANT SELECT ON public.Products TO user2;
    
    GRANT SELECT ON ALL TABLES IN SCHEMA myschema TO user2;
    GRANT USAGE ON SCHEMA myschema TO user2;
    
  4. Для отзыва выданных привилегий выполните команды:

    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 при работе с запросами пользователя.

Консоль управления
CLI

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

  • 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.

В этой статье:
  • Получить список пользователей
  • Добавить пользователя
  • Изменить пароль
  • Изменить настройки пользователя
  • Удалить пользователя
  • Примеры
  • Создание пользователя с настройкой «только чтение»
  • Дополнительные настройки
Language
Вакансии
Политика конфиденциальности
Условия использования
© 2021 ООО «Яндекс.Облако»