неплохой подход

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

а только инкремент делать

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

если запрос не сделать - не узнаешь закораптилось или нет по сути

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

чексуммы как раз для этого

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

Мы юзали Solaris + ZFS. Если были карапченные блоки zfs автоматически востановит с другой половины зеркала. + хорошее маштабирование + снапшоты + моментальное создание бизнес копий для отчетности

vacuum откатит транзакцию

как это откатит?

а есть какойнить maintance который позволяет просто проверить?

Мы юзали Solaris + ZFS. Если были карапченные блоки zfs автоматически востановит с другой половины зеркала. + хорошее маштабирование + снапшоты + моментальное создание бизнес копий для отчетности

ох уж этот зфс

а есть какойнить maintance который позволяет просто проверить?

pg_dump >/dev/null

а чтото полегче?

pg_dump >/dev/null

А восстанавливать как потом?

А восстанавливать как потом?

если ошибка есть? не знаю

с дампа)

из /dev/null ))

кстати коллеги, код версионируете каким-либо образом?

это просто проверка, ты просил проверку

из /dev/null ))

Только так

Не понял, pg dump all в формат скрипта снимает дамп, в нем нет чексумм, нет страниц данных, есть скрипт, чексумма проверяется в момент чтения страниц для создания скрипта дампа, но на кластере без чексумм не будет считаться

Да, это меня и интересовало.

чексуммы нужны для того, чтобы не получить базу Шрёдингера - когда она работает, а бекап/дамп снять с нее уже нельзя, т.к. на файловой системе часть данных скорраптилась из-за сбоя СХД

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

я говорю про аналог https://msdn.microsoft.com/en-us/library/ms176064.aspx

в пг

есть чтото такое?

кстати pg_dump может в архивный формат, не скрипт а pg_dumpall похоже не умеет для pg_restore

есть чтото такое?

нету

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

кстати pg_dump может в архивный формат, не скрипт а pg_dumpall похоже не умеет для pg_restore

Если верить документации, pg_dampall последовательно вызывает Pg_dump для каждой базы и формирует в итоге общий скрипт для воссоздания данных.

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

физической целостности? В Смысле? pg_dump не сможет снять дамп если повреждена страница.

Если верить документации, pg_dampall последовательно вызывает Pg_dump для каждой базы и формирует в итоге общий скрипт для воссоздания данных.

ага, и у pg_dumpall нет параметры -f - format, значит только в одном формате скрипта дампит, может это связано с тем, что pg_restore Не умеет весь кластер поднимать, нету типо pg_restoreall

pg_restoreall можно небольшим скриптом реализовать, если нужно

физической целостности? В Смысле? pg_dump не сможет снять дамп если повреждена страница.

не уверен, думаю сможет, но данные будут некорректны, а о том что они некорректны даже не скажет, а с checksumm - скажет

хотя может зависит от того какая страница повреждена, данных или просто индекса

не уверен, думаю сможет, но данные будут некорректны, а о том что они некорректны даже не скажет, а с checksumm - скажет

Выше описал ситуацию. Сдампить данные не дал.

pg_restoreall можно небольшим скриптом реализовать, если нужно

там же простое перенаправление из файла в psql для рестора.

а форматы "custom" (-Fc) и "directory" (-Fd)

это же не sql скрипт, а блоки данных насколько я понимаю, поэтому их через pg_restore, а не psql поднимать

Выше описал ситуацию. Сдампить данные не дал.

понятно, просто не совсем понятно, если и безчексумм показывается ошибка, то зачем чексумм), но именно для проверки валидности данных нужно

Добрый день. Запускаю pg_dump. Сначала для одной базы, потом для другой. Для одной выходит некоторая ошибка связанная с тем что база порушена, дамп второй отрабатывает хорошо. Далее запускаю команды еще раз. И ловлю следующие сообщения - pg_dump: Не удалось подключиться к базе. ВАЖНО: система баз данных в режиме восстановления. Не удалось подключиться к базе template1. ВАЖНО: система баз данных в режиме восстановления. И так далее. Через некоторое время повторный запуск команд pg_dump опять отрабатывает без этих сообщений. Если база переходит в режим восстановления - то сколько он может длиться и возможна ли работа пользователей в это время?

Поздравляю, у тебя порушились некоторые данные в БД.

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

Иначе тебе нужен dba который может восстановить данные из порушенной БД.

Сам недавно с этим возился. И сделал именно рестор бекапов в новый кластер. Т.к. сервис рушился при обращении к поврежденным данным.

я в курсе что они порушились. я ковыряюсь на копии порушенных данных. Все что тогда упало уже восстановил на продакшене из бэкапа.

А они тебе нужны?

Меня не данные интересуют на данный момент. А разница в поведении. Почему в один момент при одних и тех де условиях процесс серверный не падает при доступе к битым данным, а в другой - падает.

а чем сделать конверт дампа mysql -> psql ?

нашел какой то db_converter.py но работает с ошибками

и ролбэк в конце

Меня не данные интересуют на данный момент. А разница в поведении. Почему в один момент при одних и тех де условиях процесс серверный не падает при доступе к битым данным, а в другой - падает.

К сожалению мои познания в БД не велики для этого.

вот этим делаю https://github.com/lanyrd/mysql-postgresql-converter

отрабатывает с ошибками

дамплю по инструкции

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

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

checkpoint. но от ошибки в коде никто не застрахован. я в такой ситуации никогда не терял данные.

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

перед именем таблицы имя схемы нельзя поставить?

неа, он в кавычки оборачивает все

а существующие редактирует вот так

https://telegram.me/joinchat/BBjpEgawWIWOj6AQrH6wZA

дайте еще раз сылку

Запрос таки быстрее написать

минутку

https://youtrack.jetbrains.com/issue/DBE-2441 https://youtrack.jetbrains.com/issue/DBE-2440

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

запрос надежнее

А зачем ? Это же дольше. Проще написать

https://telegram.me/PostgreSQL_1C_Linux

ну это уже философский вопрос из серии зачем вообще IDE если можно запросы писать на все :)

так в самом поле с именем таблицы, нельзя имя схемы написать?

так в самом поле с именем таблицы, нельзя имя схемы написать?

неа

Я как всегда со странными абстракными вопросами.... Можно ли как-то оптимизировать Sort ???

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

а что за данные, префиксной сортировкой в новом постгресе сортируются?

добро пожаловать! :)

я тут добрался до раздатки с PGDay, а там обнаружился журнал linux format, в котором рассказывают, как сделать блог на MongoDB

диверсия =)

И еще вопрос нашел в логах вот такое: ERROR: could not read block ... Достаточно будет остановить постгрес релоцировать файлики и запустить снова ?

На выборках из таблицы вроде не ругается

диверсия =)

там дальше просто статья "Итак, ваш блог на монге упал и вы хотите мигрировать на пг..."

))

Всем привет. У кого есть опыт использования pgcrypto (pgp_pub_encrypt, pgp_pub_encrypt)? как будет строитьяс индекс по шифрованным полям ?

Интересный вопрос

а чем сделать конверт дампа mysql -> psql ?

Попробуй pgloader

Мне понравилось

правильно понимаю что ни у кого нет такого опыта ?

Видимо так

правильно понимаю что ни у кого нет такого опыта ?

Опыта нет. Насколько я помню из доклада на pg_day, про сортировку/индексы фактически можно забыть. Презенташка с доклада http://pgday.ru/files/papers/60/Using%20Crypto%20in%20RDBMS.pptx

спасибо, щас буду пробывать на большой таблице

make clean

ppl, заранее приношу извинения за баян. кто как лечит «ERROR: could not serialize access due to concurrent update»?