@pgsql
Петр14.12.2016
16:54:52
16:54:52
SELECT ctid, column1...,columnN from comments where ctid='(92815,25)';
SELECT ctid, column1...,columnN from comments where ctid='(92815,26)';
падает?
blkmrkt14.12.2016
16:55:39
16:55:39
SELECT ctid, column1...,columnN from comments where ctid='(92815,25)';
SELECT ctid, column1...,columnN from comments where ctid='(92815,26)';
падает?
в первом 1 результат, во втором 0. не падаетПетр14.12.2016
16:56:16
16:56:16
тогда проверим что эта страница в первом
GoogleПетр14.12.2016
16:56:40
16:56:40
dd if=/var/lib/postgresql/9.5/main/base/16385/16443 bs=8192 skip=92815 count=1 | hexdump -C | less
Stanislav14.12.2016
16:57:02
16:57:02
Всем привет, кто-нибудь пользовался pg_compact или pg_repack?
Насколько их безопасно запускать на рабочей базе с живыми асинхронными репликами?
На 9.4 получил несколько сотен повисших навсегда INSERT'ов на репакнутой таблице.Петр14.12.2016
16:57:03
16:57:03
посмотри все записи, там есть та строка последняя, на которой упало?
blkmrkt14.12.2016
16:59:02
16:59:02
blkmrkt14.12.2016
17:00:11
17:00:11
а когда крашнулся мой запрос, в psql вывалилась последняя неполная строчка с битыми данными, или предыдущая?
ctid был тот, на котором квери по ctid крашнулась
Петр14.12.2016
17:01:33
17:01:33
Ты ту страницу и смотришь, последняя строка, которая тебе выдалась в той странице
blkmrkt14.12.2016
17:02:00
17:02:00
да, оно
Петр14.12.2016
17:02:11
17:02:11
Клево
blkmrkt14.12.2016
17:02:20
17:02:20
интересно то как
Петр14.12.2016
17:02:23
17:02:23
Давай затирать ее
Googleblkmrkt14.12.2016
17:02:29
17:02:29
с dd просто?
Петр14.12.2016
17:03:07
17:03:07
ну да, пг выключи, сделай копию этого файла /var/lib/postgresql/9.5/main/base/16385/16443 (на всякий случай)
dd if=/dev/zero of=/var/lib/postgresql/9.5/main/base/16385/16443 bs=8192 seek=92815 count=1 conv=notrunc
blkmrkt14.12.2016
17:04:47
17:04:47
done. запускать сервер?
Петр14.12.2016
17:04:59
17:04:59
да
и попробуй заново прошерстить тем же макаром, на чем упадет, на другой странице должен
blkmrkt14.12.2016
17:05:45
17:05:45
ok
blkmrkt14.12.2016
17:06:01
17:06:01
a
Петр14.12.2016
17:06:21
17:06:21
это на запрос select ctid, * from comments where ctid='(92816,3)':
у тебя же и на следующей странице тоже падало?
blkmrkt14.12.2016
17:06:57
17:06:57
неа, только на той
blkmrkt14.12.2016
17:07:19
17:07:19
это на запрос select ctid, * from comments where ctid='(92816,3)':
MultiXactId 3036690260 does no longer exist — apparent wraparoundПетр14.12.2016
17:07:27
17:07:27
на следующей тоже падало
blkmrkt14.12.2016
17:07:35
17:07:35
да точно
Петр14.12.2016
17:07:40
17:07:40
давай, ее тоже затри
не забудь пг выключить
dd if=/dev/zero of=/var/lib/postgresql/9.5/main/base/16385/16443 bs=8192 seek=92816 count=1 conv=notrunc
а потом шерсти по новой, по идее 92815 92816 страницы должно пролетать
Googleblkmrkt14.12.2016
17:08:28
17:08:28
ok done
Петр14.12.2016
17:08:57
17:08:57
а покажи
dd if=/var/lib/postgresql/9.5/main/base/16385/16443 bs=8192 skip=92816 count=1 | hexdump -C | less
да, норм
должно их пролетать
вот таким макаром попробуй вычистить
не знаю, на сколько активно пользовалась эта таблица, может получится вручную зачистить все страницы
blkmrkt14.12.2016
17:10:49
17:10:49
кстати тот первый файл который затирали, он выглядел обрезанным - текст комментария обрывался впритык к концу файла
Петр14.12.2016
17:11:19
17:11:19
не понял
blkmrkt14.12.2016
17:11:22
17:11:22
оно похоже зависло во время VACUUM FULL;
Петр14.12.2016
17:11:29
17:11:29
ты имеешь ввиду страницу или файл?
Петр14.12.2016
17:12:10
17:12:10
ну это страница, а не файл)
blkmrkt14.12.2016
17:12:26
17:12:26
ох точно. страницы по 8192 байта?
Петр14.12.2016
17:12:45
17:12:45
да
blkmrkt14.12.2016
17:13:01
17:13:01
аа, мы не весь файл обнулили получается, ок
Петр14.12.2016
17:13:40
17:13:40
конечно, тебе данные не нужны чтоли?))
только битую страницу затерли
по идее
ладно, давай пошерсти еще раз таблицу
можешь начать с ctid (92815,1)
blkmrkt14.12.2016
17:13:56
17:13:56
а точно не существует утилиты для автоматизации этого безобразия?
blkmrkt14.12.2016
17:15:00
17:15:00
ok
Googleblkmrkt14.12.2016
17:15:21
17:15:21
упало на (92814,45) теперь
Петр14.12.2016
17:15:56
17:15:56
как так?
blkmrkt14.12.2016
17:16:06
17:16:06
эээ не знаю
blkmrkt14.12.2016
17:16:35
17:16:35
то же самое, timestamp out of range
Петр14.12.2016
17:17:20
17:17:20
select ctid, * from comments where ctid='(92816,3)'
вот это падает?
blkmrkt14.12.2016
17:17:44
17:17:44
Петр14.12.2016
17:17:55
17:17:55
ну значит зачищено, до этого падало)
AdminERROR: S client not available
Петр14.12.2016
17:18:13
17:18:13
в общем чисти таким макаром дальше
я откланиваюсь на этом
blkmrkt14.12.2016
17:18:31
17:18:31
blkmrkt14.12.2016
17:21:21
17:21:21
https://www.postgresql.org/docs/9.5/static/ddl-system-columns.html вот тут описание колонок
Петр14.12.2016
17:21:27
17:21:27
надо перечитать
Googleblkmrkt14.12.2016
17:22:24
17:22:24
получается что 92814 это имя файла, а 45 это номер страницы?
то есть чтоб узнать какой оффсет задавать dd для заполнения нулями, нужно умножить 92814 на блоксайз? там с 0 или с 1 нумерация страниц?а ок все, не буду мучать, нашел где почитать
вон сколько пейджей уже обнулил
92816
92814
92813
92812
92811
92812
92810
92809
92808
92807
Петр14.12.2016
19:06:06
19:06:06
Напиши скрипт
blkmrkt14.12.2016
19:06:21
19:06:21
хочу написать утилиту для этого, но хочу сперва узнать: почему нужно постгрес перезапускать? можно без перезапуска обойтись?
\set FETCH_COUNT 1
\pset pager off
select ctid,colmn1,...,columnN from comments;
и там были какие-то загадочные командыПетр14.12.2016
19:07:08
19:07:08
Можно, если пг файл не держит/модифицирует, но лучше так не делать
Это не загадочные команды, просто вытаскивает по одной, и отключает пейджер, чтобы ты после каждой страницы кнопочку не нажимал
)
Попробуй скриптом сперва выявить все битые страницы, после затрешь
blkmrkt14.12.2016
19:13:26
19:13:26
Попробуй скриптом сперва выявить все битые страницы, после затрешь
да так наверное проще. а каким образом можно скипать эти битые страницы? WHERE ctid NOT IN (...)?Петр14.12.2016
19:13:55
19:13:55
Например
blkmrkt14.12.2016
19:14:22
19:14:22
или может как-то узнать ctid min и max, и уже в рендже дергать записи
Петр14.12.2016
19:14:26
19:14:26
Но тебе нужно выявить битые сначала
Да можешь по диапазонам проверять по 10000 например, как удобнее, так и делай
blkmrkt14.12.2016
19:18:18
19:18:18
А тогда все понятно. Странно что в so/dba никто не ответил, вроде нормальное решение
Правда совсем неочевидно если не знаком с устройством движка
Петр14.12.2016
19:26:12
19:26:12
Ты сейчас какую страницу последнюю затер?
вон сколько пейджей уже обнулил
92816
92814
92813
92812
92811
92812
92810
92809
92808
92807
Проверь, все ли строки 92805 читаются, что-то подозрительно, не партачится ли там предыдущая страница
Открыть в Telegram