21

データベースのいくつかのテーブルで発生したすべての変更の実行中の履歴を保持することに関心があるため、分析目的でデータベースの履歴状態を再構築できます。

私は Postgres を使用していますが、この MVCC はこの目的のために悪用できるはずですが、これをサポートするドキュメントが見つかりません。私はそれを行うことができますか？より良い方法はありますか？

どんな入力でも大歓迎です！

UPD

Denis の回答を回答としてマークしました。なぜなら、彼は MVCC が私が求めているものであるかどうかという質問に実際に答えたからです。ただし、誰かが役に立つと思った場合に備えて、私が決めた戦略を以下に詳しく説明します。

私が望むことを行う Postgres 機能: オンライン バックアップ/ポイント イン タイム リカバリ。

http://www.postgresql.org/docs/8.1/static/backup-online.htmlでこの機能の使用方法が説明されていますが、基本的には、この「先行書き込みログ」をアーカイブ モードに設定して、データベースのスナップショットを作成できます (たとえば、 、ライブになる前に)、WAL を継続的にアーカイブします。その後、ログ再生を使用していつでもデータベースの状態を呼び出すことができます。また、必要に応じてウォーム スタンバイを使用するという副次的な利点もあります (スタンバイ サーバーで新しい WAL を継続的に再生することにより)。

おそらく、この方法は履歴を保持する他の方法ほど洗練されていません。クエリを実行するすべての時点で実際にデータベースを構築する必要があるためです。ただし、セットアップは非常に簡単で、情報を失うことはありません。つまり、履歴データの処理を改善する時間があれば、すべてが揃っているので、私の不格好なシステムをより洗練されたシステムに変えることができます。

これを完璧にする重要な事実の 1 つは、特定のアプリケーションの「有効時間」が「トランザクション時間」と同じであることです。そうでない場合は、「トランザクション時間」のみをキャプチャします。

WAL について知る前は、毎日のスナップショットか何かを取得することを検討していましたが、大きなサイズの要件と関連するデータ損失が私には合いませんでした。

最初からデータの保持を損なうことなく、すぐに起動して実行する方法として、これは完璧なソリューションのように思えます.

4

3 に答える 3

10

タイムトラベル

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)） 。CASEDELETENEW

hstore監査トリガー

NOT NULLただし、スキーマが変更されて新しい列が追加されると、それは面倒になります。そのようなことを行う場合hstoreは、複合型ではなく、を使用して列をアーカイブすることを検討してください。PostgreSQLwikiにその実装をすでに追加しました。

PITR

マスターデータベース（成長するテーブルなど）への影響を回避したい場合は、継続的なアーカイブとポイントインタイムリカバリrecovery.confを交互に使用して、を使用して任意の時点で再生できるWALファイルをログに記録できます。WALファイルは大きく、変更したタプルだけでなく、VACUUMアクティビティやその他の詳細も含まれていることに注意してください。それらがアーカイブタイムアウトからの部分的なセグメントである場合、最後にガベージデータを持つ可能性があるため、 clearxlogtailを介して実行する必要があります。その後、長期保存のためにそれらを大幅に圧縮する必要があります。

于 2012-09-26T23:27:32.433 に答える
5

私は Postgres を使用していますが、この MVCC はこの目的のために悪用できるはずですが、これをサポートするドキュメントが見つかりません。私はそれを行うことができますか？

あまり。自動バキュームは最終的に再利用されるため、デッド行を確認するためのツールがあります。

より良い方法はありますか？

あなたの質問が正しければ、ゆっくりと変化するディメンションのログ記録を検討しています。

この最近の関連スレッドは興味深いかもしれません。

ひねりを加えたテンポラル データベース設計 (ライブ vs ドラフト行)

于 2011-06-16T09:25:58.817 に答える
1

その目的のために構築されたツール/製品については知りません。

これはまさにあなたが求めているものではないかもしれませんが、Postgresql を構成して ddl の変更をログに記録することができます。log_line_prefix パラメーターを設定し (%d、%m、および %u を含めてみてください)、log_statement パラメーターを ddl に設定すると、誰がどの ddl をいつ変更したかについての妥当な履歴が得られます。

そうは言っても、ddl のログ記録が絶対確実だとは思いません。たとえば、次のような状況を考えてみましょう。

  1. 複数のスキーマに同じ名前のテーブルがあり、
  2. テーブルの 1 つが変更され、かつ
  3. ddl がテーブル名を完全に修飾していない (正しい検索パスに依存している)。
  4. その場合、どのテーブルが実際に変更されたかをログから知ることができない場合があります。

別のオプションとして、上記のように ddl をログに記録することもできますが、ddl エントリがログに記録されるたびに監視プログラムにデータベース スキーマの pg_dump を実行させることもできます。新しいダンプを以前のダンプと比較して、変更されたオブジェクトだけを抽出することもできます。

于 2011-06-16T04:02:12.047 に答える