так это же просто праздник какой-то. серьёзно?

так это же просто праздник какой-то. серьёзно?

ну проверьте сами :)

/usr/lib/postgresql/9.6/bin/initdb -D main -k /usr/lib/postgresql/9.6/bin/pgbench -i -s 100 postgres=# select count(*) from pgbench_accounts; count —------— 10000000 (1 row) postgres=# \q postgres@ubuntu:~/9.6$ rm -f main/base/12439/16396.1 postgres@ubuntu:~/9.6$ psql psql (9.6.4) Type "help" for help. postgres=# select count(*) from pgbench_accounts; count —------- 7995392 (1 row) postgres=#

Чексуммы несуществующих блоков всегда верны ) И нулевых тоже кстати. Проблемы ФС оно конечно не решит, но обычно файлы так не исчезают. Они только портятся.

Чексуммы несуществующих блоков всегда верны ) И нулевых тоже кстати. Проблемы ФС оно конечно не решит, но обычно файлы так не исчезают. Они только портятся.

можно транкейтнуть

обнулить. xfs так поступает

/usr/lib/postgresql/9.6/bin/initdb -D main -k /usr/lib/postgresql/9.6/bin/pgbench -i -s 100 postgres=# select count(*) from pgbench_accounts; count —------— 10000000 (1 row) postgres=# \q postgres@ubuntu:~/9.6$ rm -f main/base/12439/16396.1 postgres@ubuntu:~/9.6$ psql psql (9.6.4) Type "help" for help. postgres=# select count(*) from pgbench_accounts; count —------- 7995392 (1 row) postgres=#

а вы перед селектом рестартили БД?

postgres=# select count(*) from pgbench_accounts; count —------— 10000000 (1 row) postgres=# select pg_relation_filepath('pgbench_accounts'); pg_relation_filepath —------------------— base/12439/16415 (1 row) postgres=# \q postgres@ubuntu:~/9.6$ rm -f main/base/12439/16415 16415 16415.1 16415_fsm 16415_vm postgres@ubuntu:~/9.6$ > main/base/12439/16415.1 postgres@ubuntu:~/9.6$ psql psql (9.6.4) Type "help" for help. postgres=# select count(*) from pgbench_accounts; count —------- 7995392 (1 row) postgres=#

> main/base/12439/16415.1

обнуление файла на самом деле равносильно его удалению

pg просто прошупывает eof

Т.к. если не перезапускать БД в памяти останутся ваши правильные не тронутые блоки данных.

это если shb хватит

у меня в данном случае немного

это если shb хватит

ну для тестов указанных выше хватает.

не важно, представьте что после ребута ваш pg ничего не скажет про то что вы проебали данные

и насрать на чексуммы или еще что-то

а если вы надетесть на то что с shb он скинет в wal что-то то вас тут тоже можно огорчить

не важно, представьте что после ребута ваш pg ничего не скажет про то что вы проебали данные

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

если в wal есть запись о том что есть смещение на 1000k блоков

и таких файлов нет

pg просто забьет нулями

все 1000k-1 блоков

и ничего вам не скажет

Ну допустим тот же oracle тоже ничего не скажет - пока читать corrupted блок не будете

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

Ну допустим тот же oracle тоже ничего не скажет - пока читать corrupted блок не будете

ну и правильно, и не должен

а тут сраных 5 файлов для старта надо

это-то понятно. но я вот не могу представить, как с mysql повторить такой же трюк, как выше с pgbench

Он орет благим матом, если версии датафайлов различаются, а вот на запись пары байт hex редактором - ничего не скажет

Он орет благим матом, если версии датафайлов различаются, а вот на запись пары байт hex редактором - ничего не скажет

имеешь ввиду время изменения файла?

Нет, там есть еще метка типа xid...

Оракл будет крыть вас матом на контрол файлы, на битые undo и redo, но вот повреждения в блоках данных заметит только при чтении

Правда там достаточно развита обвязка - системные таблицы и вьюхи которые позволяют понять какие именно записи повреждены и даже как-то пофиксить это

что в общем логично. чтобы повреждения в данных заметить, надо на данные посмотреть для начала

что в общем логично. чтобы повреждения в данных заметить, надо на данные посмотреть для начала

Я согласен. Я скорее про то, что нет совершенного инструмента пока )

на pgday рассказывали как обновляются с pglogical. Поднимают логическую реплику, догоняются и включают ее как основной сервер. Сам не пробовал, но вроде как должен быть минимальный даунтайм

Обновляли через pglogical, добавив новую ноду с логической репликацией в балансировщик, кстати PGPool прекрасно понимает логическую репликацию.

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

По поводу Segmentation fault Постгреса в проде:

Потестил те же самые запросы на деве, всё ок. Ничего не падает.

Но конфиги полностью одинаковые,!

В связи с этим есть следующий вопрос:

Параметр dynamic_shared_memory_type есть смысл сменить с posix на sysv ?

а трейс в gdb пробовали смотреть?

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

А можно мануал как юзать gdb, для тех кто из деревни :)

А можно мануал как юзать gdb, для тех кто из деревни :)

https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD

Спасибо!

господа, а как соотносятся команды pg_archivecleanup и pg_basebackup ?

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

а почему ты решил, что они соотносятся?

не знаю. хотел бы что бы соотносились :)

как то хочется удалять валы

https://www.postgresql.org/docs/9.6/static/pgarchivecleanup.html

кажется, документация достаточно понятно написана

увы. она написано недостаточно понятно.

pg_archivecleanup дёргает сам постгрес в recovery, когда отыграет вал

получается что клинап немного бесполезен при бекапе через pg_basebackup со слейва. на мастере почистить вал не получится. и надо что то придумывать. сейчас я вижу что в backup_label есть указание на файл который последний. но этого файла еще нету в архиве.

получается что клинап немного бесполезен при бекапе через pg_basebackup со слейва. на мастере почистить вал не получится. и надо что то придумывать. сейчас я вижу что в backup_label есть указание на файл который последний. но этого файла еще нету в архиве.

Ты backup manager изобретаешь? Не проще ли взять готовый профессиональный инструмент?

я не хочу ничего изобретать. просто пытаюсь собрат ьвсе в кучу.

получается фигово и стремно.

для ha есть patroni. и он сделал так что ha работает.

в доке патрони есть упомнимание про wal-e

что ты хочешь чистить

ERROR: S client not available

ответь себе на этот вопрос

я хочу чистить примененные валы

в каком случае ?

настрой barman, например

в каком случае ?

после сделанного бекапа.

настрой barman, например

почему именно его ?

чем плох бекап через basebackup?

Ты backup manager изобретаешь? Не проще ли взять готовый профессиональный инструмент?

Поделитесь пожалуйста опытом. Про какой профессиональный инструмент идёт речь?

чем плох бекап через basebackup?

Ни кто не валидирует бакап

Уже писали выше

чем плох бекап через basebackup?

Хорош скоростью развертывания, плох размером - при большом количестве индексов - его объем в разы больше дампа

у меня база 5 гигов.

мне не жалко.

У меня базы 100 GB - 1 TB. Тут уже есть на чем экономить )

тогда pgbackrest он жмет

мне не надо жать. у мен ядедублицирующая схд под бекап.

мне только удалять валы.

мне не надо жать. у мен ядедублицирующая схд под бекап.

Навряд ли это работает

что мешает вам удалить валы?

как понять какие можно удалить ?

1) глянуть где сейчас находится стендбай

2) посмотреть .backup

2) посмотреть .backup

у меня нет этих файлов.

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

они создаются после pg_start_backup

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

slave# su - postgres -c "psql -c \"select pg_start_backup('test')\"" ERROR: recovery is in progress HINT: WAL control functions cannot be executed during recovery.

чем плох бекап через basebackup?

barman и другие managers делают его через basebackup

на примари смотрите pg_xlogfile_name()

так опять скриптами запахло и ssh с ноды на ноду

бэкап без скриптов выполняется у вас?