Subject | Syncronous replication |
---|---|
Author | Robert Munro |
Post date | 2002-04-19T02:36:35Z |
Is it possible to write a syncronous replication system for Firebird? Ie.
when a transaction is committed, it's changes are first tried on all the
other servers (as long as they are working), then the commit is accepted
(across all servers)? Has it been done? IBReplicator, IBO replicator (but I
haven't checked thoroughly) and Fibre (my own replication tool that I am
developing) seem to all focus on the asyncronous replication problem, where
changes are recorded, and then slave databases are syncronised with a
master.
Syncronous replication is useful for having an on line backup fail over, and
in places where there are a lot more reads than writes, it could be used to
spread the load of those reads over multiple servers. There is some mention
of distributed databases and two phase commits in the documentation, which
are related topics, but this seems to be for putting some data on one
server, and other data on another server from the client end and have both
sets of data behave as though they were in one transaction, not for one
server to put it's data on other servers.
Robert Munro
when a transaction is committed, it's changes are first tried on all the
other servers (as long as they are working), then the commit is accepted
(across all servers)? Has it been done? IBReplicator, IBO replicator (but I
haven't checked thoroughly) and Fibre (my own replication tool that I am
developing) seem to all focus on the asyncronous replication problem, where
changes are recorded, and then slave databases are syncronised with a
master.
Syncronous replication is useful for having an on line backup fail over, and
in places where there are a lot more reads than writes, it could be used to
spread the load of those reads over multiple servers. There is some mention
of distributed databases and two phase commits in the documentation, which
are related topics, but this seems to be for putting some data on one
server, and other data on another server from the client end and have both
sets of data behave as though they were in one transaction, not for one
server to put it's data on other servers.
Robert Munro