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

Question

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

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

Любой вклад приветствуется!

UPD

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

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

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

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

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

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

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

Answer 1

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

PostgreSQL раньше имел только эту функцию и называл ее «Путешествие во времени». См старая документация .

В модуле spi contrib есть схожая функциональность, которую вы, возможно, захотите проверить.

Триггер аудита составного типа

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

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 не определено).

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

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

PITR

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

Answer 2

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

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

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

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

Возможно, эта недавняя связанная тема интересна:

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

Answer 3

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

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

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

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

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

Answer 4

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