Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Истории успеха
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Доступны в регионе
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • AI Studio
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Партнёрская программа
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Истории успеха
  • Документация
  • Блог
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»
Все решения
    • Все решения для Managed Service for PostgreSQL
    • Восстановление работоспособности кластера Managed Service for PostgreSQL после исчерпания свободного места в хранилище данных
    • Не удается удалить кластер Managed Service for PostgreSQL в состоянии `DEAD`, если на нем включена защита от удаления
    • Кластер Managed Service for PostgreSQL переходит в статус `UNKNOWN` сразу после создания
    • Устранение проблем изменения конфигурации кластеров с дисками `local-ssd`
    • Устранение последствий переполнения хранилища кластера WAL-журналами
    • Устранение ошибки `psql error could not translate host name to address nodename nor servname provided, or not known`
    • Устранение ошибки `Unrecognized configuration parameter stats_temp_directory`
    • Устранение ошибки `max_connections сonn_limit is too high`
    • Устранение ошибки `422 UNPROCESSABLE ENTITY The specified extension <'ext_name'> is not present in shared_preload_libraries`
    • Как работает параметр `Conn limit`
    • Как настроить фильтрацию SQL-запросов
    • Как включить логирование SQL-запросов

В этой статье:

  • Описание проблемы
  • Решение
  1. Managed Service for PostgreSQL
  2. Устранение последствий переполнения хранилища кластера WAL-журналами

Устранение последствий переполнения хранилища кластера WAL-журналами

Статья создана
Yandex Cloud
Обновлена 16 августа 2024 г.
  • Описание проблемы
  • Решение

Описание проблемыОписание проблемы

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

  • В результате трансфера Data Transfer произошло переполнение хранилища данных базы;
  • Превышено количество слотов репликации для кластера;
  • Запись новых данных в таблицы в баз данных кластера не производится.

РешениеРешение

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

Каждый выполняющийся трансфер создает слот репликации в базе данных. Слот репликации – это указатель на позицию в WAL-журнале, если слот не используется, то позиция в журнале не изменяется.

Если данные из этого слота не читались по какой-то причине, размер WAL-журнала продолжает увеличиваться до тех пор, пока не закончится свободное место в хранилище кластера или пока не будет превышено значение параметра Max slot wal keep size

Узнать, какие слоты репликации открыты в базе можно, подключившись к одной из баз кластера с помощью psql и выполнив запрос SELECT * FROM pg_replication_slots WHERE slot_type = 'logical';.

Пример вывода команды SELECT * FROM pg_replication_slots WHERE slot_type = 'logical';
```sql
SELECT * FROM pg_replication_slots WHERE slot_type = 'logical';
-[ RECORD 1 ]-------+---------------------
slot_name           | dttXXXXXXXXXXXXXXXXX
plugin              | wal2json
slot_type           | logical
```
  • Если для поля plugin в слоте логической репликации указано значение wal2json, это означает, что с базами данных этого кластера в настоящий момент работает Data Transfer;

  • Если процессе работы трансфера для одного или нескольких слотов репликации ошибка, удалите его командой SELECT pg_drop_replication_slot('$REPLICATION_SLOT_NAME');, где $REPLICATION_SLOT_NAME – наименование залипшего порта репликации. Для примера выше это dttXXXXXXXXXXXXXXXXX;

  • Если в результате удаления слота репликации возникает ошибка replication slot "$REPLICATION_SLOT_NAME" is active for PID $PID_NUM, остановите выполнение трансфера на стороне Data Transfer или удалите из параметров трансфера задействованный эндпоинт.

Пример вывода команды select pg_drop_replication_slot('$REPLICATION_SLOT_NAME');
db-NAME=> SELECT pg_drop_replication_slot('$REPLICATION_SLOT_NAME');
ERROR: replication slot "$REPLICATION_SLOT_NAME" IS active FOR PID 12345

Также вы можете указать максимальный размер WAL-лога, после которого работа Data Transfer будет остановлена. Для этого измените значение параметра Max slot wal keep size. Если размер WAL-журнала для вашей базы превысит размер, указанный в этом параметре, трансфер остановится. Это предотвратит заполнение всего свободного места в хранилище кластера.

После ошибки или успешного завершения трансфера WAL-журнал удаляется и пространство в хранилище высвобождается. В случае если трансфер не завершается успешно после изменения значения параметра Max slot wal keep size, увеличьте размер хранилища кластера по этой инструкции.

Больше о работе слотов репликации вы можете узнать из документации от разработчиков PostgreSQL.

Была ли статья полезна?

Предыдущая
Устранение проблем изменения конфигурации кластеров с дисками `local-ssd`
Следующая
Устранение ошибки `psql error could not translate host name to address nodename nor servname provided, or not known`
Проект Яндекса
© 2025 ТОО «Облачные Сервисы Казахстан»