Было бы существенно проще найти инфу по беде, если бы не клюквенные логи

других нет

"corrupted item pointer"

сегфолты с оомами точно не приходили?

неа

и диск бодрячком?

тоже думал диск

но кластер новый пересоздавал

а ошибка та же

PANIC: corrupted item pointer: offset = 2240, size = 48

вот такие сообщения в другом кластере на 9,2

Всем добрый вечер. Поручили организовать горячие бэкапы на PostgreSql 9.3. Почитал доки, но остались некоторые вопросы. Как часто стоит делать базовый бэкап включающий в себя wal файлы? Т.е. к примеру 3-4 раза в день? Сами wal хранить какой период? Можно ли каждый день перемещать/архивировать wal файлы? Не будут ли конфликтов имен файлов? Например убарл в архив кипу wal'ов, потом через день организовался wal с таким же именем, необходимо восстановится. При извлечении wal'ов не будут ли проблемы с одинаковыми именами?

И вообще какого подхода стоит придерживаться при таком методе? Все доки описывают лишь общую информацию с которой как раз нет проблем. А вот архитектурную часть не затрагивают.

https://grap4it.files.wordpress.com/2013/11/apress-rman-recipes-for-oracle-database-11g.pdf

Общие приципы описаны

инструменты разные, базы разные но суть одна и та-же

архитектурно пожно почитать там

А Если кратко пройтись по вопросам выше? В частности интересует конфликт имен файлов. Такое вообще возможно?

За ссылку на книгу спасибо.

Общий принцип такой: раз в N единиц времени делаете бэкап, храните M бэкапов и непрерывный архив WAL с самого старого бэкапа. N и M зависят от времени снятия бэкапа и от ваших возможностей по хранению всего этого добра

Конфликтов в именах файлов не будет

настройте периодический pg_basebackup + archive_command в конфиге

Полный бэкап на данный момент небольшой. В в заархивированном виде порядка 9 гигов. Частота базовых бэкапов насколько важна? 2 раза в сутки, раз в сутки, чаще?Предположим если имеется постоянно 4 базовых бэкапа A,B,C,D и срез wal'ов от A до D - это по сути тоже самое что просто базовый бэкап A + все wal'ы. Или я не так понимаю? Преимущество от этого будет только в скорости накатывания wal'ов?

да, от А до состояния между C и D, например, будет дольше накатываться, чем от С до этого состояния. Но если у вас активность в базе мала => мало wal, разница во времени будет небольшая

частота выполнения бэкапа зависит от ваших требований. Сколько у вас есть время на восстановление. Возьмите, протестируйте, сколько ваша база будет накатывать сутки логов. Если вас это время устраивает, то ставьте раз в сутки. Но чаще чем раз в сутки, я не видел, чтобы кто-то делал на сколь-нибудь значительном объеме данных (9Гб - маленький объем).

По опыту, насколько снятие бэкапа замедляет одновременную работу пользователей? Существенный ли это фактор?

на загруженной базе может чувствоваться, поэтому бэкап, как правило, снимают с реплики

Реплику, к сожалению, руководство поднимать пока отказывается. База не нагружена. Порядка 25-50 пользователей. Но запросы бывают довольно тяжелыми.

протестируйте, пока не протестируйте - не поймете

Спасибо!

А на реплике бэкап при постоянных апдейтах мастера может отваливаться, если слишком много изменений

дык настраивать нада

вы про дамп или про бэкап?

про бэкап

А чем вы делаете бекап, что он отваливается?

А чем вы делаете бекап, что он отваливается?

pg_dump просто

и с каким ответом он отваливается? Просто это как то нереалистично.

ну pg_dump - это дамп, а не бэкап. Он отваливается, когда вакуум почистил строки на мастере, которые должны быть видны pg_dump'у

и происходит conflict with recovery

Никто не против, если я посоветую вот эту тулзу для бэкапов WAL файлов? https://github.com/wal-e/wal-e

используем уже как 2 года и довольны

умеет бэкапить в облако

S3, Google Storage, Azure BS...

и происходит conflict with recovery

Вот что-то типа того, pg_dump canceling statement due to conflict with recovery. У нас база была около 300 гигов, сама не росла, но апдейты очень быстро прокручивали wal-логи, вакуумы вакуумили, мы в итоге эти апдейты убрали в редис. И оттуда сливаем раз в час.

просто pg_dump делает как бы дамп, т.е. логический бэкап, а pg_basebackup делает физический бэкап, он так не отваливается

Добрый день. Сегодня вдруг упала одна из баз данных с ошибкой вида «неверная страница в блоке ххх отношения /base/..." реиндексация, вакуум, падает на нем же. Стоит 9.3.4 1с. Пришлось откатываться на бэкап. Собственно из-за чего произошло это и как этого избежать в будущем? Можно ли восстановить уже пожилые данные до состояния консистентности?

Добрый день. Сегодня вдруг упала одна из баз данных с ошибкой вида «неверная страница в блоке ххх отношения /base/..." реиндексация, вакуум, падает на нем же. Стоит 9.3.4 1с. Пришлось откатываться на бэкап. Собственно из-за чего произошло это и как этого избежать в будущем? Можно ли восстановить уже пожилые данные до состояния консистентности?

У меня было изза дохлого винта

База крутится на виртуалке, виртуалка запущена на кластере esxi. Причем поднята виртуалка совсем недавно... Как-то сомнительно что из-за этого. Могут быть еще причины? Файловая система ext4

У меня было изза дохлого винта

Вы кстати как решили вашу проблему? Переход на другой винт? Смогли восстановить данные, или откатывались на бэкапы?

Вы кстати как решили вашу проблему? Переход на другой винт? Смогли восстановить данные, или откатывались на бэкапы?

не, у нас только агрегированные данные повредились, перегенерировали их заново на новом железе и все

умеет бэкапить в облако

плохо в ней только то, что она не умеет бэкапить НЕ в облако

а так - да, золотая тулза

> «неверная страница в блоке ххх отношения А сколько баз 1С на сервере и, если их много, какой паттерн их именования? Например "cluster1", "cluster_1", "cluster.1" и т.п.

Вы кстати как решили вашу проблему? Переход на другой винт? Смогли восстановить данные, или откатывались на бэкапы?

У меня была подобная ситуация. Данные восстановил частично, кроме участков с битой страницей. Делал дамп битой таблицы, с ограничением по ид, часть записей пропала, эти строки восстановил из бэкапа. Скорее всего, сдампить данные, которые не попали в данную страницу поможет zero_damaged_pages (boolean) Естественно, перед всем этим, необходимо сделать бэкап того, что осталось от бд.

> «неверная страница в блоке ххх отношения А сколько баз 1С на сервере и, если их много, какой паттерн их именования? Например "cluster1", "cluster_1", "cluster.1" и т.п.

паттерна наименования как такого нет. Имеется 7 баз.

У меня была подобная ситуация. Данные восстановил частично, кроме участков с битой страницей. Делал дамп битой таблицы, с ограничением по ид, часть записей пропала, эти строки восстановил из бэкапа. Скорее всего, сдампить данные, которые не попали в данную страницу поможет zero_damaged_pages (boolean) Естественно, перед всем этим, необходимо сделать бэкап того, что осталось от бд.

у меня вообще не хотел дампить, к сожалению. Не разобрались из-за чего авария произошла? Как хоть от этого спасаться в будующем.

у меня вообще не хотел дампить, к сожалению. Не разобрались из-за чего авария произошла? Как хоть от этого спасаться в будующем.

Пришёл oom и гнусно потрогал постгрес.

для сохранности данных помогает кластер с чексуммами.

Пришёл oom и гнусно потрогал постгрес.

У нас точно такой проблемы не было. Вообще все стандартно работало. Люди с утреца начали работу в штатном режиме, а далее - все, приплыли.. Каких-либо специфичных ошибок в логах не нашел. Только уже на моментах конкретных запросов к битой таблице.

У нас точно такой проблемы не было. Вообще все стандартно работало. Люди с утреца начали работу в штатном режиме, а далее - все, приплыли.. Каких-либо специфичных ошибок в логах не нашел. Только уже на моментах конкретных запросов к битой таблице.

Виртуалка мигрировала по кластеру esxi? Может там что-то не так произошло?

Я доступа к esxi не имею. Другой человек этим занимается. Но насколько я знаю подобных работ не должно было проводиться. Делали клон виртуалки - это да, снапшоты, тоже да. Но саму виртуалку никуда не дергали.

Клон тоже делали не сегодня. Сомневаюсь что это должно было сказаться.

всем привет:) а здесь могут помочь с постгре?)

ERROR: S client not available

С постгре не очень. С постгресом могут, с постгрескюэлем тоже, а с постгре - сложно :)

ну вот:(

ну если вдруг кто-нибудь зачитает:) история простая, есть федора24 и соответсвенно postgresql 9.5.3. Если в конфиге поставить listen_addresses = 'ipPC', и перезапустить компьютер, то служба не стартует, если поставить * то всё ок

:)просто может кто сталкивался;)

судя по логам, он пытается стартануть службу ещё до того как получил адрес по dhcp

:)это норма?

или у меня руки не от туда)) растут просто

А что именно в логах говорится?

Так-то можно сделать echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind, и в sysctl.conf прописать, чтобы можно было на любом IP слушать, даже если его нет ещё.

Jul 14 23:18:24 localhost.localdomain postgresql-ctl[960]: LOG: could not bind IPv4 socket: Cannot assign requested address Jul 14 23:18:24 localhost.localdomain postgresql-ctl[960]: HINT: Is another postmaster already running on port 5432? If not, wait a few seconds and retry. Jul 14 23:18:24 localhost.localdomain postgresql-ctl[960]: WARNING: could not create listen socket for "10.2.0.5" Jul 14 23:18:24 localhost.localdomain postgresql-ctl[960]: FATAL: could not create any TCP/IP sockets Jul 14 23:18:25 localhost.localdomain postgresql-ctl[960]: pg_ctl: could not start server Jul 14 23:18:25 localhost.localdomain postgresql-ctl[960]: Examine the log output.

Или настроить порядок загрузки..

А когда уже адрес есть, работает?

да, если потом ручками рестартануть, всё ок

просто по логам он чуть позже получает адрес 10.2.0.5

sleep 10 и ок c стартовый скрипт )

просто на 23 федоре и postgresql 9.4.x какая то всё было ок

а тут...ересь..

а так то...для локальной базы может быть не так и страшно оставить листен адрес в *?

или лучше заморачиваться с задержкой?

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ - вообще вот, надо systemctl конфиги починить

а так то...для локальной базы может быть не так и страшно оставить листен адрес в *?

Файрволом закрыть от внешнего мира, и готово.

ну так то там еще перед ним стоит супермикро...смотрящая в инет...так что он полностью в лане

просто это же дефолтные конфиги...неужели не дотестировали...не очень хочется просто править эти юниты

Fedora же

Это как раз и есть тестирование:)

https://habrahabr.ru/post/305662/

А распаралелливание аггрегирования к оконным функциям относится ?

Есть вопрос про статистику. Есть табличка с большим количеством значений. (пара миллионов) Строится выборка по полю OwnerID::character varying(32) = 'какое то значение'. Селективность его достаточно высокая индекс есть. Так вот статистика говорит, что мы выберем 81к строк, выбираем 71к. Ошибка конечно не на порядок, но всеравно довольно большая. Можно ли её уменьшить? default_statistics_target?

а какую проблему это решает?

Есть вопрос про статистику. Есть табличка с большим количеством значений. (пара миллионов) Строится выборка по полю OwnerID::character varying(32) = 'какое то значение'. Селективность его достаточно высокая индекс есть. Так вот статистика говорит, что мы выберем 81к строк, выбираем 71к. Ошибка конечно не на порядок, но всеравно довольно большая. Можно ли её уменьшить? default_statistics_target?

ошибки нету, статистика очень близкая