Комментарии 3
WAL-логи
таблицы не пострадают, так как они расположены в другом месте
Просто для справки, без этих файлов база не поднимется сама после аварии. Более того, поднятие СУБД без WAL — исключительно сложная задача, получить консистентное состояние базы на какой-то момент, предшествующий аварии, практически невозможно.
Уж лучше пусть не поднимется после аварии, чем не сможет сохранить состояние после исчерпания места на диске из-за WAL логов.
Если WAL-лог лежит на другом диске и диск переполнился, то PostgreSQL можно корректно остановить, чтобы он скинул текущее состояние на диск с таблицами. Если WAL-лог лежит на диске с таблицами, то PostgreSQL некуда будет писать обновления по текущему состоянию в памяти.
Если WAL-лог лежит на другом диске и диск переполнился, то PostgreSQL можно корректно остановить, чтобы он скинул текущее состояние на диск с таблицами. Если WAL-лог лежит на диске с таблицами, то PostgreSQL некуда будет писать обновления по текущему состоянию в памяти.
Интерено читать «пусть не поднимется после аварии», ведь WAL как раз для того, чтобы база поднялась после аварии.
Если способность подняться после аварии не имеет ценности, то WAL можно и на tmpfs держать, и fsync выключить. Но не делайте так (wal только на диске/ssd и fsync включён). Потому что без WAL шансы восстановить консистентные данные невелики.
Против держания WAL на отдельном диске ничего не имею, мой комментарий лишь о том, что сохранность WAL так же важна, как и самих файлов данных.
Если способность подняться после аварии не имеет ценности, то
Против держания WAL на отдельном диске ничего не имею, мой комментарий лишь о том, что сохранность WAL так же важна, как и самих файлов данных.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Устранение узких мест в PostgreSQL при высоких нагрузках