Alex Peshkov wrote:

>> How? Shadow databases on NFS? With that architecture you'll still have
>> to delegate a master database to receive all write traffic and
>> communicate it to the clients... I've certainly not seen any such
>> solution documented...
>>
>>
>
>
> I don't mean load balancing - only want to continue serving requests
> after a hardware failure.
>
> Asymmetric cluster - two computers (master and slave) both have firebird
> installed, master normally running it, slave not. Slave's partition
> mounted by master (using - you are absolutely right - NFS), and database
> is mirrored to that partition. Cluster IP is assigned to master.
>
> Slave regularly checks, is master alive or not. In case when it decides
> (this is the most problematic part of the whole solution) that master is
> dead, it assigns cluster's IP to itself, starts firebird and is ready to
> answer queries with no committed transactions lost. Certainly, clients
> should reattach to the cluster in case of failure (clearing ARP cache),
> but for our purposes this is not a problem.
>
>

Note that this can be done also on Windows (when the remote shadows will
be implemented) and is blazingly fast (at 1Gbps is transparent) and,
also, rock solid at crash tests (details available on request - remote
shadows on Windows were tested on an experimental SS RC5 build for
Windows). Perhaps a better approach is to have on the client the
redirection engine. (On both servers the fbserver is running) Ie. in
TIBODatabase.OnError do something like:

if ErrorNo=<connection lost> then
if MessageDlg('Do you want to reconnect on the other server?')=mrYes
then

if BeginnsWith(<my registry key which holds the connection
string>, 'SERVER-A:') then
begin
<my registry key which holds the connection string> :=
'SERVER-B:\MyFDBDir\MyDatabase.FDB';
<activate shadow on SERVER-B> //requires gfix presence :-(
(more elegant would be an 'ACTIVATE SHADOW' command - no scary black
DOS windows, paths, switches...);
<Application.Restart>
end

IMHO, this is much more simpler, faster, platform independent and
doesn't introduce the side effects of changing the IP in the LAN.

hth,

m. th.