Связаться с намиПодключиться

Вопросы и ответы про Managed Service for PostgreSQL

Статья создана
Улучшена
Обновлена 27 ноября 2025 г.

Примечание

В регионе Казахстан доступны только платформы standard-v3 (Intel Ice Lake) и standard-v3-t4i (Intel Ice Lake with T4i). Другие типы платформ, кластеры GPU и выделенные хосты недоступны.

Общие вопросы

Подключение

Изменение кластера

Настройки параметров кластера

Перемещение и восстановление кластера

Пользователи и роли

Высокая доступность и балансировка

Мониторинг и логи

Сообщения об ошибках

Общие вопросы

Что такое Managed Service for PostgreSQL?

Managed Service for PostgreSQL — это сервис, который помогает вам создавать, эксплуатировать и масштабировать базы данных PostgreSQL в облачной инфраструктуре.

С Managed Service for PostgreSQL вы можете:

  • создавать базы данных с необходимыми параметрами производительности;
  • масштабировать вычислительные мощности и выделенный объем хранилища для баз данных по мере необходимости;
  • получать журналы работы баз данных.

Managed Service for PostgreSQL берет на себя трудоемкие задачи администрирования инфраструктуры PostgreSQL:

  • предоставляет мониторинг потребляемых ресурсов;
  • автоматически создает резервные копии баз данных;
  • обеспечивает отказоустойчивость за счет автоматического переключения на резервные реплики;
  • своевременно обновляет программное обеспечение СУБД.

Вы взаимодействуете с кластером БД в Managed Service for PostgreSQL как с обычной базой данных в вашей локальной инфраструктуре. Благодаря этому вы можете управлять внутренними настройками БД в соответствии с требованиями вашего приложения.

Какую часть работы по управлению и сопровождению баз данных берет на себя Managed Service for PostgreSQL?

При создании кластеров Managed Service for PostgreSQL выделяет ресурсы, устанавливает СУБД и создает базы данных.

Для созданных и запущенных баз данных Managed Service for PostgreSQL автоматически создает резервные копии, а также устанавливает исправления и обновления СУБД.

Также Managed Service for PostgreSQL обеспечивает репликацию данных между хостами БД (как внутри, так и между зонами доступности) и автоматически переключает нагрузку на резервную реплику в случае аварии.

При работе необходимо учитывать, что контролирует сервис, а что — клиент Yandex Cloud. Понимание этих зон контроля помогает эффективно использовать облачные ресурсы и избегать возможных проблем при работе с базами данных. Подробнее см. Разграничение зон контроля пользователей сервисов управляемых баз данных (MDB) и Yandex Cloud.

Для каких задач стоит использовать Managed Service for PostgreSQL, а для каких — виртуальные машины с базами данных?

Yandex Cloud предлагает два варианта работы с базами данных:

  • Managed Service for PostgreSQL позволяет вам эксплуатировать шаблонные базы данных, не заботясь об администрировании.
  • Виртуальные машины Yandex Compute Cloud позволяют вам создавать и настраивать собственные базы данных. Такой подход позволяет использовать любые СУБД, подключаться к базам данных по SSH и так далее.

Что такое хост базы данных и кластер базы данных?

Хост БД — это изолированная среда базы данных в облачной инфраструктуре с выделенными вычислительными ресурсами и зарезервированным объемом хранилища данных.

Кластер БД — это один или более хостов БД, между которыми можно настроить репликацию.

Как начать работу с Managed Service for PostgreSQL?

Managed Service for PostgreSQL доступен всем зарегистрированным пользователям Yandex Cloud.

Чтобы создать кластер базы данных в Managed Service for PostgreSQL, необходимо определиться с его характеристиками:

  • Класс хостов (характеристики производительности — процессоры, память и т. п.).
  • Объем хранилища (резервируется в полном объеме при создании кластера).
  • Сеть, к которой будет подключен ваш кластер.
  • Количество хостов для кластера и зона доступности для каждого хоста вы можете выбрать зону доступности.

Подробные инструкции см. в разделе Как начать работать с Managed Service for PostgreSQL.

Сколько хостов БД может содержать кластер?

Минимальное количество хостов зависит от типа используемого хранилища:

  • Минимум три хоста — для следующих дисков:

    • локальные SSD-диски (local-ssd);
    • нереплицируемые SSD-диски (network-ssd-nonreplicated).

  • Минимум один хост — для следующих дисков:

    • сетевые HDD-диски (network-hdd);
    • сетевые SSD-диски (network-ssd);
    • сверхбыстрые сетевые SSD-диски с тремя репликами (network-ssd-io-m3).

Максимальное количество хостов в кластере ограничено установленными лимитами.

Подробнее см. в разделе Квоты и лимиты в Managed Service for PostgreSQL.

Как получить доступ к запущенному хосту базы данных?

Вы можете подключаться к базам данных Managed Service for PostgreSQL способами, стандартными для СУБД.

Подробнее о подключении к кластерам.

Сколько кластеров можно создать в рамках одного облака?

Технические и организационные ограничения MDB приведены в разделе Квоты и лимиты в Managed Service for PostgreSQL.

Как происходит обслуживание кластеров БД?

Под обслуживанием в Managed Service for PostgreSQL понимается:

  • автоматическая установка обновлений и исправлений СУБД для хостов БД (в т. ч. для выключенных кластеров);
  • изменение класса хостов и объема хранилища;
  • другие сервисные работы Managed Service for PostgreSQL.

Подробнее в разделе Техническое обслуживание в Managed Service for PostgreSQL.

Какую версию PostgreSQL использует Managed Service for PostgreSQL?

Managed Service for PostgreSQL поддерживает PostgreSQL 13, 14, 15, 16 и 17, а также PostgreSQL 13, 14, 15 и 16 для 1C.

Что происходит, когда выпускается новая версия СУБД?

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

Что происходит, когда версия СУБД становится неподдерживаемой (deprecated)?

Через месяц после того, как версия СУБД становится неподдерживаемой, Managed Service for PostgreSQL автоматически оповещает владельцев кластеров БД, созданных с этой версией, по электронной почте.

Создание новых хостов с СУБД неподдерживаемых версий становится невозможным. Через 7 дней после оповещения для минорных версий и через 1 месяц для мажорных версий проводится автоматическое обновление кластеров БД до следующей поддерживаемой версии. Обновление неподдерживаемых мажорных версий происходит даже если у вас отключено автоматическое обновление.

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

В Managed Service for PostgreSQL стоимость потребления рассчитывается исходя из следующих параметров:

  • Выбранный класс хостов.
  • Объем хранилища, зарезервированного для хоста БД.
  • Объем резервных копий кластера БД. Объем резервных копий, равный объему хранилища, не тарифицируется. Хранение резервных копий сверх этого объема оплачивается по тарифам.
  • Количество часов работы хоста БД. Неполные часы округляются до целого значения. Стоимость часа работы для каждого класса хостов приведена в разделе Правила тарификации для Managed Service for PostgreSQL.

Как изменить вычислительные ресурсы и объем хранилища для кластера БД?

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

Характеристики кластера изменяются в течение 30 минут. В этот период также могут быть включены другие сервисные работы по кластеру, например, установка обновлений.

Можно ли настроить автоматическое увеличение размера хранилища кластера?

Да, автоматическое увеличение размера хранилища можно настроить при создании или изменении кластера.

Включено ли резервное копирование хостов БД по умолчанию?

Да, по умолчанию резервное копирование включено. Для PostgreSQL выполняется полное резервное копирование один раз в сутки, и сохраняются все журналы транзакций кластера БД. Это позволяет восстановить состояние кластера на любой момент времени в пределах периода хранения резервных копий, за исключением последних 30 секунд.

По умолчанию резервные копии хранятся 7 дней.

Когда выполняется резервное копирование? Доступен ли кластер БД во время резервного копирования?

Окно резервного копирования — это интервал времени, в течение которого выполняется ежедневное полное резервное копирование кластера БД. Окно резервного копирования — 01:00−05:00 по московскому времени.

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

Шифруется ли соединение с кластером БД PostgreSQL?

Соединение между кластером БД и приложением всегда шифруется с использованием SSL. Отключить шифрование соединений с кластером нельзя.

Что такое реплика для чтения в PostgreSQL?

Реплика для чтения — это доступный только для чтения хост в кластере БД PostgreSQL, данные на котором синхронизируются с хостом-мастером (применимо только если в кластере работает более 1 хоста). Вы можете использовать реплику для чтения для снижения нагрузки на мастер в базах данных с большим объемом запросов на чтение.

За какими метриками и процессами можно следить с помощью мониторинга?

Для всех типов СУБД можно отслеживать:

  • загрузку процессора, памяти, сети, дисков в абсолютных величинах;
  • объем данных кластера БД и остаток свободного места в хранилище данных.

Для всех хостов БД можно отслеживать метрики, специфические для типа соответствующей СУБД. Например для PostgreSQL можно отслеживать:

  • среднее время выполнения запроса;
  • количество запросов в секунду;
  • количество ошибок в журналах и т. д.

Мониторинг можно осуществлять с минимальной гранулярностью в 5 секунд.

Я могу получить логи моей работы в сервисах?

Да, вы можете запросить информацию о работе с вашими ресурсами из логов сервисов Yandex Cloud. Для этого обратитесь в техническую поддержку.

Какие ограничения накладываются на кластеры БД PostgreSQL?

Подробнее об ограничениях Managed Service for PostgreSQL см. раздел Квоты и лимиты в Managed Service for PostgreSQL. В разделе Классы хостов PostgreSQL приведены характеристики кластеров, которые можно создать с помощью Managed Service for PostgreSQL.

Какие расширения для PostgreSQL поддерживаются в Managed Service for PostgreSQL?

Список поддерживаемых расширений для PostgreSQL приведен в разделе Управление расширениями.

Могу ли я получить права суперпользователя в PostgreSQL?

Нет, права суперпользователя недоступны пользователям Managed Service for PostgreSQL. Все виды действий с кластером доступны пользователям с ролью mdb_admin.

Могу ли я скопировать данные из таблицы Managed Service for PostgreSQL в локальный файл? А заполнить таблицу данными из локального файла?

Да, вы можете как скопировать данные из таблицы в локальный файл, так и заполнить таблицу данными из локального файла. Подробнее см. в разделе Копирование и заполнение таблицы с локальной машины.

Есть ли какие-то особенности или ограничения работы сборщика мусора в кластере Managed Service for PostgreSQL?

В кластере Managed Service for PostgreSQL поддерживаются все параметры команды VACUUM, но при их использовании учитывайте, что:

  • Для выполнения полной очистки (VACUUM FULL) пользователю должна быть назначена роль mdb_admin. Полная очистка не затронет служебные таблицы.
  • В PostgreSQL версии 14 расширена функциональность параметра INDEX_CLEANUP: теперь по умолчанию он имеет значение AUTO. Это означает, что команда VACUUM пропускает очистку индекса, если считает ее нецелесообразной. Если вы хотите обеспечить обратную совместимость с предыдущими версиями PostgreSQL, установите параметр INDEX_CLEANUP в значение ON.

Почему кластер работает медленно, хотя вычислительные ресурсы использованы не до предела?

Вероятно, максимальные значения IOPS и пропускной способности (bandwidth) хранилища недостаточны для обработки текущего количества запросов. В этом случае срабатывает троттлинг и быстродействие всего кластера падает.

Максимальные IOPS и bandwidth прирастают на фиксированную величину при увеличении размера хранилища на определенный шаг. Шаг и прирост зависят от типа дисков:

Тип дисков Шаг, ГБ Прирост макс. IOPS (чтение/запись) Прирост макс. bandwidth (чтение/запись), МБ/с
network-hdd 256 300/300 30/30
network-ssd 32 1000/1000 15/15
network-ssd-nonreplicated, network-ssd-io-m3 93 28000/5600 110/82

Чтобы увеличить максимальные значения IOPS и bandwidth и снизить вероятность троттлинга, расширьте размер хранилища при изменении кластера.

Если вы используете хранилище с типом диска network-hdd, рассмотрите возможность перехода на network-ssd или network-ssd-nonreplicated путем восстановления кластера из резервной копии.

Подключение

Возможен ли доступ к кластеру изнутри Yandex Cloud?

К хостам кластера Managed Service for PostgreSQL можно подключиться:

  • Через интернет, если вы настроили публичный доступ для нужного хоста. К таким хостам подключиться можно только используя SSL-соединение.
  • С виртуальных машин Yandex Cloud, расположенных в той же облачной сети. Если к хосту нет публичного доступа, для подключения с таких виртуальных машин необязательно использовать SSL-соединение.
  • Из контейнера в сервисе Yandex Serverless Containers. Если к хосту нет публичного доступа, контейнер должен располагаться в той же облачной сети.

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

Можно ли подключиться к кластеру из Docker-контейнера?

Да, для этого настройте Dockerfile.

Пример подключения из контейнера в сервисе Yandex Serverless Containers см. в практическом руководстве.

Как получить SSL-сертификат для подключения к Managed Service for PostgreSQL на Windows?

SSL-сертификат можно получить с помощью PowerShell:

mkdir $HOME\.postgresql; curl.exe --output $HOME\.postgresql\root.crt https://storage.yandexcloud.kz/cloud-certs/CA.pem

Сертификат будет сохранен в файле $HOME\.postgresql\root.crt.

Подробнее о получении сертификата и подключении к базе данных см. в документации сервиса.

Как установить SSL-сертификат для подключения Power BI к Managed Service for PostgreSQL через psql?

  1. Установите Windows Subsystem for Linux (WSL) и выполните в терминале команду:

    mkdir /mnt/c/temp && \
curl "https://storage.yandexcloud.kz/cloud-certs/CA.pem" --output /mnt/c/temp/CA.pem && \
openssl pkcs12 -export -out /mnt/c/temp/CA.pfx -nokeys -in /mnt/c/temp/CA.pem

    Сертификат будет доступен по пути C:\temp\CA.pfx.

  2. Разместите полученный сертификат в хранилище сертификатов Windows.

Можно ли подключиться к хостам кластера по SSH?

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

Сколько одновременных подключений к одному хосту доступно в Managed Service for PostgreSQL?

Количество одновременных подключений задается на уровне кластера в настройке Max connections. По умолчанию установлено максимальное значение, которое задается формулой:

200 × <количество_vCPU_на_одном_хосте>

О том, как изменить настройки PostgreSQL на уровне кластера читайте в документации.

Сколько подключений доступно одному пользователю?

По умолчанию кластер резервирует для каждого пользователя 50 подключений к каждому хосту. Вы можете изменить это количество в настройке Conn limit.

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

too many active clients for user (pool_size for user <имя_пользователя> reached <значение_лимита>)

О том, как изменить настройки PostgreSQL на уровне пользователя, читайте в документации.

Почему при попытке подключиться к базе данных из Looker Studio возникает ошибка?

Для подключения из Looker Studio необходимо сгенерировать и указать в настройках подключения файл сертификата клиента и приватный ключ. О том, как это сделать, см. в разделе Подключение из Looker Studio.

Как всегда подключаться к хосту-мастеру?

Чтобы подключиться к текущему хосту-мастеру, используйте особый FQDN. Он имеет вид c-<идентификатор_кластера>.rw.mdb.yandexcloud.kz. При подключении к этому FQDN вы сможете выполнять операции чтения и записи.

Пример команды для подключения к мастеру
psql "host=c-<идентификатор_кластера>.rw.mdb.yandexcloud.kz \
      port=6432 \
      sslmode=verify-full \
      dbname=<имя_БД> \
      user=<имя_пользователя>"

Как всегда подключаться к наименее отстающей от мастера реплике?

Чтобы подключиться к наименее отстающей от мастера реплике, используйте особый FQDN. Он имеет вид c-<идентификатор_кластера>.ro.mdb.yandexcloud.kz. При подключении к этому FQDN вы сможете выполнять только операции чтения.

Пример команды для подключения к реплике
psql "host=c-<идентификатор_кластера>.ro.mdb.yandexcloud.kz \
      port=6432 \
      sslmode=verify-full \
      dbname=<имя_БД> \
      user=<имя_пользователя>"

Если в кластере нет активных реплик, то этот FQDN укажет на текущий хост-мастер.

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

postgres — системная БД. По соображениям безопасности подключаться к системным БД нельзя.

Как получить пароль пользователя postgres?

По соображениям безопасности получить пароль пользователя postgres и подключиться к БД от его имени нельзя.

Изменение кластера

Почему кластер перешел в статус Updating во время внепланового создания резервной копии?

Кластер переходит в статус Updating сразу после запуска процесса создания резервной копии. Отменить операцию невозможно — дождитесь ее завершения.

Время выполнения операции зависит от ряда факторов: объем БД, конфигурация кластера, характер хранимых данных и т. д. Средняя скорость восстановления кластера из резервной копии приблизительно равна 100 Мб/сек.

Можно ли одновременно создавать две базы данных в PostgreSQL?

Одновременное выполнение нескольких операций над кластером невозможно: это архитектурная особенность технологий, используемых Yandex Cloud.

Как изменить количество подключений, доступное пользователю?

Можно. Для этого измените значения соответствующих настроек:

  • Conn limit — максимальное количество подключений к хосту для одного пользователя. По умолчанию равно 50. Не может быть меньше 10.
  • Max connections — максимальное количество подключений, зарезервированных для всех пользователей. По умолчанию равно 200 × <количество_vCPU_на_каждом_хосте>. При этом нужно учитывать, что в это число входит 15 служебных подключений: например, если для кластера задан параметр "max_connections": 100, то вы можете зарезервировать не более 85 подключений на каждый хост кластера для пользователей.

Можно ли изменить класс существующего хоста (standard, memory-optimized, burstable)?

Можно — для этого воспользуйтесь инструкцией в разделе Изменение настроек кластера.

Можно ли изменить тип диска в существующем кластере?

Можно. Для этого восстановите кластер из резервной копии и при задании настроек нового кластера укажите нужный тип диска.

Можно ли управлять кластером с помощью команд SQL?

Существуют ограничения на управление кластером с помощью команд SQL. Подробнее см. в разделе Ограничения для команд SQL.

Можно ли создать базу данных с помощью команд SQL?

Нет, создать базу данных с помощью команд SQL нельзя. В кластере Managed Service for PostgreSQL возможно создание баз данных только с помощью интерфейсов Yandex Cloud.

Как вывести кластер из режима read-only?

Воспользуйтесь инструкциями в разделах Вывод кластера из режима read-only и Вывести кластер из режима read-only вручную.

Настройки параметров кластера

Параметр autovacuum по умолчанию включен для всех таблиц?

Да, AUTOVACUUM включен для всех таблиц по умолчанию.

Процесс автоочистки запускается не по времени, а по достижении значений, заданных в настройках — например, когда доля измененных или удаленных записей в таблице равна значению настройки Autovacuum vacuum scale factor.

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

Какие значения LC_COLLATE и LC_CTYPE по умолчанию выставляются для баз данных?

По умолчанию для создаваемых баз данных выставляются значения LC_CTYPE=C и LC_COLLATE=C. Для базы данных, которую вы создаете вместе с кластером, эти настройки изменить нельзя, но вы можете создать новую базу и указать нужные значения для нее.

Можно ли изменить значения LC_COLLATE и LC_CTYPE?

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

  • создать новую базу данных с нужными настройками;
  • задать локаль сортировки (LC_COLLATE) для элементов уже созданной базы данных:
    • при вызове функции: 
      SELECT lower(t1 COLLATE "ru_RU.utf8") FROM test;
    • при создании и изменении таблицы: 
      CREATE TABLE test (t1 text COLLATE "ru_RU.utf8");

Можно ли сменить владельца БД?

После создания БД изменить ее владельца невозможно. Если создать БД через Terraform и затем поменять ее владельца в параметре owner, это приведет к пересозданию БД и потере данных.

Перемещение и восстановление кластера

Можно ли восстановить резервную копию кластера в работающий экземпляр Managed Service for PostgreSQL в другой облачной сети?

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

Можно ли изменить срок хранения автоматических резервных копий?

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

Нужен ли плагин wal2json, если выполняется только реплицирование, но не копирование данных?

Да, плагин обязателен, даже если вы не выполняете копирование данных.

Можно ли локально выгрузить резервную копию базы данных?

Локально выгрузить резервную копию из Yandex Cloud средствами сервиса нельзя, но вы можете воспользоваться утилитой pg_dump.

Как перенести локальный дамп базы данных PostgreSQL в Yandex Cloud?

Воспользуйтесь инструкцией в разделе Миграция базы данных.

Как перенести БД или таблицу из одного кластера в другой?

Перенести БД или таблицу можно с помощью сервиса Data Transfer или утилиты pg_dump.

Подробнее о миграции с помощью Data Transfer см. в руководстве Миграция базы данных.

Как перенести данные между кластерами в разных каталогах или облаках?

Перенести данные можно с помощью сервиса Data Transfer или утилиты pg_dump.

Подробнее о миграции с помощью Data Transfer см. в руководстве Миграция базы данных.

Как перенести кластер в другое облако?

Перенести кластер можно с помощью сервиса Data Transfer или утилиты pg_dump.

Подробнее о миграции с помощью Data Transfer см. в руководстве Миграция базы данных.

Как восстановить резервную копию в существующий кластер?

Резервную копию можно развернуть только в новый кластер.

Как восстановить кластер до состояния выбранной резервной копии?

Резервную копию можно развернуть только в новый кластер.

Можно ли восстановить из резервной копии одну базу данных?

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

Пользователи и роли

Можно ли перенести пользователей из кластера-источника PostgreSQL в кластер-приемник Managed Service for PostgreSQL?

Нет, пользователей нельзя автоматически перенести из стороннего кластера PostgreSQL или кластера Managed Service for PostgreSQL в кластер Managed Service for PostgreSQL. В кластере-приемнике нужно создать пользователей заново.

Как создать роль с помощью SQL-запросов?

С помощью SQL-запросов создать роль нельзя.

В PostgreSQL роль — это пользователь или группа пользователей БД. Создать пользователя в Managed Service for PostgreSQL можно только с помощью консоли управления, Yandex Cloud CLI, Terraform или API. Подробнее о создании пользователей см. в документации PostgreSQL.

Вы можете назначить пользователю привилегии, которые определяют доступные для него действия с объектами БД.

Высокая доступность и балансировка

Как исключить хост из выбора мастером?

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

Важно

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

Почему при настройке каскадной репликации возникает ошибка?

Текст ошибки:

cluster should have at least 2 HA hosts to use cascade host

Ошибка возникает, если вы указываете источник репликации для единственной некаскадной реплики.

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

Подробнее о репликации см. в соответствующем разделе.

Как всегда подключаться к хосту-мастеру?

Чтобы подключиться к текущему хосту-мастеру, используйте особый FQDN. Он имеет вид c-<идентификатор_кластера>.rw.mdb.yandexcloud.kz. При подключении к этому FQDN вы сможете выполнять операции чтения и записи.

Пример команды для подключения к мастеру
psql "host=c-<идентификатор_кластера>.rw.mdb.yandexcloud.kz \
      port=6432 \
      sslmode=verify-full \
      dbname=<имя_БД> \
      user=<имя_пользователя>"

Как всегда подключаться к наименее отстающей от мастера реплике?

Чтобы подключиться к наименее отстающей от мастера реплике, используйте особый FQDN. Он имеет вид c-<идентификатор_кластера>.ro.mdb.yandexcloud.kz. При подключении к этому FQDN вы сможете выполнять только операции чтения.

Пример команды для подключения к реплике
psql "host=c-<идентификатор_кластера>.ro.mdb.yandexcloud.kz \
      port=6432 \
      sslmode=verify-full \
      dbname=<имя_БД> \
      user=<имя_пользователя>"

Если в кластере нет активных реплик, то этот FQDN укажет на текущий хост-мастер.

Почему мастер и реплики поменялись местами?

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

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

Важно

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

Можно ли настроить мультимастер в кластере или между двумя кластерами?

Нет, в сервисе Managed Service for PostgreSQL не поддерживается настройка мультимастера.

Подробнее об обеспечении высокой доступности кластера см. в разделе Высокая доступность управляемых баз данных (MDB).

Как настроить балансировку, чтобы запросы на чтение отправлялись только на реплики?

Балансировка не осуществляется на стороне Managed Service for PostgreSQL, поэтому ее необходимо реализовать в бэкенде вашего приложения. Чтобы отправлять запросы на чтение репликам, приложение должно определить самостоятельно, какой из хостов является репликой, а какой — мастером. Например, это можно сделать с помощью библиотеки libpq. Подробнее см. в документации PostgreSQL.

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

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

Почему мастер переключается на случайно выбранный хост при отключенной опции автоматического переключения мастера?

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

Примечание

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

Почему при восстановлении работоспособности кластера происходит смена мастера, несмотря на отключенную опцию автоматического переключения мастера?

Хост-мастер может переключиться на другой хост при восстановлении работоспособности даже при запрете на автоматическое переключение. Это сделано для обеспечения правильной работы кластера в указанных условиях. Подробнее читайте в разделе Высокая доступность кластера Managed Service for PostgreSQL.

Почему во время операций обслуживания происходит автоматическое переключение мастера, хотя эта опция выключена?

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

Мониторинг и логи

Где я могу отслеживать использование дискового пространства, чтобы не превысить лимит в 95% для перехода в read-only?

Отслеживать использование дискового пространства можно:

Логи хранятся на том же диске, что и данные PostgreSQL? Как они тарифицируются?

Логи хранятся отдельно от диска с данными и ротируются автоматически. Посмотреть информацию о логах можно командой CLI:

yc managed-postgresql cluster list-logs <идентификатор_кластера>

Использование хранилища с логами кластера не тарифицируется.

Как долго хранятся логи?

Логи кластера хранятся 30 дней.

Что такое WAL и для чего они нужны?

Журналы Write-Ahead Log нужны для записи данных на диск и их репликации. Они создаются при запросах на запись и занимают место на диске до момента полной записи информации с журналов на диски хостов — это обеспечивает отказоустойчивость и надежность СУБД.

Подробнее о принципах работы PostgreSQL см. в официальной документации.

Что означает параметр Cached в мониторинге RAM хоста кластера PostgreSQL?

В Cached помещаются кешированные данные. Большинство операций выполняется на уровне оперативной памяти, так как вся информация базы данных хранится именно там. Кеширование происходит не только для баз данных, но и для диска — из-за этого объём кешированных данных может превышать размер хранилища.

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

Подробнее о кешировании данных дисков в Linux см. в документации.

Как получать алерты о критических показателях кластера PostgreSQL?

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

Как настроить алерт, который срабатывает при заполнении определенного процента дискового пространства?

Создайте алерт с метрикой disk.used_bytes в сервисе Yandex Monitoring. Метрика показывает размер использованного дискового пространства в кластере Managed Service for PostgreSQL.

Для disk.used_bytes используются пороги для оповещения. Их рекомендуемые значения:

  • Alarm — 90% дискового пространства.
  • Warning — 80% дискового пространства.

Значения порогов задаются только в байтах. Например, рекомендуемые значения для диска размером в 100 ГБ:

  • Alarm — 96636764160 байт (90%).
  • Warning — 85899345920 байт (80%).

Сообщения об ошибках

Почему при использовании расширения TimescaleDB возникает ошибка?

Текст ошибки:

SQL Error [0A000]: ERROR: functionality not supported under the current "apache" license
Hint: Upgrade your license to 'timescale' to use this free community feature.

Эта ошибка возникает при попытке использовать функцию, доступную только в TimescaleDB Community Edition.

Community Edition распространяется по лицензии Timescale License (TSL). Пункт 2.2 лицензии запрещает использовать Community Edition для предоставления услуг DBaaS (Database as a Service), поэтому эта версия недоступна в Yandex Cloud.

В кластер Managed Service for PostgreSQL устанавливается TimescaleDB Apache 2 Edition — по сравнению с Community Edition ее функциональность ограничена.

Что делать, если при получении SSL-сертификата через PowerShell возникает ошибка проверки отзыва?

Полный текст ошибки:

curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x80092012)
The revocation function was unable to check revocation for the certificate

Это означает, что при подключении к сайту не удалось проверить, есть ли его сертификат в списке отозванных.

Чтобы исправить ошибку:

  • убедитесь, что проверку не блокируют настройки корпоративной сети;

  • выполните команду с параметром --ssl-no-revoke.

    mkdir $HOME\.postgresql; curl.exe --ssl-no-revoke -o $HOME\.postgresql\root.crt https://storage.yandexcloud.kz/cloud-certs/CA.pem

Что делать, если при подключении я получаю ошибку SSL is required?

Ошибка означает, что вы пытаетесь подключиться к кластеру с хостом в публичном доступе. Такие хосты поддерживают только соединения с SSL-сертификатом. Вы можете:

Что делать, если при подключении я получаю ошибку too many active clients for user?

Подключение к хостам кластера может завершиться ошибкой:

too many active clients for user (pool_size for user <имя_пользователя> reached <значение_лимита>)

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

Решение: увеличьте лимит подключений в настройке Conn limit.

О том, как изменить настройки PostgreSQL на уровне пользователя, читайте в документации.

Почему при подключении к пользовательской базе данных возникает ошибка?

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

ERROR: odyssey: ce3ea075f4ffa: route for '<имя_БД>.<имя_пользователя>' is not found

Ошибка означает, что в параметрах подключения указано неверное имя базы данных.

Почему при создании дампа с помощью pg_dumpall возникает ошибка?

При создании дампа с помощью утилиты pg_dumpall возникает ошибка:

ERROR: odyssey: c16b9035a1f78: route for 'template1.<имя_пользователя>' is not found

Ошибка возникает из-за того, что утилита pg_dumpall пытается выгрузить все базы данных: как пользовательские, так и системные.

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

Почему при подключении к базе данных postgres возникает ошибка?

Подключение к базе данных postgres завершается ошибкой:

ERROR: odyssey: c76e2c1283a7a: route for 'postgres.<имя_пользователя>' is not found

База данных postgres является системной, и подключение к ней в Managed Service for PostgreSQL запрещено. Укажите в параметрах подключения другую существующую базу данных.

Почему соединение завершается ошибкой terminating connection due to administrator command?

Соединение с кластером Managed Service for PostgreSQL может завершаться сообщением:

FATAL: terminating connection due to administrator command

Такое сообщение не является ошибкой, а означает, что длительность сессии/транзакции превысила значение настройки Session duration timeout (по умолчанию — 12 часов).

Почему не удается подключиться к хостам кластера?

Подключение к хостам кластера может завершиться ошибкой:

could not translate host name "<обычный или специальный FQDN>" to address: Name or service not known

Ошибка возникает, если запрещен публичный доступ к хосту или пользователи используют кастомизированные DNS-серверы, которые не разрешают доменные имена в зоне mdb.yandexcloud.net.

Решение:

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

    Важно

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

  • Рекомендуется включить публичный доступ для всех хостов кластера. Это позволит избежать ошибок подключения при автоматической смене хоста-мастера.

  • Для кастомизированных DNS-серверов настройте DNS-перенаправление для зоны mdb.yandexcloud.net.

Почему я не могу остановить кластер?

Текст ошибки:

ERROR: rpc error: code = FailedPrecondition desc = Cluster has no backups

Остановить кластер, у которого нет резервных копий, невозможно. Чтобы устранить ошибку и остановить кластер, создайте резервную копию.

Почему при изменении кластера возникает ошибка max_connections is less than sum of users connection limit?

Эта ошибка может возникнуть при уменьшении класса хоста в кластере, если сумма лимитов подключений всех пользователей меньше общего лимита подключений на кластер (Max connections).

Решение: сначала уменьшите лимиты, установленные для пользователей, чтобы их сумма была меньше, чем <значение_Max_connections> — 15, а затем снижайте класс хоста.

Почему перенос данных через создание и восстановление логического дампа завершается ошибкой?

Восстановление логического дампа может завершаться одной из ошибок:

  • ERROR: role "<имя_пользователя_источника>" does not exist
  • ERROR: must be member of role "<имя_пользователя_источника>"

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

Чтобы устранить ошибки:

  1. Добавьте пользователя в кластере-приемнике с доступом к базе данных для переноса и таким же именем, что и у пользователя, с помощью которого был создан логический дамп в кластере-источнике.
  2. Восстанавливайте логический дамп с помощью этого пользователя или выдайте его привилегии пользователю, с помощью которого вы восстанавливаете логический дамп.

Что делать, если при выполнении логической репликации возникает ошибка replication slot already exists?

По умолчанию при создании подписки создается и слот репликации. Ошибка replication slot already exists означает, что слот репликации уже существует.

Устранить ошибку можно одним из способов:

  1. Привяжите подписку к существующему слоту репликации. Для этого добавьте в запрос для создания подписки параметр create_slot = false.
  2. Удалите существующий слот репликации и попробуйте создать подписку еще раз.

Почему при миграции БД в Managed Service for PostgreSQL возникает ошибка extension... is not available?

Текст ошибки:

extension "<название_расширения>" is not available

Ошибка может возникнуть при миграции БД в Managed Service for PostgreSQL с помощью скрипта, который пытается установить и использовать расширение PostgreSQL. Причина ошибки в том, что в кластерах Managed Service for PostgreSQL нельзя управлять расширениями PostgreSQL с помощью команд SQL.

Чтобы избежать ошибки:

  1. Если скрипт или логический дамп имеют текстовый формат, удалите из них операторы для создания расширений PostgreSQL.
  2. Установите все необходимые расширения в базе-приемнике с помощью интерфейсов Yandex Cloud.

Почему при развертывании логического дампа возникает ошибка must be owner of extension?

Восстановление логического дампа может завершаться ошибкой ERROR: must be owner of extension.

Ошибка вызвана тем, что в логическом дампе присутствуют операции установки или обновления расширений PostgreSQL. В кластерах Managed Service for PostgreSQL нельзя управлять расширениями с помощью команд SQL.

Чтобы устранить ошибку:

  1. Перед восстановлением дампа включите в базе-приемнике все необходимые расширения.
  2. Исключите из дампа любые операции с расширениями. Например, можно закомментировать строки, связанные с установкой расширений.
  3. Выполните восстановление логического дампа повторно.

Почему при настройке каскадной репликации возникает ошибка?

Текст ошибки:

cluster should have at least 2 HA hosts to use cascade host

Ошибка возникает, если вы указываете источник репликации для единственной некаскадной реплики.

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

Подробнее о репликации см. в соответствующем разделе.

Почему возникает ошибка cannot execute <SQL-команда> in a read-only transaction?

Варианты ошибок:

ERROR: cannot execute ALTER EXTENSION in a read-only transaction

ERROR: cannot execute CREATE TABLE in a read-only transaction

ERROR: cannot execute UPDATE in a read-only transaction

ERROR: cannot execute INSERT in a read-only transaction

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

Избежать таких ошибок можно любым из способов:

  • Подключитесь к кластеру с помощью особого FQDN, который всегда указывает на текущий мастер.

    Важно

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

  • При подключении укажите параметр target_session_attrs=read-write и перечислите все хосты кластера. Так вы подключитесь к хосту-мастеру с возможностью чтения и записи.

Подробнее о способах подключения к хосту-мастеру см. в разделе Подключение к базе данных.

Что делать, если в логах отображается ошибка too many connections for role "monitor"?

Пользователь monitor зарезервирован для нужд мониторинга в кластере Managed Service for PostgreSQL. Сообщения об исчерпании лимита подключений для этого пользователя можно игнорировать.

Почему установка нескольких расширений в CLI заканчивается ошибкой?

Установка нескольких расширений в CLI может завершиться одной из ошибок:

  • ERROR: accepts 1 arg(s), received 2

    Ошибка может возникать из-за неправильного формата команды.

    Решение: проверьте, что все расширения перечислены без пробела, например:

    yc managed-postgresql database update db1 --cluster-id cat0adul1fj0******** --extensions cube,pg_logic,timescaledb

  • ERROR: rpc error: code = InvalidArgument desc = Invalid extensions '<имя_расширения>', allowed extension: <список_расширений>

    Ошибка может возникать при несовместимости одного из расширений в списке с версией PostgreSQL в кластере.

    Решение: проверьте совместимость указанных в команде расширений в списке поддерживаемых расширений.

  • ERROR: rpc error: code = InvalidArgument desc = The specified extension '<имя_расширения>' is not present in shared_preload_libraries

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

    Решение: проверьте требования к библиотекам общего пользования в списке поддерживаемых расширений. Чтобы подключить нужную библиотеку, при изменении настроек кластера PostgreSQL укажите ее имя в параметре Shared preload libraries.

Предыдущая
Сообщения об ошибках
Следующая
Обучающие курсы