и что дальше? он просто кого-то другого убьёт

Другого не жалко

тут как-то уже кажется эту тему поднимали, но не помню чем закончилось... есть самоподписанные сертификаты, приложение идет напрямую в постгрес, но по каким-то причинам ЧАСТЬ коннектов отваливаются с SSL error: certificate verify failed ... кто-нибудь может подсказать куда копать ?

часы синканы?

тут как-то уже кажется эту тему поднимали, но не помню чем закончилось... есть самоподписанные сертификаты, приложение идет напрямую в постгрес, но по каким-то причинам ЧАСТЬ коннектов отваливаются с SSL error: certificate verify failed ... кто-нибудь может подсказать куда копать ?

у меня такое бывает, когда клиент занимается верификацией сертификатов сервера. Отключаю эту самую верификацию и радуюсь жЫзни.

часы да синканы, одна машина

на счет верификации попробую...

В dsn строке есть возможность написать: sslmode=disable

невариант

тут как-то уже кажется эту тему поднимали, но не помню чем закончилось... есть самоподписанные сертификаты, приложение идет напрямую в постгрес, но по каким-то причинам ЧАСТЬ коннектов отваливаются с SSL error: certificate verify failed ... кто-нибудь может подсказать куда копать ?

сделайте самоподписанный CA. Других вариантов нет

сделайте самоподписанный CA. Других вариантов нет

Не прокатывает в большинстве (по слухам, у меня всегда не прокатывало) случаев. Не хочЮт клиенты работать с самоподписанными CA.

либо они будут работать через самоподписанный CA, либо пусть строят валидеый CA, либо отключайте верификацию сертов вообще

Это и есть самоподписанный CA

Все работает отлично, глаз замылился не заметил что указал балансер вместо коннекта к pg

Кто-нибудь AWS Glacier для бекапов использует? Там правда такая дикая цена за ретрив данных - например $6000 за 3ТБ? В то же время класть на хранение 3ТБ каждый месяц стоит всего $21

Кто-нибудь AWS Glacier для бекапов использует? Там правда такая дикая цена за ретрив данных - например $6000 за 3ТБ? В то же время класть на хранение 3ТБ каждый месяц стоит всего $21

https://aws.amazon.com/ru/glacier/pricing/ у них есть калькуляторы можно посчитать

и условия тоже

Страховка наоборот: платишь ежемесячные взносы, а при наступлении страхового случая платишь ещё больше...

я там не нашел цен в 2$ за гб

Страховка наоборот: платишь ежемесячные взносы, а при наступлении страхового случая платишь ещё больше...

Зависит от того, сколько эти данные стоили

Кто-нибудь AWS Glacier для бекапов использует? Там правда такая дикая цена за ретрив данных - например $6000 за 3ТБ? В то же время класть на хранение 3ТБ каждый месяц стоит всего $21

а почему 21 ?

а вижу.

Добрый день. Использую PostgreSQL 9.4.9 1C сборка от postgrespro. На эту версию перешли относительно недавно, до этого был 9.3.4 1C. Довольно часто ловлю такие вот ошибки index "pg_depend_reference_index" contains unexpected zero page at block 191. Statement: create temporary table tt1... Информационная база - зарплата и управление персоналом. Ошибка возникает почти при аналогичных условиях: База работает, затем ночью в 4:00 происходит остановка сервиса 1с (чтобы отключить клиентов от базы), создание дампа, полученный дамп восстанавливается в тестовую базу, 1с поднимается. Далее в 5:30 1с останавливается, останавливается postgresql, файлы пришедшие через arhive_command на внешнее хранилище архивируются, старые подчиющаются, поднимается postgresql, выполняется basebackup, поднимается сервис 1с (да, я понимаю что процесс может выглядеть сложным и не правильным, что можно сделать без остановок, но пока вот так). Далее начинается проблема описанная выше. Возникает не каждый раз и не каждый день, но уже с регулярностью. Кто-то сталкивался с подобной проблемой? Куда копать? Почему postgres начинает сыпаться? Может проблема в online_analyze проходящего с патчем 1с? Его настройки выставлены по умолчанию. Данные о системе - Centos 7.2, lvm + xfs. Все это крутится в виртуальной машине на esxi.

есть группа https://telegram.me/PosstgreSQL_1C_Linux

dump-restore пробовали?

а так, проблемы у вас возникают с версией pg, который вы сняли через basebackup?

или проблемы с рабочей версией? (тогда не понимаю зачем весь этот длинный опус про бакапы)

С рабочей версией. Весь длинный опус чтобы объяснить что делаю перед тем как возникает проблема. Ибо проблема возникает после остановки/запуска сервиса постгрес

В группе 1с+постгрес я уже пообщался с людьми. Сюда пришел за свежими мыслями :)

Что значит: "старые данные подчищаются"?

> index "pg_depend_reference_index" contains unexpected zero page at block 191 ну как бы только востаналиваться из бакапа пробовали?

или после востановления из бакапа возникает ошибка?

fsync=off? :)

> index "pg_depend_reference_index" contains unexpected zero page at block 191 ну как бы только востаналиваться из бакапа пробовали?

Реиндекс по pg_depend решает проблему на несколько дней. Потом повторения.

fsync=off? :)

On. Full_page_writes on etc. Все включено

Что значит: "старые данные подчищаются"?

Старые wal архивы с внешнего хранилища

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

Ну во-первых первых сам постгрес хинтует об реиндексе, во вторых поднимал базу из дампа и проблема все равно проявлялась вновь.

Через какое-то время после ночных остановок/подъема

востанавливайтесь из бакапа. поверьте, проверить испорчены ваши данные или нет на текущий момент нельзя

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

востаналивайтесь из бакапа. хинт про реиндкс написал разраб, которому насрать на ваши данные.

>вторых поднимал базу из дампа и проблема все равно проявлялась вновь. это другое дело

из логического дампа надеюсь?

>вторых поднимал базу из дампа и проблема все равно проявлялась вновь. это другое дело

данные поломались настолько давно, что уже во всех бекапах - битые.

из логического дампа надеюсь?

Из логического. Он снимается каждую ночь.

инстанс переинициализировали?

или дамп лили в старый инстанс?

В старый. Но ошибки не на общих системных таблицах. Вообще подобные сбои начали появляться после перехода на новую версию постгреса через pgdump_all и соответственно через инициализации нового кластера. Кластер с чексуммами.

> после перехода на новую версию постгреса через pgdump_all чего только не придумают, чтобы pg_upgrade не юзать... :(

> после перехода на новую версию постгреса через pgdump_all чего только не придумают, чтобы pg_upgrade не юзать... :(

через upgrade чексуммы не включишь

> после перехода на новую версию постгреса через pgdump_all чего только не придумают, чтобы pg_upgrade не юзать... :(

pg_upgrade работает только с extension из контриба

В старый. Но ошибки не на общих системных таблицах. Вообще подобные сбои начали появляться после перехода на новую версию постгреса через pgdump_all и соответственно через инициализации нового кластера. Кластер с чексуммами.

таки переливать надо в новый :(

pg_upgrade работает только с extension из контриба

да, вот это проблема

таки переливать надо в новый :(

Чем это обоснованно? Ошибка в индексе не системной таблицы. Pgdump работает а учитывая чексуммы мы должны при этом получить гарантию что с данными при этом ок. Или я что-то не так понимаю?

обосновано тем, что данным доверять уже нельзя

чексуммы говорят что 8k блок - ок

но нигде не хранится информации о том, сколько таких блоков в таблице

И да, индекс в постгрессе же отдельная структура и не трогать данные. Каким образом реиндекс может убить данные в основном отношении?

я не буду вас уговаривать. ок. просто у вас сломался файл и вы дико верите что только он один. ок

всем привет

наткнулся на непонятный косяк

может кто сталкивался

но нигде не хранится информации о том, сколько таких блоков в таблице

Но когда мы делаем дамп мы считаем все страницы с диска, т.е. для каждой страницы мы гарантируем что она ок. Я как то слабо верю в коллизию при этом которая не ломает еще и структуру.

неправильные данные toast_bytes

Но когда мы делаем дамп мы считаем все страницы с диска, т.е. для каждой страницы мы гарантируем что она ок. Я как то слабо верю в коллизию при этом которая не ломает еще и структуру.

неправда, данные в toast ищется по index'у.

ERROR: S client not available

а не сексканом

у меня таблицы точно большие, но показывает что там дофига тоста и почти нет данных

я не буду вас уговаривать. ок. просто у вас сломался файл и вы дико верите что только он один. ок

Без обид, но я пытаюсь понять как это реально работает. Ведь есть гарантии чексум и они делались для того чтобы представить гарантии. Я не прав в этом?

чексуммы вам гарантируют что конкретно прочитанный вами блок - валиден

ничего больше, проведите эксперимент - pgbench

потом остановите pg и сделайте > path/to/oid

после старта таблица будет пустая, и валидная

не смотря на включенные чексуммы

не смотря на включенные чексуммы

Но в вашем случае мы просто затрем файл, не оставим данных и следственно и информации чексум в ней. Структура при этом будет в другом месте. Потому мы типа считаем что таблица аля транкейтнута и все.

если вы можете провалидировать данные простым сексканом, то в случае когда в toast хранится часть ваших данных, поиск в toast будет проводиться по index

Это не случай когда мы меняем пару бит

это более частый use-case, когда файлы транкейтяться в случае потери питания

Но при этом мы просто теряем все данные. А не часть или получаем невалидные данные.

вот у вас есть relation: 1111 1111.1 1111.2 1111.3 «« транктейнула fs 1111.4 у вас транкейтнулся 3, как только pg получит EOF, он завешит seqscan и данные с точки зрения чексум будут валидны

Пользователи в системах типа 1с где все на всем завязано увидели бы потерю большого блока данных и потерю всяких там ссылок

да-да, пользователи заметят. ок.

Причем смотрите, если бы были транкейтнуты вообще общие системные таблицы мы бы вообще нормально с каждой базой работать не смогли. Смысл тогда перезаливать кластер? Базу в которой произошел какой-то сбой - еще можно понять.

ок!

если проблемы будут продолжаться - можете обратиться к нам, в PgPro, у нас есть утилита, что проверяет консистентность инстанса. к тому же мы работаем над checksum'ами у clog (в ванильном pg этого нет, к вопросу о включенных чексуммах)

если проблемы будут продолжаться - можете обратиться к нам, в PgPro, у нас есть утилита, что проверяет консистентность инстанса. к тому же мы работаем над checksum'ами у clog (в ванильном pg этого нет, к вопросу о включенных чексуммах)

а вы не планируете заделится утилитой? Я не злорадствую, а просто спрашиваю

ИМХО, очень полезная штукенция

если проблемы будут продолжаться - можете обратиться к нам, в PgPro, у нас есть утилита, что проверяет консистентность инстанса. к тому же мы работаем над checksum'ами у clog (в ванильном pg этого нет, к вопросу о включенных чексуммах)

а эта утилита бесплатная?

будет в опенсорсе :)

у mysql была похожая, но страшная, как смерть. В свое время она меня спасла

но в ядре pg много не хватает

но мы оставляем ее работоспособная с ваниллой, на сколько это можно.

ок!

Возможно я конечно не прав, но мне кажется что такие проблемы должны были бы высыпаться сразу.

если проблемы будут продолжаться - можете обратиться к нам, в PgPro, у нас есть утилита, что проверяет консистентность инстанса. к тому же мы работаем над checksum'ами у clog (в ванильном pg этого нет, к вопросу о включенных чексуммах)

Такие утилиты были бы очень полезны.

я просто помню свою историю про битый блок, который путешествовал в бакапах полгода :)

Меня еще интересует корень этого случая. Из-за чего вообще это высплывает. И почему рецидивится.

я уверен что корень этой проблемы - хардварная/виртулизации

Т.е. виртуализация для постгреса зло?