О восстановлении.
Добрый день, уважаемые коллеги!
Сегодня я хотел бы рассмотреть оченно интересную статью на Хабре: Восстановление данных PostgreSQL после потери pg_control. А именно, что такое потеря данных, которые выводятся командой pg_controldata с точки зрения практикующего инженегра по эксплуатации. С высоты своего жЫзненного опыта и глубины погружения в тему.
Итак, поехали!
А теперь без вашего позволения я немного заберусь вглубь файловых систем и собственный опыт.
Что мы имеем в ситуации, когда постгрес не запускается по причине утери файла pg_control? После некоторых раздумий в голове остается только одно: питание было потеряно в момент сброса на диск кеша, содержащего суперблок(и). Что мы будем иметь в таком случае?
- слетевшую файловую систему, ГАРАНТИРОВАННО слетевшую! С вероятностью, стремящейся к 100% вместо файловой системы у вас каша, и в /lost+found какое-то лютое количество бинарных файлов имеющих наименования, далекие от читабельности, а именно - какие-то наборы символов, которые вполне себе можно в качестве паролей использовать. Мало того! Эти файлы - в подавляющем большинстве случаев - это каша из разных файлов! Т.е. кусок текста, далее - кусок картинки, далее - еще какая-нибудь белиберда, которую можно поднять только hex-редактором.
Вы что там поднимать собрались?! У вас в табличных пространствах с большой вероятностью что попало! И хорошо, если каталоги пустые, или там невооруженным глазом видно, что всё, хана. Потому что бесплодные попытки восстановить невосстановимое - это совершенно неоправданная потеря времени. Ни с точки зрения личного профессионального роста, ни, тем более, с точки зрения бизнеса.
Вы никогда не видели ФС после внезапного выключения питания? Примите мои соболезнования. Я, хвала всем Богам, такие ФС видел, либо имея рядом резервную копию, либо теряя восстановимые данные. А если у вас один сервер БД и нет ни резервных копий, ни какой-либо отказоустойчивости - ну что я могу сказать - у вас все впереди. На бесперебойники тоже надеяться не стоит - они, бывает, выходят из строя. Есть и такой опыт.
Но это техническая сторона. Есть еще и административно-управленческая.
Народ, а вот попробуйте непосвященному доказать необходимость создания резервных копий и прочей отказоустойчивости, когду у него будет перед глазами вот эта вот статья о восстановлении. Или вы никогда не видели "руководителей", которые занимаются бездумным сокращением расходов на эксплуатацию средств вычислительной техники? Ну ничего, все еще впереди. Таких есть, и есть весьма прилично. :(
А в случае сбоев ФС, каковые я описал, кто будет виноват? Вы думаете подобный "руководитель"? Я вас таки сильно расстрою, но виноватым будет непосредственный эксплуататор. В любом случае. Было в моей практике случаев, когда магазин терял бухгалтерию за несколько лет, и виновному было ничего. Потому что вот.
Мне бы очень хотелось почитать, что думает по этому поводу hydrobiont, с точки зрения бизнеса, построенного на эксплуатации Постгреса - как быть, когда ИТ-начальнЕГ тычет в лиТСо подобной статейкой и утверждает, что восстановление данных - это рутина, и платить какие-то бешеные бабки в случаях сбоев он не будет. При этом в контракте стоит весьма серьезные штрафные санкции за потерю данных и длительные простои. А чтобы совсем весело было, заказчик - гос/бюджет, статусный, послать в дальние дали нельзя в принципе, пошлешь такого - вылетишь с рынка, без вариантов.
Ну и что пожелать автору статьи сделать с его финальной фразой: "Всем успешной эксплуатации PostgreSQL и резервных копий под рукой!"?
Грустно. Печально. Ну ладно.
Сегодня я хотел бы рассмотреть оченно интересную статью на Хабре: Восстановление данных PostgreSQL после потери pg_control. А именно, что такое потеря данных, которые выводятся командой pg_controldata с точки зрения практикующего инженегра по эксплуатации. С высоты своего жЫзненного опыта и глубины погружения в тему.
Итак, поехали!
- pg_control - если уж указываете имя, надо указывать полный путь:
root@shurutovmv ~ # find /var/lib/postgresql/9.4/data/ -name "*pg_control*"
/var/lib/postgresql/9.4/data/global/pg_control
При этом в материале вполне себе пойдет замена /var/lib/postgresql/9.4/data/ на PGDATA, кому надо - поймут;
Эта статья может быть полезна в тех случаях,
Дык вот. Эта статья в публичном неподконтрольном доступе безусловно вредна. О чем я и буду немного рассуждать;
Но это так, мелкая придирка, докопаться захотелось.
А теперь без вашего позволения я немного заберусь вглубь файловых систем и собственный опыт.
Что мы имеем в ситуации, когда постгрес не запускается по причине утери файла pg_control? После некоторых раздумий в голове остается только одно: питание было потеряно в момент сброса на диск кеша, содержащего суперблок(и). Что мы будем иметь в таком случае?
- слетевшую файловую систему, ГАРАНТИРОВАННО слетевшую! С вероятностью, стремящейся к 100% вместо файловой системы у вас каша, и в /lost+found какое-то лютое количество бинарных файлов имеющих наименования, далекие от читабельности, а именно - какие-то наборы символов, которые вполне себе можно в качестве паролей использовать. Мало того! Эти файлы - в подавляющем большинстве случаев - это каша из разных файлов! Т.е. кусок текста, далее - кусок картинки, далее - еще какая-нибудь белиберда, которую можно поднять только hex-редактором.
Вы что там поднимать собрались?! У вас в табличных пространствах с большой вероятностью что попало! И хорошо, если каталоги пустые, или там невооруженным глазом видно, что всё, хана. Потому что бесплодные попытки восстановить невосстановимое - это совершенно неоправданная потеря времени. Ни с точки зрения личного профессионального роста, ни, тем более, с точки зрения бизнеса.
Вы никогда не видели ФС после внезапного выключения питания? Примите мои соболезнования. Я, хвала всем Богам, такие ФС видел, либо имея рядом резервную копию, либо теряя восстановимые данные. А если у вас один сервер БД и нет ни резервных копий, ни какой-либо отказоустойчивости - ну что я могу сказать - у вас все впереди. На бесперебойники тоже надеяться не стоит - они, бывает, выходят из строя. Есть и такой опыт.
Но это техническая сторона. Есть еще и административно-управленческая.
Народ, а вот попробуйте непосвященному доказать необходимость создания резервных копий и прочей отказоустойчивости, когду у него будет перед глазами вот эта вот статья о восстановлении. Или вы никогда не видели "руководителей", которые занимаются бездумным сокращением расходов на эксплуатацию средств вычислительной техники? Ну ничего, все еще впереди. Таких есть, и есть весьма прилично. :(
А в случае сбоев ФС, каковые я описал, кто будет виноват? Вы думаете подобный "руководитель"? Я вас таки сильно расстрою, но виноватым будет непосредственный эксплуататор. В любом случае. Было в моей практике случаев, когда магазин терял бухгалтерию за несколько лет, и виновному было ничего. Потому что вот.
Мне бы очень хотелось почитать, что думает по этому поводу hydrobiont, с точки зрения бизнеса, построенного на эксплуатации Постгреса - как быть, когда ИТ-начальнЕГ тычет в лиТСо подобной статейкой и утверждает, что восстановление данных - это рутина, и платить какие-то бешеные бабки в случаях сбоев он не будет. При этом в контракте стоит весьма серьезные штрафные санкции за потерю данных и длительные простои. А чтобы совсем весело было, заказчик - гос/бюджет, статусный, послать в дальние дали нельзя в принципе, пошлешь такого - вылетишь с рынка, без вариантов.
Ну и что пожелать автору статьи сделать с его финальной фразой: "Всем успешной эксплуатации PostgreSQL и резервных копий под рукой!"?
Грустно. Печально. Ну ладно.