над проблемой. Суть есть два пг сервера - мастер и реплика, как-то они живут и нормально. Но вот я хочу погасить машинки для проведения технических работ. И проблема заключается в том что мастер очень часто наглухо зависает при выключении. и держит его процесс wal_sender. Причем нет никакой разницы в том, что я сначала гашу - стендбай или мастер. если убивать этот процесс или гасить через pg_ctl stop -m immediate (точный синтаксис не помню, но -m fast не помогает) то при возвращении будет скорее всего повреждение данных. Что у меня не так?
мужик, честно, не знаю, но где то здесь должен быть ответ
Ты наверное удивишься, но на свете есть куча людей, у которых нет возможности выучить наизусть 13 мегабайт пэдээфа. Более того, у них есть не менее интересные занятия.
Сначала перестаньте делать shutdown immediate. Это мало чем отличается от kill -9, к примеру. Данные скорее всего не потеряете, но база будет каждый раз после этого восстанавливаться.
пуля -9 в голову - потеря данных, да
мастер при выключении должен 1) передать все WAL журналы на реплику (не помню с какой версии но вроде уже давно); 2) сбросить все shared buffers на диск. Вам надо просто дождаться завершения этих процедур, вместо этого вы аварийно завершаете работу БД через kill -9 - это рискованно и может привести к повреждению БД Продолжительность выключения зависит от лага репликации (отставание реплики), и размера грязных страниц в shared buffers и скорости дисков/сети.
Ничего подобного. Если от такого там действительно теряются данные, у меня для Вас плохие новости — там проблемы с fsync, и данные могут быть потеряны и при внезапном power off, например. Аналогично к @lesovsky — это по поводу 1 апреля такие утверждения? ;)
при стечение обстоятельств риск потери данных есть, тем более вы и сами это утверждаете: > Если от такого там действительно теряются данные, у меня для Вас плохие новости — там проблемы с fsync выключать базу по SIGKILL это не общепринятая практика, не надо писать так как будто это нормально и за это никогда не будет последствий.
> при стечение обстоятельств риск потери данных есть Да, если по стечению обстоятельств "оказалось" так, что, например, DBA ненастоящий. ;) Т.е. если сервер (OS) не настроен корректно и/или использует "неправильное" железо. > не надо писать так как будто это нормально Это "нормально" в том плане, что данные не должны теряться. Если теряются в такой ситуации при условии исключения вышеуказанных проблем — это причина для bug report, вот и все "последствия". ;)
все что вы написали имхо неважно, дба... железо... Выключать по SIGKILL следует только в крайнем случае, когда других вариантов остановить базу не осталось.
Потому что гладиолус? FUD такой FUD, в общем. > я топлю за утверждение "Выключать по SIGKILL нельзя" https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/postmaster/postmaster.c;h=4a3ca78c1b7063f69eb20e9d936629cd2849049f;hb=HEAD#l1836 Раз "топите" — может, расскажете это теперь PostgreSQL hackers (смотрите — они-то не знают!)? ;) И да, а что случается при OOM kill, кстати?
Нет ли в этом списке пункта - заархивировать все wal сегменты?
Ага, походу я что-то подобное сделал на своей машине
А если kill придёт ТОЛЬКО в postmaster. Каковы могут быть последствия?
Умрут все т.к. "shared memory may be corrupt" или как-то так.
Из https://www.postgresql.org/docs/current/server-shutdown.html : "It is best not to use SIGKILL to shut down the server. Doing so will prevent the server from releasing shared memory and semaphores. Furthermore, SIGKILL kills the postgres process without letting it relay the signal to its subprocesses, so it might be necessary to kill the individual subprocesses by hand as well."
Редко, но я видел "зависшие" checkpointer или даже рабочий процесс после "убийства" postmaster.
Прямо как по написанному же.
Ну да. Я хотел редкость этого отметить. Киляю я эти процессы не по пять раз на дню, но достаточно регулярно :)
Хороший вопрос. Долго искал ответ, т.к. в памяти вспоминается случай когда я или кто-то из коллег сталкивался со случаем что постгрес не выключался именно из-за архивирования, но детали уже забылись... Посмотрел бегло по документации, заявленного поведения не нашел. Полез в код, нашел это. Между копированием сегментов archiver стоит проверка на выключение в случае сработки архивация прерывается.
Обсуждают сегодня