SELECT * FROM table;

Может есть что-то типа git :) только для записей БД

event sourcing

У меня следующая заморочка (качательно версионности). Нужно выводить пользователю, что и когда менялось в записи

event sourcing x2

:)

Уже хабр открыл, чтобы понять о чем речь

У меня следующая заморочка (качательно версионности). Нужно выводить пользователю, что и когда менялось в записи

делать insert вместо update?

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

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

event sourcing Я как понял это тот же паттерн observer, но на стороне БД

?

В доменной модели описываются события, которые могут произойти над сущностью: увеличение баланса, уменьшение баланса, смена владельца, любое другое доменное событие. Как правило, каждое такое событие оформляется классом, который реализует два функционала: произведение изменений над готовой сущностью и сериализация-десериализация свойств этого события. Например, событие "изменение баланса" будет иметь поле "изменение", в которое будет записываться указанное изменение баланса, а при применении к объекту это изменение будет складываться с текущим балансом. В результате каждая сущность представляет из себя просто лог событий, которые с ней происходили, а для восстановления состояния достаточно все эти события применить к болванке сущности.

В результате какой-нибудь банковский аккаунт получается логом из событий "создан", "внесены деньги", "сняты деньги", все это дело хранится в базе данных с минимальным оверхедом, т.к. требуется хранить только необходимые данные для каждого события, аудит представляет собой не историю изменений атрибутов, а реальную историю событий с сущностью, обновления происходят через простую оптимистичную блокировку, но у этого есть очевидные минусы - например, надо городить ручные мат.вью для сущностей, чтобы делать обычные выборки, изменения приходится хранить в виде сериализованных объектов.

Надеюсь, более-менее понятно написал, н оесли нет, всегда есть Фаулер http://martinfowler.com/eaaDev/EventSourcing.html

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

Привет! Может кто поскажет по процедуре промоутинга. У нас есть процесс, он построен на ручных действиях и состоит примерно из таких действий: 1) Остановка старого мастера (если он жив) 2) Создание триггер-файла на целевом слейве 3) Актуализация конфигурации нового мастера 4) Обновление CNAME DNS (мы используем их для определения кто мастер и кто слейв) 5) Переналивка слейва относительно нового мастера 6) Все решения принимает человек, информацию о том какая текущая роль у сервера он берет из мониторинга по метрикам и сверяет их с другими фактами (ДНС, записи от системы управления конфигурации) Пункты 5 и 3 делаются самой системой управления конфигурации, а не руками, но не суть. Сейчас встал вопрос в автоматизации всех этих действий т.к. есть подозрения в том что дежурные могут сильно накосячить в случае когда промоутинг придется делать по инструкции вне штатной ситуации, и здесь не чоень понятно как заскриптить весь процесс и даст ли это преимущество над человеческой ошибкой, также проблема ДНС в ближайшее время может дать свои проблемы, т.к. есть планы масштабировать слейвы для распределения нагрузки на чтение, внутри команды есть инициатива использовать плавающий адрес, и менять его привязку к серверу в зависимости от живой и активной ноды. Может кто поделиться опытом как еще устраивают подобные сценарии промоутинга, может есть какие полезные доклады или статьи на эту тему?

http://wiki.clusterlabs.org/wiki/PgSQL_Replicated_Cluster

Вы не боитесь, что у вас DNS в какой-то момент где-нибудь закешируется?

А он закешируется. Обязательно. И с кривым экспайром.

Да, думаем об этом. Или просто запись не обновится в ожидаемое время, и основная проблема - мы не можем проверить что запись обновилась для всех-всех инстансов работающих с БД

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

У нас keepalived несколько раз очень больно падал

А как выглядило это падение? И у вас он использовался для автоматического переключения адресов или в ручном режиме? По wiki что дали, там предлагаю ставить corosync + pacemaker, это выглядит ближе к autofailover. Выглядит сложно, в таком случае понадобится еще машина "свидетель/арбитр", из того что видно сразу.

Я не уверен, что существуют специализированные средства для таких ситуаций, и здесь наиболее разумным (с моей колокольни) кажется bash/ruby/etc-скрипт, который просто будет заходить на все машины по ssh, выполнять необходимые действия, переходить к следующему этапу, и так пока успешно не завершится.

Привет! Может кто поскажет по процедуре промоутинга. У нас есть процесс, он построен на ручных действиях и состоит примерно из таких действий: 1) Остановка старого мастера (если он жив) 2) Создание триггер-файла на целевом слейве 3) Актуализация конфигурации нового мастера 4) Обновление CNAME DNS (мы используем их для определения кто мастер и кто слейв) 5) Переналивка слейва относительно нового мастера 6) Все решения принимает человек, информацию о том какая текущая роль у сервера он берет из мониторинга по метрикам и сверяет их с другими фактами (ДНС, записи от системы управления конфигурации) Пункты 5 и 3 делаются самой системой управления конфигурации, а не руками, но не суть. Сейчас встал вопрос в автоматизации всех этих действий т.к. есть подозрения в том что дежурные могут сильно накосячить в случае когда промоутинг придется делать по инструкции вне штатной ситуации, и здесь не чоень понятно как заскриптить весь процесс и даст ли это преимущество над человеческой ошибкой, также проблема ДНС в ближайшее время может дать свои проблемы, т.к. есть планы масштабировать слейвы для распределения нагрузки на чтение, внутри команды есть инициатива использовать плавающий адрес, и менять его привязку к серверу в зависимости от живой и активной ноды. Может кто поделиться опытом как еще устраивают подобные сценарии промоутинга, может есть какие полезные доклады или статьи на эту тему?

Посмотри https://github.com/zalando/patroni Можно сделать через haproxy

У нас в автомате было. Я не имел большого отношения к его конфигурации и не знаю всех подрробностей, но в результате мускул умудрился среплицировать /dev/null размером в полбазы

Патрони выглядит интересно

"внутри команды есть инициатива использовать плавающий адрес, и менять его привязку к серверу в зависимости от живой и активной ноды." У нас постгре кластер, с 4 слейвами, над ним PgPool. Пгпул отвечает за промоутинг и за распределение нагрузки (тупое правда, селекты по round-robin отправляет на слейвы), при этом пгпулов 2 в режиме hot-stand-by, на пгпулах как раз виртуальный айпи. Собстно в апп серверах этот виртуальный айпи как айпи базы указывается.

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

страшновато звучит

196G /var/lib/pgsql/9.5/data/base/pgsql_tmp - что за папка?

выростает раз в 6ть часов потом исчезает

размер базы всего 40 гиг

что там можно темповать?

Seq scan запросы?

Скорее всего неверно настроен workmem

бизнес аналитики из Power BI написали запрос со 100500 CASE когда можно было сделать join

Скорее всего неверно настроен workmem

всмысле мало или много?

Мало

Тут ещё транзакция может быть настроена

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

Сервер не тот например.

в списке через \list видна, подключаюсь из идеи - не видна

и база postgres видна

хм, муть какая-то. поменял порт с 5433 на 5432 - пропала и из \list, слетел пароль на postgres, но создал заново и заработало ><

права на базу?

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

два постгреса разных версий, потому что обновляли убунту? :)

всем привет) у меня вопрос: нужно перегнать большой массив данных из csv файла в БД, попыталась сделать вот так: COPY accelerator_log FROM '/home/username/blahblahblah.csv' WITH CSV HEADER, ругнулось на несоотвествия данных, а именно таймстемпа - дело в том, что мне дала файлики с Unix timestamp а мне нужно как-то перевести их в postgres timestamp.. кто-нибудь сталкивался с этой проблемой?

Помогите пожалуйста, дедлайн на носу((

перегнать в таблицу без таймстампа, потом написать вставку в другую, с приведением к таймстампу, не ?

а как его приводить есть соображения? я с юниксовым тамйстемпом впервые встречаюсь

to_timestamp? :)

to_timestamp? :)

спасибо)

напоминалка http://www.epochconverter.com/

да хоть в браузере в консоли new Date(timestamp*1000);

да хоть в браузере в консоли new Date(timestamp*1000);

Да хоть man date :)

Немного о том, что пропатчили в PostgreSQL в составе Astra Linux и как это повлияло на скорость работы с базой данных. В PostgreSQL, входящий в Astra Linux добавлены средства расширенного аудита и разграничения доступа вплоть до ячейки, а с версии 1.5 PostgreSQL стал поддерживать мандатно-ролевую модель разграничения в полном объеме. Собственно, ниже небольшое описание влияния средств защиты информации и расширенного аудита на скорость работы модифицированной версии PostgreSQL в Astra Linux Special Edition.

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

Одно таки маленькое НО. В астре пг - 9.4, а выше - нет и неизвестно.

Одно таки маленькое НО. В астре пг - 9.4, а выше - нет и неизвестно.

Коммерческие продукты не так часто меняют поддерживаемые версии БД чтобы скакать по числовым вершкам

А есть тут кто с киева? :)

Коммерческие продукты не так часто меняют поддерживаемые версии БД чтобы скакать по числовым вершкам

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

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

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

Коммерческие продукты не так часто меняют поддерживаемые версии БД чтобы скакать по числовым вершкам

И, кстати, в ванильной версии ПГ нет мандатного доступа, так что указывать на различие версий тут не совсем корректно.

И пока вы ваш продукт сертифицируете (иначе зачем вам астра), еще пару версий pg выйдет

привет.

есть два сервера бд на одном сервере на дебиане: 9.4 и 9.6

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

порт указали? :)

да

а что значит "не хочет видеть базу"?

пишет, что база не найдена

покажите ошибку

если бд не найдена, значит не найдена

если бд не найдена, значит не найдена

+1

нет, ну может плохо искали ? :)

дебиан поди :)

а что значит "не хочет видеть базу"?

Ну когда отказывается. Ты ему шоу датабазес. Он тебе — не заставляй меня сегодня работать, не хочу, у меня шаббат.

Ну когда отказывается. Ты ему шоу датабазес. Он тебе — не заставляй меня сегодня работать, не хочу, у меня шаббат.

нет, это когда ты "шоу датабазес", а он тебе: "mysql sucks" ?

Я специально чтобы кто-нибудь подыграл, а ты не подыграл.

нет, это когда ты "шоу датабазес", а он тебе: "mysql sucks" ?

http://sqlanywhere.blogspot.ru/2008/03/unpublished-mysql-faq.html

?

http://sqlanywhere.blogspot.ru/2008/03/unpublished-mysql-faq.html

??

да, у постгреса был бы ответ "просто потюнь автовакуум"

http://sqlanywhere.blogspot.ru/2008/03/unpublished-mysql-faq.html

Я тут один баянчик про MySql вспомнил https://www.youtube.com/watch?v=emgJtr9tIME