Alle 16:30, sabato 6 marzo 2004, Andrew Sullivan ha scritto:
> Asynchronous replication with automatic failover is _dangerous_,
> because you can strand records. Many commercial systems do this with
> what they describe as conflict-management; in truth, this usually
> amounts to marking _both_ records as suspect and letting the DBA
> decide what to do.
Of course, that's right. Nevertheless, it is hard to imagine anything better
than master-slave replication as a backup/recovery mechanism. For example,
how more data would you loose during a file system copy?
Much of the overall reliability depends on the details of the replication and
of the failover mechanisms:
- you need to copy the master db to the slave at a good speed and with a high
frequency, in order to not leave behind any unsaved data. This mean to have
good hardware and a good network.
- the failover mechanism should be designed to flush all unsaved data before
shutting down the master and replace it with the slave, if possible. This is
often just matter to wait for the next step of replication.
- some kind of database "journaling" can help. Write down any request of data
change sent to the master before actually performing it. This should allow
you to spot any unsaved operation at restore-time.
- and so on....
Unfortunately, the only way to guarantee the system against any loss of data
should be to use a federation of server with a federation-wide concept of
transactions. That is: a transactions does not commit until all federated
servers have performed the required change to data. Bettina Kemme's
replication engine seems to evolve in this direction but, as long as I know,
no PostgreSQL replication system actually implement this mechanism yet.
See you.
-----------------------------------------
Alessandro Bottoni and Silvana Di Martino
alessandrobottoni@interfree.it
silvanadimartino@tin.it
