barman

а в pg_dumpall нельзя разве выбрать custom format?

рано я собрался отмечать ? pg_dump: Dumping the contents of table "comments" failed: PQgetResult() failed. pg_dump: Error message from server: ERROR: invalid page in block 92800 of relation base/16385/16443

:D

А мы тебе говорили.

эх ладно, буду читать

zero_damaged_pages сейчас включу и попробую снова

Блин, котаны, читаю вас и уже боюсь на пг вкатываться

Там вообще можно настроить все и на N лет забыть? ?

Блин, котаны, читаю вас и уже боюсь на пг вкатываться

зря боитесь. У остальных ДБЕ все еще хуже

Там вообще можно настроить все и на N лет забыть? ?

ток если с бекапами

никогда не видели, как mysql себя ведет, когда ib_data ломается?

никогда не видели, как mysql себя ведет, когда ib_data ломается?

Я на MS SQL, вообще ничего не ломалось никогда

Я на MS SQL, вообще ничего не ломалось никогда

ну да, конечно, никогда-никогда

у меня mssql унес с собой в могилу виртуальный цод на полтысячи виртмашин

Я на MS SQL, вообще ничего не ломалось никогда

А нука вытащите два диска из RAID5 и с оставшегося решето попробуйте чего ни будь вытащить!

нельзя без бэкапов БД.

pg_dump: WARNING: invalid page in block 92800 of relation base/16385/16443; zeroing out page pg_dump: Dumping the contents of table "comments" failed: PQgetCopyData() failed. pg_dump: Error message from server: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. pg_dump: The command was: COPY public.comments (id, from_id, date, text, reply_to_user, reply_to_comment, attachments, date_found, post_owner_id, post_object_id) TO stdout; pg_dumpall: pg_dump failed on database "vw", exiting

в логе постгреса ничего нет

а в мессаджес?

а нет, вот что: LOG: server process (PID 6449) was terminated by signal 11: Segmentation fault

ну вот

оом киллер?

не думаю, он рестартнулся после zeroing out page

2016-12-06 15:02:06 EET [6395-1] [unknown]@[unknown] LOG: incomplete startup packet 2016-12-06 15:04:01 EET [6449-1] postgres@vw WARNING: invalid page in block 92800 of relation base/16385/16443; zeroing out page 2016-12-06 15:04:01 EET [6388-2] LOG: server process (PID 6449) was terminated by signal 11: Segmentation fault 2016-12-06 15:04:01 EET [6388-3] DETAIL: Failed process was running: COPY public.comments (id, from_id, date, text, reply_to_user, reply_to_comment, attachments, date_found, post_owner_id, post_object_id) TO stdout; 2016-12-06 15:04:01 EET [6388-4] LOG: terminating any other active server processes 2016-12-06 15:04:01 EET [6393-2] WARNING: terminating connection because of crash of another server process 2016-12-06 15:04:01 EET [6393-3] DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2016-12-06 15:04:01 EET [6393-4] HINT: In a moment you should be able to reconnect to the database and repeat your command. 2016-12-06 15:04:01 EET [6440-1] postgres@postgres WARNING: terminating connection because of crash of another server process 2016-12-06 15:04:01 EET [6440-2] postgres@postgres DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory. 2016-12-06 15:04:01 EET [6440-3] postgres@postgres HINT: In a moment you should be able to reconnect to the database and repeat your command. 2016-12-06 15:04:01 EET [6388-5] LOG: all server processes terminated; reinitializin

такое ощущение, что памяти не хватило нужно больше данных

а точно, там 8М выделено в стандартном конфиге

А нука вытащите два диска из RAID5 и с оставшегося решето попробуйте чего ни будь вытащить!

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

у меня mssql унес с собой в могилу виртуальный цод на полтысячи виртмашин

А что конкретно случилось?

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

Чтобы два диска выпали сразу? Легко.

г-ди, снова это: Error message from server: ERROR: timestamp out of range

sa

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

подозреваю что чаще такое случается из-за человеческой глупости, а не из-за надежности техники

подозреваю что чаще такое случается из-за человеческой глупости, а не из-за надежности техники

я с таким сталкивался. Продавец в результате заменил мне все диски на новые. Был бак в прошике Segate

ну и на стенде за 1 килобакс данные подняли.

Чтобы два диска выпали сразу? Легко.

да, такое буквально в прошлом месяце было

Чтобы два диска выпали сразу? Легко.

Тут я тоже не скажу про детали на чем все это дело крутится. Надо у админов узнавать. Знаю только, что там используется какое-то ололо корпоративное решение от QNAP вроде бы

я с таким сталкивался. Продавец в результате заменил мне все диски на новые. Был бак в прошике Segate

и с таким сталкивался на прошлой работе все сегейт диски в одно и то же время стали вылетать в офисе)

Тут я тоже не скажу про детали на чем все это дело крутится. Надо у админов узнавать. Знаю только, что там используется какое-то ололо корпоративное решение от QNAP вроде бы

Ну так если у вас всё серьёзно и без колхоза — риски проблемы файловой системы сведены к нулю, то у тебя вообще голова не должна болеть про это, хоть на MSSQL, хоть на Postgre, хоть на MySQL прости господи.

Ну так если у вас всё серьёзно и без колхоза — риски проблемы файловой системы сведены к нулю, то у тебя вообще голова не должна болеть про это, хоть на MSSQL, хоть на Postgre, хоть на MySQL прости господи.

только так не бывает, чтобы хоть какие-то риски были сведены к нулю

Ну так если у вас всё серьёзно и без колхоза — риски проблемы файловой системы сведены к нулю, то у тебя вообще голова не должна болеть про это, хоть на MSSQL, хоть на Postgre, хоть на MySQL прости господи.

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

На MS SQL, когда еще в сотовой связи работал, налетели на баг sql. Сломалась мастер-база биллинга. Чинили ее специалисты с европейского центра техподдержки

Ну так если у вас всё серьёзно и без колхоза — риски проблемы файловой системы сведены к нулю, то у тебя вообще голова не должна болеть про это, хоть на MSSQL, хоть на Postgre, хоть на MySQL прости господи.

у меня даже есть пару серваков с ubuntu 10 и postgres 8.4 и ничё работает до сих пор

так что, все бд могут сломаться, будь это мускул, пг, оракл, скл

у меня даже есть пару серваков с ubuntu 10 и postgres 8.4 и ничё работает до сих пор

??

работает - не трогаешь? ?

оффтопик: а случаем никто не знает как можно узнать результат выполнения azure storage upload / download ?

помимо того что парсить результат

работает - не трогаешь? ?

ну да.

Есть кто с pgloader на "ты"?

Как pgloader сказать - не дропай типы которые есть и создавай типы которых нет? И почему оно не найдя тип который надо создать - останавливается?

хочу удалить записи с таймштампами out of range, их всего 192тыс: delete from comments where date > '1 Jan 9999' or date < '1 Jan 2000' or date_found > '1 Jan 9999' or date_found < '1 Jan 2000', но вот такую ошибку выдает: ERROR: attempted to delete invisible tuple. Как вообще тупл может быть невидимым? Сделал pg_resetxlog -D /datadir - не помогло

гугл выдает куски всяких мейлинг листов, я их читать не умею ?

а триггеров нет на таблице comments?

неа

http://postgresql.nabble.com/ERROR-attempted-to-delete-invisible-tuple-td1918888.html

http://postgresql.nabble.com/ERROR-attempted-to-delete-invisible-tuple-td1918888.html

угу, этот тред тоже читаю, но непоняно что сделал ОП, что у него получилось их удалить: Wow, how crazy is that. I was just able to delete those three records. I tried the remaining, and two were left that I could delete. Waited 30 seconds, tried again and now they're gone as well. As far as I'm aware, that's all the bad records in that table.

он удалил те, с которыми были проблемы

подождал видимо вакуума и попробовал удалить все

какая версия?

вижу

подождал видимо вакуума и попробовал удалить все

просто автовакума? я знаю что у меня места не хватает для vacuum full, поэтому и хочу сдампить на 8ТБ хдд и загрузить снова

это я pgdata перенес с умершего сервера, и запустил новый с ней же после реинсталляции

другая транзакция может в то же время пытаться поменять данные?

ERROR: S client not available

в версии 955 https://www.postgresql.org/docs/9.5/static/release-9-5-5.html убирается один баг с появлением attempted to delete invisible tuple

(9.5.5) Fix deletion of speculatively inserted TOAST tuples when backing out of INSERT ... ON CONFLICT (Oskari Saarenmaa) In the race condition where two transactions try to insert conflicting tuples at about the same time, the loser would fail with an "attempted to delete invisible tuple" error if its insertion included any TOAST'ed fields.

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

другая транзакция может в то же время пытаться поменять данные?

сервер ничего не обслуживает сейчас, только мои квери. он правда при старде запускает autovacuum launcher

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

просто сделать vacuum comments; и посмотреть что будет?

сколько раз его запускаешь, те же ошибки на тех же блоках

наверное индексы следует дропнуть?

индекс пересоздайте

а просто REINDEX DATABASE dbname не то же самое что пересоздать?

просто конкретный индекс пересоздать быстрее

сколько бд то весит?

3,9 TB

а так, да на битой бд стоит все индексы пересобрать

это долго

давай конкретный индекс и двигаться дальше

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

лучше то лучше

только вот как индекс пересоздастся, если некоторые данные битые, например timestamps out of range?

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

а ок

и какие значения xmin, xmax,ctid по проблемным записям

может лучше удалить индекс совсем и полечить табличку

если бд никто не пользует, то можно и удалить

угу, удалю тогда

вот бы какой однострочник, чтоб делал это сам

что делал?

пересоздавал индексы например

ну или утилиту, чтоб умела чистать таблицы от всяких странностей после краша

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

ок, дропнул все индексы кроме pkey, пошло дальше обнулять пейджи

вот