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

во всяком случае халявным способом без чтения вала :) так что проще прочитать страницу несколько раз пока не получишь валидную.

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

Я конечно не специалист, но как можно считать битую страницу из файла? Только если она уже не испорчена и её просто сам postgres ещё не считывал чтобы ругнуться при проверке чексумм.

Я конечно не специалист, но как можно считать битую страницу из файла? Только если она уже не испорчена и её просто сам postgres ещё не считывал чтобы ругнуться при проверке чексумм.

race condition

нету никаких гарантий на "атомичность" записи и чтения из файла

это всё упирается в буфера в VFS

это всё упирается в буфера в VFS

И снова fsync?

И снова fsync?

fsync он только для диска

и его ещё надо успеть запустить :)

Ну вот ?. Значит эту фичу нельзя использовать даже на wal-g? Вроде как его яндекс использует.

Проблема не имманента какому-то конкретному режиму бэкапа. Проблема в следующем: считываем страницу из файла и пытаемся провалидировать ее чексумму. Если она не сходится, то мы не можем однозначно сказать, коррапшен это или просто рваное чтение. pg_probackup в этой ситуации или пытается прочитать ее через буфер-менеджер(если постгрес собран с ptrack), гарантируя таким образом консистентное чтение, или пытается перечитать ее 100 раз. Если чексумма по-прежнему не сходится - падаем с ошибкой.

Проблема не имманента какому-то конкретному режиму бэкапа. Проблема в следующем: считываем страницу из файла и пытаемся провалидировать ее чексумму. Если она не сходится, то мы не можем однозначно сказать, коррапшен это или просто рваное чтение. pg_probackup в этой ситуации или пытается прочитать ее через буфер-менеджер(если постгрес собран с ptrack), гарантируя таким образом консистентное чтение, или пытается перечитать ее 100 раз. Если чексумма по-прежнему не сходится - падаем с ошибкой.

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

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

такого ключа нет, но запилить можно

такого ключа нет, но запилить можно

Ну да я знаю что его нет. Как раз про его создание писал. Просто сама идея нормально выглядит? Не бредово?

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

Хорошо. Осталось дождаться пока кто-то это напишет. )

Добрый день, подскажите, для использования утилиты pg_probackup обязательно включенные data-checksum в кластере?

Добрый день, подскажите, для использования утилиты pg_probackup обязательно включенные data-checksum в кластере?

Не обязательно, но крайне желательно

Не обязательно, но крайне желательно

только валы пухнут от этого

WAL-ы пухнут от чек-сумм?! Это как?

только валы пухнут от этого

Зато спать можно спокойно

WAL-ы пухнут от чек-сумм?! Это как?

Хинты форсируют пересчет чексуммы страницы

Зато спать можно спокойно

ну это да, но надо знать врага :)

Хинты форсируют пересчет чексуммы страницы

там ещё вроде чаще полные копии страниц начинают прилетать

Хинты форсируют пересчет чексуммы страницы

Аааа... понятно...

там ещё вроде чаще полные копии страниц начинают прилетать

Именно из-за хинтов

ну это да, но надо знать врага :)

Враг - это тот, кто инициализировал без чексумм

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

точнее именно балансеры

https://www.linux.org.ru/forum/talks/14156178

уже 5лямов

камрады добрый день, подскажите плиз настройку отвечаюющую сколько в планировщике рассматривать таблиц с left join? таблица c LEFT JOIN 10я по счету (получает в определнных случаях входящий фильр, по сути это же INNER JOIN) но планировщий не строит от нее запрос

join_collapse_limit но при его увеличении будет больше времени уходить на планирование

камрады добрый день, подскажите плиз настройку отвечаюющую сколько в планировщике рассматривать таблиц с left join? таблица c LEFT JOIN 10я по счету (получает в определнных случаях входящий фильр, по сути это же INNER JOIN) но планировщий не строит от нее запрос

А может запрос переписать всё же?

там ещё вроде чаще полные копии страниц начинают прилетать

а если включен full pages write, они и так ведь полные всегда прилетают?

А может запрос переписать всё же?

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

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

join_collapse_limit но при его увеличении будет больше времени уходить на планирование

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

менять не собираемся)

Grigory для того чтоб сделать FULL backup, надо вначале настроить achive_command в директорию wal ? А то у меня валится по arhive_timeout после такого сообщения INFO: Wait for WAL segment to be archived ERROR: Switched WAL segment 00000002000000AE00000009 could not be archived in 300 seconds

Есть кто из Екатеринбурга? https://events.yandex.ru/events/meetings/25-april-2018

Ребята, а можно сюда писать предложения по работе?

Судя по количеству забаненных сегодня IP желательно за границей

Ребята, а можно сюда писать предложения по работе?

Да, можно. Но без спама и вот этого всего. По сути

#работа #удаленно Нам в команду нужен опытный специалист. Нужно взять на себя всю работу по БД, начиная с администрирования, заканчивая поддержкой и постоянной доработкой бизнес логики (процедуры, триггеры, отчеты). Обязателен опыт построения бизнес процессов. Вилка: 1000р. - 1500р./ч., либо от 100к р. - 150к р./мес, удаленно.

Если что-то не так, можно удалить мое сообщение.

Если что-то не так, можно удалить мое сообщение.

Мы ж не роскомнадзор какой ))

Удалённо?)) А сервера на Амазоне?)

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

Grigory для того чтоб сделать FULL backup, надо вначале настроить achive_command в директорию wal ? А то у меня валится по arhive_timeout после такого сообщения INFO: Wait for WAL segment to be archived ERROR: Switched WAL segment 00000002000000AE00000009 could not be archived in 300 seconds

Ага, ну или использовать опцию --stream

Ага, ну или использовать опцию --stream

а если настраивать инкрементальный бэкап (PAGE), то архивирование wal обязательно?

а если настраивать инкрементальный бэкап (PAGE), то архивирование wal обязательно?

Да

Удалённо?)) А сервера на Амазоне?)

да

а если настраивать инкрементальный бэкап (PAGE), то архивирование wal обязательно?

В 2.0.17 появятся DELTA бэкапы и можно будет делать инкрементальные бэкапы без архива

в этом плане pgbarman попроще выходит, так как не требует руками ничего настраивать, кроме кредов к базе

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

Ну например, у нас есть процедура расчета задолженности. Нужно понимать что это и как считать.

в этом плане pgbarman попроще выходит, так как не требует руками ничего настраивать, кроме кредов к базе

+ PITR без проблем сразу работает

в этом плане pgbarman попроще выходит, так как не требует руками ничего настраивать, кроме кредов к базе

Ну там и инкрементальность на уровне файлов

+ PITR без проблем сразу работает

А как он работает без предварительной настройки архивирования? Bootstrap есть какой-то?

и все обернуто python скриптами

А, да, это где он тебе в кронтаб вкорячивает запуск pg_receivexlog каждую секунду

Н - надежность

уже 5лямов

20 же

А, да, это где он тебе в кронтаб вкорячивает запуск pg_receivexlog каждую секунду

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

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

Каждую минуту, приврал чутка

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

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

А не подерутся?

А не подерутся?

вот вот, думаю будут коллизии

или как то изварачиваться и монтировать на каждом инстансе в другую директорию и со standby удалять лишнее по скрипту или на подобии с barman сделать через pg_receivexlog

Может проще разрешить только мастеру писать в архив?

Может проще разрешить только мастеру писать в архив?

применение archive_command идет на всем кластере https://github.com/sorintlab/stolon/blob/master/doc/pitr.md archive_mode and the related archive_command will be enabled for all the instances (master and standbys). This is done to avoid losing some wals to backup when the current master keeper is down and a new master is elected. We suggest to define your archive command script to avoid backing up the same wal from all the instances (for example doing this only when the instance is the stolon master and just removing the wal when the instance is a stolon standby).

моя цель снимать бэкапы со standby

моя цель снимать бэкапы со standby

вам можно попробовать pgbackrest, но там всё равно мастер нужен

+ еще для применения настроек archive_command надо рестартовать мастер

вам можно попробовать pgbackrest, но там всё равно мастер нужен

я на конфе pgconf вдохновился этим докладом https://pgconf.ru/2018/110791 судя по цифрам, pg_probackup более выгодный

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

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

к сожалению я не нашел, только пару фоток сделал

моя цель снимать бэкапы со standby

а standby синхронный?

а standby синхронный?

Один синхронный, другой асинхронный

ну вот с синхронного как раз и пишите в архив

и с него же делайте бэкапы

Ребят, косвенно, но в тему БД Купил себе старенький Xeon И задумался Разгоняли ли его раньше в серваке, и занимаются ли такими вещами it-компании, ускоряя работу CPU ?)

Ребят, косвенно, но в тему БД Купил себе старенький Xeon И задумался Разгоняли ли его раньше в серваке, и занимаются ли такими вещами it-компании, ускоряя работу CPU ?)

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

Ребят, косвенно, но в тему БД Купил себе старенький Xeon И задумался Разгоняли ли его раньше в серваке, и занимаются ли такими вещами it-компании, ускоряя работу CPU ?)

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

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

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

Ну как не окупится Новый серв ставишь И сразу в шину +15% смело в биосе Если кондеи хорошие

учитывая стоимость того самого ксеона (в молодости) и выход его из строя по причине "прямых" рук - никто ни в жизни не будет такое делать

всем привет а кто нибудь видел где нибудь исходники pglupgrade ? которые описаны в этой презентации http://slides.com/apatheticmagpie/near-zero-downtime-postgres ?