Myles

Consider usage of IB_Replicator - out of the box tool that will do
bi-directional replication. You should only prepare metadata for that -
adding a column to primary key that will indicate the server. Then
replicator will copy only 'local' records to other servers.
Authors of IB_Replicator should be very helpfull in your case... Try to
contact them..

My 0.02$
Marcin

W dniu 09.03.2011 18:11, Myles Wakeham pisze:

> We have a mission critical PHP based system that uses a Firebird SQL
> back-end. Works brilliantly and has for many years. This is hosted on
> a CentOS server with FB 1.5 (will update FB versions soon to later
> releases).
>
> Due to high demand, we are going to need to create multiple server
> 'nodes' for the system using a DNS load balanced setup. As a result,
> servers that run PHP will be located in different geographic regions,
> sometimes in different countries. The DNS failover capability will
> ensure that at least one server is available for any incoming request.
>
> Although this is relatively painless to setup for general PHP/Apache
> operation, it isn't as simple with the database. I'd like to adopt a
> common approach that MySQL databases& high demand PHP apps seem to do,
> and that is that updates to the database are immediately replicated to
> all node systems, which have their own separate Firebird database on
> them. In this way, each node is self-contained. If a node is down,
> however, I need to find a way to identify changes that were made to a
> 'master' server, that didn't complete replication to a number of slave
> node servers.
>
> Is anyone doing this sort of thing in similar technologies that we use?
> If so, how have you chosen to do it? Should I build all of this
> technology myself, or are there any pre-written systems that do
> replication that already are considered 'bullet proof' that I should be
> considering evaluation?
>
> Thanks in advance for any feedback.
>
> Myles