Size: a a a

pgsql – PostgreSQL

2021 February 08

YS

Yaroslav Schekin in pgsql – PostgreSQL
Sergey Kletsov
Она по факту пытается восстановить базу ? Поврежденные файлы
Что он делает по факту, нужно посмотреть в логах, прочитав в них всё с начала запуска.
Вы нашли, где это?
источник

SG

Sergey Gr in pgsql – PostgreSQL
Sergey Kletsov
уже час
А процессы postgres'а есть?
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
blkmrkt
Не, просто постгрес и большинство реляционных бд так устроены что пишут сначала WAL файлы и регулярно делают чекпоинты, записывая эти WAL поверх реальных блоков данных на диске. Если жестко убить постмастер с долгоживущими трансакциями, то проигрывание всех WAL с момента последнего чекпоинта может занять много часов.
> убить постмастер с долгоживущими трансакциями,

Долгоживущие или нет — неважно.
Важно только время (объём записи, на самом деле) с последнего checkpoint.
Для того-то и существуют все эти настройки checkpoint_timeout и max_wal_size — чтобы время recovery ограничить.
источник

b

blkmrkt in pgsql – PostgreSQL
полные версии PostgreSQL там и там какие?

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

>Да что он вообще может знать о процессах postgres?! 😉
>И я серьёзно, между прочим — запись в WAL такой процесс будет стараться откладывать — "за него" её почти наверняка будет выполнять что-то другое (тот backend, который делает свой commit); а запись в базу — checkpointer (на который Вы и видите жалобы в логах).

Да уж, я слышал что iotop нельзя использовать для мониторинга постгреса, ну вот что было)

pg_waldump показывает сплошь записи rmgr: Btree, это обновления индекса? Что-то в доках нет описания этих колонок которые эта утилита пишет...
источник

b

blkmrkt in pgsql – PostgreSQL
Yaroslav Schekin
> убить постмастер с долгоживущими трансакциями,

Долгоживущие или нет — неважно.
Важно только время (объём записи, на самом деле) с последнего checkpoint.
Для того-то и существуют все эти настройки checkpoint_timeout и max_wal_size — чтобы время recovery ограничить.
👍
источник

b

blkmrkt in pgsql – PostgreSQL
blkmrkt
полные версии PostgreSQL там и там какие?

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

>Да что он вообще может знать о процессах postgres?! 😉
>И я серьёзно, между прочим — запись в WAL такой процесс будет стараться откладывать — "за него" её почти наверняка будет выполнять что-то другое (тот backend, который делает свой commit); а запись в базу — checkpointer (на который Вы и видите жалобы в логах).

Да уж, я слышал что iotop нельзя использовать для мониторинга постгреса, ну вот что было)

pg_waldump показывает сплошь записи rmgr: Btree, это обновления индекса? Что-то в доках нет описания этих колонок которые эта утилита пишет...
Еще флаг --follow не дает никакого эффекта 🙁
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
blkmrkt
полные версии PostgreSQL там и там какие?

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

>Да что он вообще может знать о процессах postgres?! 😉
>И я серьёзно, между прочим — запись в WAL такой процесс будет стараться откладывать — "за него" её почти наверняка будет выполнять что-то другое (тот backend, который делает свой commit); а запись в базу — checkpointer (на который Вы и видите жалобы в логах).

Да уж, я слышал что iotop нельзя использовать для мониторинга постгреса, ну вот что было)

pg_waldump показывает сплошь записи rmgr: Btree, это обновления индекса? Что-то в доках нет описания этих колонок которые эта утилита пишет...
> 12.5, апгрейднулся вот ровно неделю назад.

Т.е. неизвестные bugs в логической репликации ни при чём, хотя бы. ;)

> У меня еще archive_command была пустая, поэтому постгрес держал валы аж с нового года.

И на источнике, и на приёмнике?

> Я ее поставил на true позавчера

И с тех пор всё нормализовалось? Кстати, почему бы не отключить архивирование, если оно не нужно (или уж, наоборот, настроить — что это Вы без архива живёте? ;) ).

> записи rmgr: Btree, это обновления индекса?

Да. И там вроде должны быть OID-ы, по которым можно найти, что это за индекс.
И да, описания нет — исходники придётся смотреть, если интересует подробно... но и это и не нужно, обычно.
источник

b

blkmrkt in pgsql – PostgreSQL
>И на источнике, и на приёмнике?

Только на приемнике (наверное тк репликация логическая). На мастере я бы это моментально узнал.

>И с тех пор всё нормализовалось? Кстати, почему бы не отключить архивирование, если оно не нужно (или уж, наоборот, настроить — что это Вы без архива живёте? 😉 ).

Да, постгрес тогда почистил все эти WALы. Вообще я заметил что они не удалялись рефрешнув публикацию, тк отжор диска начал расти намного быстрее (красивый график на пике).

Конфиг с archive_mode приплелся с мастера, где я его тоже отключил) Я экспериментировал с архивом в S3, но S3 оказался слишком медленным а команда слишком синхронной чтоб успевать за количеством этих файлов)
источник

b

blkmrkt in pgsql – PostgreSQL
что-то ни один из этих интов не кастится в текстовое имя объекта с oid::regclass...
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
blkmrkt
Еще флаг --follow не дает никакого эффекта 🙁
Не в тот WAL попали, например (в тот, что уже был ротирован).
С высокой скоростью записи, даже если предварительно смотреть в postgres (pg_current_wal_lsn() и т.п.) и то можно промахнуться. ;)
источник

b

blkmrkt in pgsql – PostgreSQL
Yaroslav Schekin
Не в тот WAL попали, например (в тот, что уже был ротирован).
С высокой скоростью записи, даже если предварительно смотреть в postgres (pg_current_wal_lsn() и т.п.) и то можно промахнуться. ;)
Ааа, понятно! Этих 16-мб валов там по 20шт в минуту
источник

YS

Yaroslav Schekin in pgsql – PostgreSQL
blkmrkt
что-то ни один из этих интов не кастится в текстовое имя объекта с oid::regclass...
То, что после rel — база/файл/блок, кажется (не помню точно).
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
> записи rmgr: Btree, это обновления индекса?

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

AL

Alexey Lesovsky in pgsql – PostgreSQL
посмотрите top -p $PID процесса которые заливает данные
источник

b

blkmrkt in pgsql – PostgreSQL
Yaroslav Schekin
То, что после rel — база/файл/блок, кажется (не помню точно).
Ох блин, копирую я таблицу email_address, и оказывается что оно обновляет индекс ix_email_address_domain_id! Разве COPY это должен делать? Или оно COPY только на стороне отправителя, а на логическую реплику оно прилетает в виде единичных операций внутри гигантской трансакции?
источник

ВК

Влад Казаков... in pgsql – PostgreSQL
NIKITA POLETIN
Ребят, заранее извиняюсь за глупый вопрос, но через гугл никак не выходит. как на linux (Ferdora 30) установить postgresql-dev ? сам постгресс стоит, но я не могу сообразить как поставить вот эту... сущность. И разве она не входит в основной пакет posrgress?
Во-первых, Fedora 30 out of support, рекомендую обновиться до 33
Во-вторых, не знаю, что вам конкретно нужно, но есть пакет postgresql-server-devel
В-третьих, обычно -devel отделяется от основного пакета
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
источник

b

blkmrkt in pgsql – PostgreSQL
Alexey Lesovsky
> записи rmgr: Btree, это обновления индекса?

кстати сколько там индексов на таблице? может процесс рестора просто упирается в CPU на создании индексов?
Так оно наверное и есть 🙁
источник

NP

NIKITA POLETIN in pgsql – PostgreSQL
Влад Казаков
Во-первых, Fedora 30 out of support, рекомендую обновиться до 33
Во-вторых, не знаю, что вам конкретно нужно, но есть пакет postgresql-server-devel
В-третьих, обычно -devel отделяется от основного пакета
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_devel_packages
Да, я вчера с горем пополам разобрался, спасибо большое за ответ
источник

b

blkmrkt in pgsql – PostgreSQL
Alexey Lesovsky
посмотрите top -p $PID процесса которые заливает данные
Точно так и есть, 90%-96% отъедает процесс для этой таблицы. Это не может быть IOWAIT если это logical replication worker?
источник

AL

Alexey Lesovsky in pgsql – PostgreSQL
blkmrkt
Точно так и есть, 90%-96% отъедает процесс для этой таблицы. Это не может быть IOWAIT если это logical replication worker?
посмотрите через pidstat -u -p $PID, там будет per-process распределение утилизации проца, там будет видно iowait или что другое
источник