Originally created by: itagaki....@gmail.com
Originally owned by: itagaki....@gmail.com
現在、バックアップの履歴は、ディレクトリ構成とその中のテキストファイルで
管理されている。この方式は、追加のライブラリや設定などが不要な利点が
あるものの、他ツールとの連携がしづらく、内部的な扱いも複雑になっている。
== 改善案 ==
履歴情報を他DBMSに保存してはどうか?
もちろんバックアップ対象の PostgreSQL に保存してしまうとディスク故障で
一緒に失ってしまうので、別のサーバは必要になる。別サーバを用意する手間を
避けるため、SQLite 等の組み込みDBを用いることも考えられる。
特に pg_rman の GUI フロントエンドを開発するような場合には、
pg_rman show の出力を再解析するよりも、直接 DBMS からカタログ情報を
取得したほうがスマートである。
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: itagaki....@gmail.com
tranlate to English:
Now the catalog of backup history are managed with hierarchy of directories and
plan text files in them. This implementation might be good in because it does not
require any additional libraries and configuration files, but other tools hard
to access the catalog information and the internal codes are very complex and buggy.
== Suggestion ==
Change to store the backup catalog in RDMBS. The RDBMS must be different form
the backuped database itself. SQLite might be a good solution because it does not
require to setup another database server.
If the backup catalog is stored in common RDBMS, users could write a GUI frontend
for pg_rman. Reparsing the output of "pg_rman show" is messy.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: feikesteenbergen@gmail.com
My opinion on this matter is that the catalog should be held in the postgres cluster
AND outside the cluster.
The reason to have it in the cluster is so that DBA's can monitor backups easily
using familiar tools.
The reason to have it outside the database (whether in files or in another DBMS) is
to have the ability to recover when the cluster has vanished.
These two catalogs would have to be synchronized though, but I don't think that would
be a big issue.
View and moderate all "tickets Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Tickets"
Originally posted by: saas...@gmail.com
How about storing the catalog information in a simple BTree like data structure?