База данных — бизнес-критический компонент любой ИТ-инфраструктуры, поэтому вопрос обеспечения ее доступности и отказоустойчивости обычно находится в центре внимания. Однако, фокусируясь на отказоустойчивости, компании нередко недооценивают риск переполнения диска. При этом подобные ситуации могут оставаться незамеченными до полной остановки записи БД, например при заполнении отдельного раздела, где хранятся данные или WAL.

Привет, Хабр. Меня зовут Александр Шмелёв. Я Team Lead команды разработки Databases, VK Tech. В этой статье я расскажу о рисках и причинах переполнения дисков, а также рассмотрю несколько способов предотвращения подобных проблем.

Возможные последствия отказа БД

Простой базы данных (если он не вызван плановой технической паузой) несет риск прямых финансовых убытков для компании. Так, по данным исследований 2025 года, средняя продолжительность одного ИТ-сбоя в российских компаниях составляет около четырех часов, при этом финансовые потери от подобных инцидентов достигают примерно двух миллионов рублей.

Масштаб ущерба зависит от размера бизнеса: если команда из десяти разработчиков теряет четыре рабочих часа, прямые издержки составляют около 100 тысяч рублей только на фонде оплаты труда. Для крупного ритейлера или банка с оборотом в сотни миллионов рублей каждая минута остановки продаж или платежных шлюзов обходится в сотни раз дороже.

Однако реальные потери зачастую в несколько раз превышают и эти цифры — так, к прямым убыткам добавляются:

• репутационные риски;

• штрафы за нарушение SLA перед партнерами;

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

Падает и долгосрочное доверие аудитории, что крайне сложно оценить в моменте.

При этом частой причиной, почему БД перестает принимать данные на запись, как правило, является переполнение диска — ситуация, когда на томе, где хранятся данные, логи транзакций или временные файлы, заканчивается место.

Причины переполнения диска

Причин переполнения диска может быть много. Разберем основные:

• Резкий рост нагрузки (акции, сезонные пики, релизы). Внезапный наплыв пользователей во время маркетинговых акций, сезонных распродаж или запуска новых продуктов способен увеличить объем транзакций в несколько раз. Даже если инфраструктура была рассчитана на средние показатели, пиковые значения могут привести к быстрому заполнению диска, особенно если система не была заранее подготовлена к такому сценарию.

• Массовые операции записи (миграции, пересчеты, bulk insert/update). Длительные транзакции, такие как массовая загрузка данных, сложные миграции или пересчет индексов, создают огромную нагрузку на дисковую подсистему. Пока подобная операция не завершится, база данных удерживает значительные объемы ресурсов, что может привести к исчерпанию свободного места даже при наличии запаса емкости.

• Отсутствие контроля роста данных и логов. Часто проблема возникает из-за отсутствия регулярного контроля за темпами роста данных и служебных файлов. Без настроенного мониторинга объема таблиц, временных файлов и логов команда может не заметить приближения критической отметки, пока не станет слишком поздно.

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

Причиной переполнения могут быть и проблемы с упреждающим журналом записи (WAL, Write-Ahead Logging), который применяется в большинстве распространенных СУБД — например, в PostgreSQL. Здесь стоит остановиться подробнее, так как именно механика работы WAL чаще всего становится скрытой причиной внезапных аварий в отказоустойчивых кластерах СУБД.

Немного о нюансах записи WAL-файлов

В большинстве ACID-совместимых систем управления базами данных — например, PostgreSQL — надежность хранения обеспечивается соблюдением требований теоремы ACID. Так, чтобы гарантировать сохранность подтвержденных транзакций даже при внезапном отключении питания, СУБД обязана немедленно записывать изменения на физический носитель.

Однако постоянная случайная запись в основные файлы таблиц (data files) обычно медленная из-за особенностей работы дисковых подсистем. Поэтому все изменения сначала записываются в упреждающий журнал. Сами же файлы базы сбрасываются на физический носитель асинхронно и большими порциями в процессе чекпойнта (checkpoint), после чего отработанные wal-файлы сразу удаляются. 

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

Проблемы с архивацией

Если настроена отправка логов в удаленное хранилище (например, S3) и возникает сетевая ошибка, процесс очистки останавливается. База продолжает работать, но мастер-сервер больше не может удалять отработанные wal-файлы, так как они еще не улетели в архив. Отследить это можно через системное представление pg_stat_archiver: если счетчик failed_count становится больше нуля, значит возникла проблема, которая рано или поздно приведет к отказу.

postgres=# select * from pg_stat_archiver ;
-[ RECORD 1 ]------+------------------------------
archived_count     | 666
last_archived_time | 2023-04-27 15:08:52.841433+00
failed_count       | 12 -- сигнал тревоги

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

Слоты репликации

Еще один сценарий связан с потоковой репликацией. Чтобы гарантировать, что каждая реплика сможет получить нужные данные, используются слоты удержания: мастер-сервер никогда не удалит сегмент журнала, пока тот не будет забран всеми активными потребителями. Но если реплика долго недоступна или отвалился процесс захвата изменений (CDC), мастер продолжит хранить гигабайты ненужных логов со статусом «удерживается» (reserved/extended).

postgres=# select * from pg_replication_slots ;
-[ RECORD 1 ]-------+------------------------------------
slot_name           | replica_1
wal_status          | extended -- сигнал тревоги

В этом случае WAL копится потому, что слот запрещает мастеру удалять файлы, необходимые потенциальной реплике для синхронизации. В результате свободное место исчезает, хотя сама основная база данных работает штатно.

Методы предотвращения переполнения диска: ручное управление или автоматика

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

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

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

• Адекватные алерты. Пороги уведомлений должны быть жесткими. Оставлять 5% от терабайтного тома — это всего лишь 50 Гб свободного места, которые при пиковой нагрузке исчерпаются мгновенно. Для решений в проде безопаснее ориентироваться на порог в 30–50% свободного пространства.

• Понимание профиля нагрузки. Необходимо анализировать типичные операции системы. Если планируется масштабная рекламная кампания или запуск новой отчетности, нужно заранее спрогнозировать кратный рост объема входящих транзакций.

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

• Проверка состояния реплик. Доступность слейвов необходимо мониторить так же строго, как и мастер-сервера. Отставшая или полностью недоступная реплика сама становится источником проблем, удерживая WAL-файлы слотами репликации и мешая их удалению с мастера.

Соответственно, при таком подходе требуется непрерывная вовлеченность команды и глубокая экспертность в нюансах администрирования БД.

Но существует и другой способ, который подразумевает использование управляемых баз данных в облаке (например, таких как Cloud Databases в VK Cloud). В этом сценарии защиту от блокировки БД из-за переполнения дисков можно автоматизировать с помощью встроенных механизмов, таких как:

• автомасштабирование;

• режим read-only. 

Принцип работы автомасштабирования

Автомасштабирование — автоматическое увеличение размера диска при нехватке места, которое происходит без остановки базы данных. Механизм срабатывает превентивно: система постоянно отслеживает объем свободного пространства, и, как только оно опускается ниже определенного порога (threshold > free space), диск автоматически расширяется на заданный шаг.

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

• Для диска с данными: выбирается минимум из значений «2 Гб + размер диска / 25» или «25 Гб». Формула выглядит следующим образом: threshold = min(2 + volume_size / 25, 25).

• Для WAL-диска: выбирается минимум из значений «0,5 Гб + размер диска / 25» или «2 Гб». Формула простая: threshold = min(0.5 + volume_size / 25, 2).

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

Принцип работы режима read-only

Режим «только для чтения» (read-only) выступает последним бастионом защиты. Он включается автоматически, когда свободного места остается критически мало, а другие механизмы уже исчерпаны. 

При его активации в случае достижении порога блокируется выполнение операций записи (insert, update, delete), однако доступ к данным для выполнения запросов на чтение сохраняется. Это позволяет приложениям продолжать работу в ограниченном режиме, не допуская полной остановки сервиса. 

Для включения данного режима порог рассчитывается как минимальное из двух значений. Например, свободно только 5% диска или свободно 4 Гб. В виде формулы это выглядит так 

threshold = min(disk.size * ENABLE_RO_PERCENT, ENABLE_RO_FREE_SPACE)

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

Саммари

С проблемой переполнения дисков может столкнуться практически любой проект — даже при корректной настройке инфраструктуры и наличии запаса памяти, «под капотом» могут идти скрытые процессы, которые приведут к внезапной остановке записи. Поэтому при работе с базами данных необходимо четко соблюдать множество эксплуатационных правил, от настройки мониторинга свободного пространства и алертов на пороговые значения до контроля долгих транзакций и регулярной проверки состояния реплик. То есть требуется постоянный контроль со стороны команды.

Однако существует и другой путь. Так, при работе в облаке проблемы с полным отказом базы данных можно предотвратить встроенными, автоматическими механизмами защиты. Такие, например, доступны и при работе с Cloud Databases в VK Cloud. Причем протестировать облачные БД и их возможности можно на специальных условиях, поскольку VK Cloud предоставляет приветственный бонус в размере до 12 000 ₽ всем новым клиентам облачной платформы.