Коллеги, всем доброй наступающей послепраздничной недели! Кому приходилось делать "догонялки базы" - чтобы из прода на тест быстро стащить только новые строки. При этом консистентность старых данных не важна - если что-то поменяли с строке со старыми данными, то и фиг с ним. Задача - приблизить к реальности тест на свежих данных. Что посоветуете?

А тупо дамп-рестор не катит?

Как вариант накатывать бекап pitr

Или логическая реплика.

А тупо дамп-рестор не катит?

Хотя мне самому это надоело.

Коллеги, всем доброй наступающей послепраздничной недели! Кому приходилось делать "догонялки базы" - чтобы из прода на тест быстро стащить только новые строки. При этом консистентность старых данных не важна - если что-то поменяли с строке со старыми данными, то и фиг с ним. Задача - приблизить к реальности тест на свежих данных. Что посоветуете?

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

Если во всех таблицах, есть общее поле, например, customer_id, тогда и простым \copy можно обойтись.

Коллеги, всем доброй наступающей послепраздничной недели! Кому приходилось делать "догонялки базы" - чтобы из прода на тест быстро стащить только новые строки. При этом консистентность старых данных не важна - если что-то поменяли с строке со старыми данными, то и фиг с ним. Задача - приблизить к реальности тест на свежих данных. Что посоветуете?

master-slave. Если целосность не важна совсем - писать скрипт самому

А тупо дамп-рестор не катит?

Не. Разворачивание идёт почти 14 часов при этом сервер полностью убит по io, работать нельзя. Поэтому сейчас приходится это делать только на выходных и то не каждых . Но это не гуд.

Не. Разворачивание идёт почти 14 часов при этом сервер полностью убит по io, работать нельзя. Поэтому сейчас приходится это делать только на выходных и то не каждых . Но это не гуд.

Да уж. Я пока в 5 часов укладываюсь, но думаю дальше больше будет.

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

ато может быть сюрприз

Всмысле ?

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

Как вариант накатывать бекап pitr

То есть в какой-то момент сделать дамп сохранять все измене ия в wal-лог, постоянно его куда-то копировать, ночью перетащить на тест. Как-то грохнуть все изменения сделанные в нем за день (как?). Накатить wal. И снова как-то зафиксировать состояние. Выглядит очень хорошо. Тогда даже базе будет консистентный - те все старое будет актуализировано.

То есть в какой-то момент сделать дамп сохранять все измене ия в wal-лог, постоянно его куда-то копировать, ночью перетащить на тест. Как-то грохнуть все изменения сделанные в нем за день (как?). Накатить wal. И снова как-то зафиксировать состояние. Выглядит очень хорошо. Тогда даже базе будет консистентный - те все старое будет актуализировано.

ну это по сути оффлайн master-slave

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

Все справочники и связанные данные накатывать так же - только свежее. Если customer Иванов стал Петров, то на тесте это не важно. А вот то, что id нового пользователя не помещается в форму и она теперь падает - это важно.

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

Не критичны. То есть их производить надо, что проверить работу приложения. Но каждую ночь все изменения. Можно сносить. Если вдруг надо сохранить какой-то кейс, его вынесем отдельно.

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

Да 14 эти локально. Копирование данных + индексы.

ну это по сути оффлайн master-slave

Да но с периодическим отрыванием и возвращением ;)

14 часов - лоакльно. Тады ой. Тады я немного погорячился.

Почему люди добавляются, а все равно 600 человек…

ограничение int9.23

??

ладно, не зашла шутейка

Марк, мне кажется вы начинаете флудить, и портите кристалльную академическую атмосферу тут.

Ладно. Просто там у нее коронная фраза как раз про эту шутку.…

ограничение int9.23

600,49149400672194747385804194362 получается. так что действительно не смешно

мы нашли новый эталон скукоты

кстати про кристальную академическую атмосферу. оказалось что я по прошествии 20 лет еще таки помню как на инженерном калькуляторе вычислить логарифм по любому основанию. #нозачем

мы нашли новый эталон скукоты

#zanoodamodeon int9,2288186904958808771943778029266

кстати про кристальную академическую атмосферу. оказалось что я по прошествии 20 лет еще таки помню как на инженерном калькуляторе вычислить логарифм по любому основанию. #нозачем

Хм, а я на логарифмической линейке.

@Aytuar твой логарифм-фу длиннее моего )

Привет, сообщество, у postgres есть какие-либо стандартные средства для версионирования таблицы?

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

в golang - https://bitbucket.org/liamstask/goose/ в python/sqlalchemy - https://pypi.python.org/pypi/alembic

liquibase (java), phinx (php)

flyway для Java

(из этого же чата, если в вопросе имелось в виду что-то другое - напиши)

Привет, сообщество, у postgres есть какие-либо стандартные средства для версионирования таблицы?

Функции, триггеры. Вот тулза от postgrespro https://github.com/postgrespro/pg_pathman

Да, мне именно данные. Читал, что тригеры не очень для этого, какие могут возникнуть проблемы с ними?

что значит версионирование?

это вы про темпоральность?

Хмм, видимо ?

Ой, прочитал "секционирование".

ну в PGSQL http://pgxn.org/dist/temporal_tables/

у нас в одном проекте уже используется (по моей наводке, но не я сам)

вроде особых нареканий не было

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

теоритически, сейчас можно попробовать что-то подобное замутить не на тригерах , а на базе logical decoding

обещает меньше накладных расходов, жертвуя транзакционностью

но я таких решений не видел еще

на сайте postgrespro было видео презентации посвещенное теме bi-temporal в postgres

сейчас найти не могу

есть вот ссылка на блог автора https://hdombrovskaya.wordpress.com/2016/03/15/my-presentation-on-bi-temporal-model-in-moscow/

полезно для общего осознания проблемы ознакомиться

я правильно понимаю, что нужно просто хранить версии сущностей?

я правильно понимаю, что нужно просто хранить версии сущностей?

Да, важны изменения.

ERROR: S client not available

Ну вы можете без всяких дополнений просто делать две записи в две таблицы, либо сразу взять event sourcing и хранить прямо аудит изменений. Не могу ничего сказать за скорость, но я бы эти два варианта в первую очередь смотрел.

Народ, если вдруг не знаете , HighLoad++ внезапно (для меня) организовал трансляцию с главного зала

https://special.habrahabr.ru/highload/2016/

Сейчас перерыв с интервью, продолжение трансляции - с 13.00 по МСК

Вот и расписание http://www.highload.ru/2016/schedule.html

По просьбам трудящихся выложил наш темплейт мониторинга Pg 9.4 https://github.com/CityAds/zabbix

Друзья, кто нибудь сталкивался с вопросом long-running tasks в pgAgent. Если подходит новое расписание задачи, а прошлая заадча еще в процессе. Будет ли запущена задача еще раз?

что то внятного ответа не нашел в доке

Нет

Нет

Это вы не сталкивались с таким или задача не будет запущена ? :)

задание не будет запущено

спасибо!

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

Ну и Яндекс.почта разрекламировали в который раз что оракл это плохо, а пг хорошо

Валик Гогичашвили делает доклад на Highload++ прямо сейчас. Советую посмотреть https://special.habrahabr.ru/highload/2016/

да, клево рассказывает

Блин, неужели не исправили Tried to send an out-of-range integer as a 2-byte value: 42854 до сих пор?

Печалит постоянно запросы бить на 2

Валентин просто нереально жжот глаголом! Явно один из лучших докладов конфы.

Валентин просто нереально жжот глаголом! Явно один из лучших докладов конфы.

Нашел он там себе сотрудников в Германию интересно?

Вы про Zalando?

да

А есть запись?

Вы про Zalando?

Zalando

А есть запись?

Ну вон же ссылка на хабр. Там должно лежать

Вижу только текст

что я делаю не так?

записи стрима нет, да