毎秒 1 エントリ (約 300KB) のデータ エントリ レートを持つデータベースの圧縮をサポートする必要があります。データベース ファイルは 3GB に達することがあります。現在のデータベースには自動バキューム機能がありません。データベース ファイルの容量が特定の制限 (たとえば 3GB) を超えるのは、最悪のシナリオです。

私の現在の戦略は、(クラスター化された主キーによって) 最も古いデータを削除してから、CHECKPOINT DEFRAG を実行することです。これは信頼できるものではないようで、VACUUM または DEFRAG には長い時間がかかる可能性があります。データベース名に名前を付けたくありませんが、提案は受け付けています。

確実に (ダウンタイムがほとんどまたはまったくない、O(1) の操作速度で) ディスク容量を確保するために、他にどのような戦略が利用できるか疑問に思っていました。

編集: レポートとして必要なリレーショナル データベースと SQL データ抽出が必要です。

固定サイズの循環バッファー - まさに - フットプリントの小さい DB と高速な「循環」動作 (つまり、高速挿入) を使用して、リレーショナルの世界でこれを複製する必要があります。

AWS RDS プラットフォームで PostgreSQL 9.3 を実行しています。毎晩午前 1 時に、グローバルVACUUM ANALYZEジョブを実行しています。

VACUUM ANALYZE昨日、パフォーマンスの大幅な低下が見られ、過去 5 日間で5 つのプロセスがスタックしていたことが判明しました。同じ期間に、ディスク使用率は 45 ギガバイト増加しました。

で殺しましたpg_terminate_backendが、あまり影響はありませんでした。プロセスは停止しているように見えましたが、パフォーマンスは依然として大幅に低下していました。AWS RDS を使用しているため、フェイルオーバーを使用して再起動すると、すぐにパフォーマンスが大幅に改善されました。

今朝確認したところ、VACUUM ANALYZE再び 5 時間スタックしていることがわかりました。私はそれを殺しましたが、まだどこかにあると思います。

さらに調査した結果auto_vacuum、正しく有効になっていることを確認しました。つまり、手動で実行する必要はありませんが、一部またはすべてのテーブルでVACUUM実行する必要がある場合があります。ANALYZE

私の調査では、次の記事を見つけました: http://rhaas.blogspot.com/2011/03/troubleshooting-stuck-vacuums.htmlおよびhttp://wiki.postgresql.org/wiki/Introduction_to_VACUUM,_ANALYZE,_EXPLAIN,_and_COUNT。

最後に、次の質問があります。

1. auto_vacuum を有効にして手動で VACUUM を実行しないのは正しいですか?
2. auto_vacuum の進行状況とパフォーマンスを監視するにはどうすればよいですか? マニュアルの VACUUM と同じ場所にスタックしていないことをどのように確認できますか?
3. ANALYZE を定期的に実行する必要がありますか?
4. auto_vacuum と同様に、自動 ANALYZE を有効にする方法はありますか?

こんにちは Slack Overflowvians。

それで、8.3.11を実行しているこのPostgreSQLサーバーに出くわしました（ええ、知っています）、それはロックされた状態でした：

通常、自動バキューム デーモン ( autovacuum=on) がこれを処理しますが、次の 4 つの TOAST (パンのような大きなフィールド値 8 kB スライスの格納を許可する) のため、データベース オブジェクト. しかし、これらの破損したデータベース オブジェクトが原因で、このデータベースの XID がリセットされることはありませんでした。

以下は、admin ユーザーを使用してシングルユーザー モードでサーバーを実行したときの出力のスニペットです。

vacuum_freeze_min_ageこのサーバーでは age が (VACUUM が成功した後に設定された値) をはるかに上回っていることに注意してください。上記はVACUUM FULL;を実行した後です。他のすべてのテーブルは問題ありません。

そのため、ディスクを調べたところ (上記の各テーブルに pg_class.relfilenode 値を使用)、トースト テーブルのファイルが見つかりませんでした。

トーストのインデックスでディスクを見たとき

次に、不良トースト レコードが関連付けられているテーブルを見つけようとしました。

上記の各テーブルで 0 件の結果が得られました! VACUUMこれらの関係の XID をリセットするコマンド のテーブルはありません。

pg_depend テーブルを確認したところ、これらの TOAST テーブルには参照がないことがわかりました。

質問

1. pg_class テーブルから不適切な TOAST テーブルと TOAST テーブル インデックスを削除できますか (例DELETE FROM pg_class where oid=2421459)
2. リレーションを削除する必要がある他のテーブルはありますか?
3. 一時テーブルを作成して、それを TOAST のインデックスの oid にリンクすることはできますか?

上記の #3 の例:

編集：

select txid_current()は 3094769499 であるため、これらのテーブルはかなり前に破損しています。データを回復する必要はありません。Linux 2.6.18-238.el5 で ext4 ファイル システムを実行しています。関連するlost+found/ディレクトリを確認しましたが、ファイルはありませんでした。

PostgreSQL で自動バキュームを有効にするにはどうすればよいですか? 目的は理解していますが、それを有効にする方法に関する簡単な答えが見つかりません。

列idがprimary key.

次に、すべての行を削除しますwhere id > 10。テーブルには 10 行しか残っていません。

今、クエリを実行するSELECT id FROM tablenameと、実行時間は約 1.2 ～ 1.5 秒です。
しかしSELECT id FROM tablename where id = x、10 ～ 11 ミリ秒しかかかりません。

SELECT最初の行がわずか 10 行で遅いのはなぜですか?

PostgreSQL では、トランザクション ID のラップアラウンドによる非常に古いデータのデータ損失を防ぐために、定期的にバキュームする必要があります。定期的にバキューム処理を行わないと、SQLite3 データベースでもデータ損失が問題になるのではないかと懸念しています。

さらに、SQLite3 データベースが経験するワークロードは重要ですか? 現在、次のようないくつかのシナリオで SQLite3 を使用することを考えています。

• 人々がファイルを共有し、異なるマシン間でそれらを使用する可能性のあるプログラムのファイル形式として
• アプリケーション設定を保存する
• 1 秒間に複数回ログを記録するアプリケーションのログを保存するため (最近のデータに対するクエリは 1 時間ごとに実行される場合があります)

また、更新と削除の頻度は重要ですか?

現在、 Android Auto Backupには 25 メガバイトの制限があります。

バックアップ マネージャがバックアップ ジョブを実行する前に、データベースで SQLiteバキュームを実行する方法はありますか?

これは、クォータ内でできるだけ多くのユーザーを維持するためです。