Good question. I would ask on the IB-architect (FB-Architect?) and
firebird-dev lists as well to try to get Jim Starkey's opinion.

Offhand, I think you might be able to do this with the 2pc, internal
transaction manager, and insert/update/delete triggers on all the master
db's tables. However I don't know if:

1. triggers/sp can perform operations on other db instances -- I would
guess you could write a UDF to do this if necessary

2. As I recall, Firebird kind of prefers you to specify all the db's in a
transaction when you start the tx. This is I believe actually required for
complete consistency, but may cause problems here. You may need to have
transactions specify in some way if they are read-only, in which case they
only start the tx on the single db they connect to, or rw, in which case
they have to start the tx on every machine in the cluster.

3. What happens if one db instance crashes (someone unplugs it's machine)?
You don't want the other nodes to keep waiting for it.

4. Is it possible to have any node be the master in some transactions?

Is this the hard part of clustering/ high availability? (The other part I
know of being the at the client, if the node you are connected to fails,
try another)


Thanks
david jencks

On 2002.04.18 22:36:35 -0400 Robert Munro wrote:
> 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
>
>
> Community email addresses:
> Post message: IBDI@yahoogroups.com
> Subscribe: IBDI-subscribe@yahoogroups.com
> Unsubscribe: IBDI-unsubscribe@yahoogroups.com
> List owner: IBDI-owner@yahoogroups.com
>
> Shortcut URL to this page:
> http://www.yahoogroups.com/community/IBDI
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>