Управление версиями содержимого базы данных

Я заинтересован в сохранении истории выполнения всех изменений, которые произошли в некоторых таблицах в моей базе данных, что позволяет восстановить исторические состояния базы данных для целей анализа.

Я использую Postgres, и эта вещь MVCC просто кажется, что я должен использовать ее для этой цели, но я не могу найти никакой документации для ее поддержки. Могу ли я это сделать? Есть ли лучший способ?

Любой ввод оценивается!

------- EDIT -------

Я отвел ответ Дениса как ответ, потому что он действительно ответил, является ли MVCC тем, что я хочу, в чем вопрос. Тем не менее, стратегия, о которой я остановилась, подробно описана ниже, если кто-либо сочтет это полезным:

Функция Postgres, которая делает то, что я хочу: онлайн-резервное копирование/точечное восстановление.

http://www.postgresql.org/docs/8.1/static/backup-online.html объясняет, как использовать эту функцию, но по существу вы можете установить этот "журнал записи вперед" в режим архивации, сделать снимок базы данных (скажем, до того, как она выйдет в прямом эфире), а затем постоянно архивировать WAL. Затем вы можете использовать повтор воспроизведения журнала, чтобы вызвать состояние базы данных в любое время, при этом вы можете использовать теплый режим ожидания (если постоянно переигрывать новые WAL на резервном сервере).

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

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

Прежде чем я узнал о WAL, я рассматривал возможность делать ежедневные снимки или что-то в этом роде, но требования к большому размеру и потери данных не соответствовали мне.

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

Ответы

Ответ 1

Я использую Postgres, и эта вещь MVCC просто кажется, что я должен использовать ее для этой цели, но я не могу найти никакой документации для ее поддержки. Могу ли я это сделать?

Не совсем. Есть инструменты для просмотра мертвых строк, потому что автоматическое вакуумирование - это то, что в конечном итоге будет исправлено.

Есть ли лучший способ?

Если я правильно задаю вопрос, вы смотрите в журнал медленно меняющиеся размеры.

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

Временная структура базы данных с твистом (прямая трансляция строк)

Ответ 2

Путешествие во времени

PostgreSQL использовал только эту функцию и назвал ее "Time Travel". См. старую документацию.

Здесь несколько аналогичная функциональность в spi contrib module, которую вы можете проверить.

Триггер аудита композитного типа

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

CREATE TABLE sometable_history(
    command_tag text not null check (command_tag IN ('INSERT','DELETE','UPDATE','TRUNCATE')),
    new_content sometable,
    change_time timestamp with time zone
);

и ваш триггер версии может просто insert into sometable_history(TG_OP,NEW,current_timestamp) (с другим CASE для DELETE, где NEW не определено).

триггер аудита hstore

Это становится болезненным, если схема изменит добавление новых столбцов NOT NULL. Если вы планируете сделать что-либо подобное, подумайте об использовании hstore для архивирования столбцов вместо составного типа. Я уже добавил реализацию этого в вики PostgreSQL уже.

PITR

Если вы хотите избежать влияния на основную базу данных (растущие таблицы и т.д.), вы можете поочередно использовать непрерывное архивирование и восстановление по времени регистрировать WAL файлы, которые с помощью recovery.conf могут быть воспроизведены в любой момент времени. Обратите внимание, что файлы WAL большие, и они включают не только измененные кортежи, но и активность VACUUM и другие детали. Вы захотите запустить их через clearxlogtail, поскольку они могут содержать данные об мусоре в конце, если они являются частичными сегментами из таймаута архива, то вы захотите сжать их для долговременного хранения.

Ответ 3

Я не знаю никаких инструментов/продуктов, которые были созданы для этой цели.

Хотя это может быть не совсем то, о чем вы просите, вы можете настроить Postgresql для регистрации изменений ddl. Установка параметра log_line_prefix (попробуйте включить% d,% m и% u), а параметр log_statement в ddl должен дать вам разумную историю того, кто сделал то, что ddl изменилось и когда.

Сказав это, я не считаю, что регистрация ddl является надежной. Например, рассмотрим ситуацию, когда:

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

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

Ответ 4

вы должны попробовать nextep. это программное обеспечение создает историю базы данных. Он использует модифицированную среду Eclipse IDE