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 [EMAIL PROTECTED] [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
