On 7/3/2004 9:11 AM, Martin Marques wrote:

El Vie 02 Jul 2004 18:39, Jan Wieck escribió:
On 6/22/2004 11:51 PM, mike g wrote:
> Slony version 1 is supposed to be live very soon.  You can test beta3 if
> you like.

Slony-I version 1.0 is out now. It does not contain incremental backup.
This feature is on the TODO list for 1.1.

I'm very interested in this.
How is it that a replication system would give the ability of doing incremental backups?

The information Slony collects with triggers basically consists of INSERT, UPDATE and DELETE statements that cause exactly the same changes on a slave, that have been performed on the master. If it is possible to extract a consistent data snapshot and to know exactly what actions are included in that, and which need to be redone after ...


There isn't much of a difference between applying the changes to a database and writing SQL statements into files.

How would these incremental backups compare to Informix's level backups (level 0 is a full backup, 1 are the differences from the last 0, and 2 are the differences from the last level 1 BU)?

I wonder how informix does that sort of level backup. It sounds very much like a filesystem dump, but on a database level I can't really imagine this. Especially with an MVCC database like PostgreSQL.


There will be no levels. Slony will provide a dump, and then incrementals. One advantage will be that the incrementals are just plain SQL scripts containing INSERT, UPDATE and DELETE operations. One usually does PITR because a misbehaving application corrupted the data from a logical point of view. Finding the offending statement with grep in those files will ultimately lead to the exact point in time to wich the DB can be rolled forward. Plus, it will be easy to analyze what had been done after that point, based on the wrong data.


Jan

--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== [EMAIL PROTECTED] #


---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster

Reply via email to