есть реплика.
PG10
На на мастере запустили довольно тяжелый запрос
который заполняет таблицу данными из других таблиц
размер таблицы около 2GB после заполнения.
Во время заполнения через некоторое время отвалилась реплика.
Предположил что реплике не хватило количества wal файлов
как я понял за это отвечает параметр конфигурации
wal_keep_segments
и сейчас он выставлен в 128
и всё работало отлично
видимо первый раз такая большая таблица попалась
вопрос - правильно ли я копаю?
и как правильно рассчитывать этот параметр?
и какие побочки могут быть если его увеличить?
у вас WAL файлы быстро “ротируются”. предположим, что все 2Gb попали в WAL (это 128 сегментов). чекпойнты из коробки срабатывают при записи 1GB (64 сегмента), значит у вас было 2 чекпойнта, значит WAL-ы успели отротироваться на мастере. если всё это было быстрее, чем эти ваши 2GB могли пролезть по сети — мы пришли к тому, что на мастере мы слишком быстро промотали WAL. я бы рекомендовал посмотреть на настройки контрольных точек в первую очередь, при адекватных настройках мастер не будет так быстро ротировать сегменты. я обычно ставлю таймаут в 1 час и ставлю max_wal_size=16G ну и да, wal_keep_segments тоже помогут. 1024 = +16GB на диске
> Предположил что реплике не хватило количества wal файлов Да, скорее всего. > за это отвечает параметр конфигурации wal_keep_segments В том числе, да. > и как правильно рассчитывать этот параметр? А почему бы не посмотреть на слоты репликации вместо этого параметра?
А я бы настроил archive_command на мастере и restore_command на реплике. Слоты репликации имеют очень неприятное свойство забивать $PG_DATA, когда реплика начинает отставать, а вы с этим ничего поделать не можете. Было и такое - диски на реплике просели на запись, и оппа! 95% PG_DATA занято. Аврал, полкомпании рвут все разные части тел, ну и вот это вот всё...
Можно и то, и другое настраивать, кстати. ;) Но если уже есть архив или есть возможность его сделать (+ещё сервер, то есть) — лучше streaming + restore_command, да.
Обсуждают сегодня