Re: backup database by cloning itself
От | Ted Byers |
---|---|
Тема | Re: backup database by cloning itself |
Дата | |
Msg-id | 02cd01c7507d$263e2710$6401a8c0@RnDworkstation обсуждение исходный текст |
Ответ на | backup database by cloning itself ("filippo" <filippo2991@virgilio.it>) |
Список | pgsql-general |
----- Original Message ----- From: "Ron Johnson" <ron.l.johnson@cox.net> To: <pgsql-general@postgresql.org> Sent: Wednesday, February 14, 2007 3:46 PM Subject: Re: [GENERAL] backup database by cloning itself >> >> It seems to me that if you really want a historical record of what >> certain tables looked like in the past, it would be smarter and more >> accurate to create triggers, for each possible operation, that store the >> relevant details in an audit table including especially who made the >> edits and when. This strikes me as being much less work than developing >> code that processes so many backups. > > I dunno about that. We use triggers to populate log tables that get > extracted, truncated then loaded into a reporting db every night. > Because of the night time batch cycle, there is no quiescent time to > do this, so we have 2 log tables, and the triggers alternate which > log table to insert into, depending on whether the day number is > even or odd. > > That's in addition to the trigger logic to insert into history tables. > > It's a royal pain. Sounds painful, but not as painful as trying to do the same thing with a suite of backups and client code to read the backups. Or maybe the latter task is easier than it looks at first glance. Doesn't the amount of pain depend on the amount of traffic your servers see, the capability of the hardware you can devote to the task, what you're doing with the history tables, &c.? When I've worked on this kind of problem, everything was in a single DB. The traffic, though, was low enough that for daily reports a simple view of the log selecting only the previous day's data, was sufficient, but only occasionally used. The principal reason for the log was to support accountability, to know who made changes, and when, and who knew what when. Historical reconstructions were required, e.g., only when something went awry and there was a need to know if a good decision was made based on bad data or a bad decision was made based on good data, or, e.g., during an audit of the business processes and decision support systems. Cheers, Ted
В списке pgsql-general по дате отправления: