Postgresql как ограничить общий размер WAL-файлов?

Question

[vlarkanov]

Приветствую! Собственно, сабж. Настраиваю потоковую репликацию по вот этой инструкции eax.me/postgresql-replication

# какие адреса слушать, замените на IP сервера
listen_addresses = '10.0.3.245'

wal_level = hot_standby

# опционально: не дожидаемся fsync на реплике при синхронной репликации
# synchronous_commit = remote_write

# это нужно, чтобы работал pg_rewind
wal_log_hints = on

max_wal_senders = 8
wal_keep_segments = 64

# если хотим синхронную репликацию на одну любую реплику
# synchronous_standby_names = '*'

hot_standby = on

- каким образом ограничить не только количество WAL-сегментов, но максимально занимаемый ими объем?

Answer 1

[Melkij]

Один сегмент WAL обычно имеет фиксированный размер 16мб (опция компиляции postgresql with-wal-segsize, если вы её указывали - вы должны об этом знать, плюс она требует initdb делать заново). Поэтому их количество пересчитывается в объём банальным умножением.

Ограничить максимальный занимаемый объём wal сверху - нельзя. Такой единой гайки нет, даже если вас устраивает переход базы в readonly по достижении этого лимита. И есть довольно много гаек, которые при своём использовании могут попросить базу не вычищать старые wal ещё какое-то время.

Гайки, на которые надо обращать внимание:
wal_keep_segments - база оставляет на диске не меньше этого числа wal, что позволяет реплике штатно на некоторое время терять мастера и затем догонять
replication slots - если вы сделаете слот репликации и его никто не будет читать - база будет сохранять wal пока не закончится диск. Если вы используете слоты репликации, то у вас в мониторинге обязана быть отдельная проверка что слот вычитывается
max_wal_size - несмотря на название - объём wal, по накоплению которого происходит checkpoint. (либо по таймеру checkpoint_timeout смотря что случится раньше). Реально объём wal может быть выше, т.к. автоматический checkpoint намеренно не выполняется моментально, а размазан во времени.
min_wal_size - этот объём wal всегда будет на диске занят и будет переписываться по кругу. Как гарантия того, что на диске есть место под столько wal
archive_command - если включен и команда возвращает ненулевой статус возврата - то будет накапливать wal без ограничений. wal будут удалены (если только ещё не нужны какой из других настроек) когда archive_command получает от команды 0 код возврата.

Если не хочется много денег тратить на резерв свободного места на хороших SSD - разместите на SSD саму базу данных, а WAL перенесите (симлинком директории pg_xlog (до 10.0) или pg_wal (10.0 и выше)) на отдельные HDD. WAL пишутся строго последовательно, вполне возможно жить с WAL на механических дисках и держать хорошую нагрузку.
Плюс если работаете не с деньгами, можно сделать synchronous_commit = off. Что увеличит производительность всех пишущих транзакций. Но в случае фатального краха железа вы потеряете последние 3*wal_writer_delay транзакции (т.е. до 3*200мс = 600мс).

Comments

[vlarkanov]

Спасибо, очень развернутый ответ!

В конкретно моей ситуации есть виртуалка с Postgresql, которая в ближайшее время собирается перенестись на железо. Планирую поступить так: на виртуалке разрешить потоковую репликацию, через pg_basebackup stream затянуть данные на железный сервер. После того как будет проверено, что данные консистентны и доступны - погасить виртуалку. Проблема в том, что на виртуалке свободно около 28Gb (базы весят в сумме около 90Gb) и нужно настроить репликацию так, чтобы свободное место не съелось за ближайшие несколько дней.

[Melkij]

Тогда не трогайте настройки мастера кроме как max_wal_senders (если был выключен) (для basebackup необходимо минимум 2 коннекта). Ну и чуть-чуть wal_keep_segments всё-таки можно поднять.
По-умолчанию мастер не будет дожидаться реплику. Если мастеру хочется удалить wal - он их удалит как ни в чём не бывало. Если реплика этот wal не прочитала ещё - то получит потом отлуп и надо будет pg_basebackup делать заново. (для изменения этого поведения как раз replication slots и появились)

pg_basebackup -X stream открывает два соединения: по одному копирует базу, по второму подписывается на все новые wal как рядовая реплика. Поэтому во время его работы мастер работает как ни в чём не бывало и удаляет wal как обычно. А вот на реплике wal будут копиться. И стартовать реплика может немного не сразу, пока все эти wal проигрывает. Неприятный момент - за новыми wal к мастеру реплика пойдёт только когда разгребёт все локально записанные wal.

В общем, делается в screen pg_basebackup с ключом --progress, когда он доработал - открывается в другой консоли tail -f лога будущей реплики, запускается реплика и ждём ready to accept connections и starting streaming. Если посыпались ошибки wal segment already removed - стопаем реплику, на мастере поднимаем keep segments и пробуем налить реплику ещё раз. (у нас в dataegret обычно изначально keep segments задран)