Т
В идеале историю изменений, но хотя бы аудит. Про log_destination(stderr, csvlog и syslog) в принципе минимально тоже не плохая идея, чтоб лишний раз в базу не писать, а выплевывать это все в какой нить эластик.
Size: a a a
2020 July 22
Т
спасибо!
Т
тут надо смотреть на потребление этих версий. где-то они нужны “встроенные” (а-ля Temporal Databases), где-то надо выносить в лог-таблицы
а что за log-таблицы ?
VY
а что за log-таблицы ?
триггером писать старые версии строк в таблицу-лог, с аналогичной схемой (без constraint-ов) и несколькими служебными полями
Т
не, это устаревший путь, совсем не хочется в 2020 году возвращаться к таким реализациям.
VY
не, это устаревший путь, совсем не хочется в 2020 году возвращаться к таким реализациям.
это может оказаться выгоднее (быстрее), чем другие варианты.
Т
триггеры не могут быть быстрыми. С точки зрения скорости записи в некоторых случаях, возможно, но всяко wal во1 добавляет асинхронности, а во2 работает прозрачно и без дополнительного функционала. Но в случаях кластеров, не хочется лишний раз грузить эту же базу чем то не жизненно важным.
VY
триггеры не могут быть быстрыми. С точки зрения скорости записи в некоторых случаях, возможно, но всяко wal во1 добавляет асинхронности, а во2 работает прозрачно и без дополнительного функционала. Но в случаях кластеров, не хочется лишний раз грузить эту же базу чем то не жизненно важным.
> но всяко wal во1 добавляет асинхронности, а во2 работает прозрачно и без дополнительного функционала
а можно перевести?
а можно перевести?
АЛ
Имеется ввиду, что декодирование wal и запись в другое место - не создает дополнительной нагрузки на БД
АЛ
Где-то я видел статью про декодирование wal в json при логической репликации
Т
> но всяко wal во1 добавляет асинхронности, а во2 работает прозрачно и без дополнительного функционала
а можно перевести?
а можно перевести?
прозрачно - идет прямая запись в таблицу(триггера висят на таблице, их могут погасить например, ну ручки шаловливые бывают)
асинк - изменение данных попадает в журнал а далее журналы подхватываются асинхронно ведомыми, никак не блокируя мастер.
асинк - изменение данных попадает в журнал а далее журналы подхватываются асинхронно ведомыми, никак не блокируя мастер.
Т
Где-то я видел статью про декодирование wal в json при логической репликации
из репликационных слотов вполне можно читать просто как из вьюхи или функции.
АЛ
Т
и чтение на самом деле идет напрямую из wal'ов и не покрывается транзакцией, это практически единственная, известная мне, сущность, не покрываемая транзакцией в постгресе
Т
https://habr.com/ru/post/254263/
Но довольно старая статья
Но довольно старая статья
ага, в свое время читал ее
Т
но проще оказалось реализовать механизм вне постгреса, но использовать чтение из слотов
Т
pg...get_changes
VS
привет пацанчики. подскажите что не так делаю. в пг12 сделал архивирование логов через валг, замутил полный бекап и потоковый чтоб бэкапилось непрерывно. потом сделал второй сервер, который должен непрерывно восстанавливаться из бэкапа. в 12 поменяли расположение restore_command на постгрес.конф, я его перенес туда и поднял флажок /var/lib/postgresql/12/main/recovery.signal
VS
12 main 5433 down,recovery postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log
VS
я вижу, что рекавери распозналось