Debezium приводит к тому, что у Postgres заканчивается место на диске в RDS
У меня есть небольшая база данных разработки Postgres, работающая на Amazon RDS, и я использую K8s. Насколько я могу судить, трафика практически нет. Я хочу включить захват изменений, я включил rds.logical_replication, запустил экземпляр Debezium, и темы появляются в Kafka, и все выглядит нормально.
Через несколько часов свободное место на диске начинает уменьшаться:
Он начал потреблять диск с постоянной скоростью и съел все доступные 20 Гб в течение 24 часов. Остановка Debezium ничего не делает. Способ, которым я вернул свое дисковое пространство, был следующим:
select pg_drop_replication_slot('services_debezium')
и:
vacuum full
Затем, через несколько минут, как видно на графике, место на диске восстанавливается.
Какие-нибудь советы? Я хотел бы увидеть, что на самом деле заполняет пространство, но я не думаю, что смогу. На стороне Debezium вроде ничего не происходит (никаких зловещих журналов), да и журналы Postgres не показывают ничего особенного. Или есть какое-то внешнее событие, которое вызывает это начало?
Насколько я понял, на экземпляре есть «невидимая» база данных AWS, которая делает что-то, разделяет WAL и имеет довольно много активности. Поэтому, если захват изменений не выполняется из-за отсутствия активности в вашей базе данных или по какой-либо другой причине, он довольно быстро займет место на диске. Настройка сердцебиения «heartbeat.interval.ms» помогает, когда ваша база данных очень малоактивна.
Ответы 3
Проблема в слоте репликации. Он помечает позицию в WAL, и PostgreSQL не будет удалять более новые сегменты WAL. Эти файлы находятся в подкаталоге pg_wal каталога данных.
Удаление слота репликации и запуск CHECKPOINT удалит файлы и свободное место. Возможно, вам также придется VACUUM (FULL) столы, которые раздулись, а VACUUM не могли добиться никакого прогресса.
Причиной проблемы должна быть неправильная конфигурация Debrezium: он не использует изменения и не перемещает слот репликации вперед. Решите эту проблему, и вы хорошо.
Да, но нет. Странно то, что Debezium работает нормально: изменения используются, задержка низкая, ошибок нет с обеих сторон. Я бы хотел увидеть, что на самом деле находится в файловой системе, но, ЧТО-ТО, Amazon этого не позволяет. А прямолинейность линии, кажется, указывает на то, что она не связана с движением. Единственная "подозрительная" вещь, которую я вижу в логах: "Параметру max_wal_senders было присвоено значение, несовместимое с репликацией. Оно было скорректировано с 10 до 15".
Вы не обязаны мне верить :^)
Хорошо, я думаю, что понял это. В Amazon RDS есть еще одна «скрытая» база данных, в которой есть изменения, но изменения, которые я не вносил и которые я вижу, поэтому Debezium также не может их подобрать. Если изменить мою отслеживаемую базу данных, она покажет это изменение и в процессе сбросит буфер и освободит это пространство. Так что само отсутствие изменений было причиной его заполнения. Не знаю, есть ли для этого красивое решение, но, по крайней мере, я могу с этим работать.
Вам необходимо периодически генерировать некоторые движения в вашей базе данных (например, выполнять обновление любой записи).
Debezium предоставляет функцию под названием Heartbeat для выполнения операций такого типа.
Сердцебиение можно настроить в коннекторе следующим образом:
"сердцебиение.интервал.мс": "300000", "heartbeat.action.query": "обновить my_table SET date_column = now();"
Вы можете найти больше информации в официальной документации:
https://debezium.io/documentation/reference/connectors/postgresql.html#postgresql-wal-disk-space
Обратите внимание, что достаточно просто иметь интервал сердцебиения. Запрос действия пульса используется только в том случае, «когда захват изменений из базы данных с низким трафиком на том же хосте, что и база данных с высоким трафиком, не позволяет Debezium обрабатывать записи WAL». Из документации: debezium.io/documentation/reference/connectors/…
Вы наконец нашли причину/обходной путь?