If a distributed store-and-forward mechanism is required ...

Run a set of triggers that inserts key information for new/updated rows
into a submission queue table, ordered by timestamp (need to use
millisecond or finer granularity).

Run a parallel task that processes the data from the submission queue,
and forwards the rows from the database back to the central server ...
in near-real-time.

Since the information is stored in a table, if there is an outage
anywhere, no data will be lost. Transmission will resume once
everything is working, and systems will sync up.




If centralization is really the goal, and you can afford to have remote
sites shut down if there is a problem at the central site or the
communications, you might be able to get a larger box and run Classic.

Does anyone know if the issues with the 64 bit compiles were resolved?
If so, a big opteron or athlon X2 type system might be worth examining
(depending on your budget). Toshiba has announced plans to build
mainframe class systems around the Itanium, which will run Windoze or
linux.

On Fri, 2005-06-10 at 07:58 -0400, Steve Wiser wrote:
> Hi Mick,
>
> We are lucky enough to have a fairly stable backup window when the
> gdbs are put into shutdown which is when we rsync them over a T1 to the
> backup site. There definitely are days when the gdbs still sometimes in
> use and do result in a bad rsync copy which is something we are still
> working on...
> I was hoping that it would be magically possible to nfs mount a shared
> location on 1 server to host the isc4.gdb and point all of the other
> servers to it, but that definitely doesn't work as the lock managers
> seem to step on each other... Our UserManager app already posts each
> request into all of the dbs, but we sometimes run into problems were it
> didn't post properly in 1, but did in the other 22, so do we commit the
> rest? I guess I will keep on working on a solution for this. Just
> wanted to know how other Interbase/Firebird users handle this
> synchronization task.
>
> -steve
>
> On Fri, 2005-06-10 at 03:44 +0000, mikcaau wrote:
>
> > Steve,
> > I think (am sure) that you'll have problems with rsync.
> > rsync on databases will (almost) always catch the database in an
> > unstable state, some parts of a transaction will have been posted and
> > other parts will be yet to be posted. This is a recipe for disaster.
> > GBak works, GBak + zip or tar makes a small backup.
> >
> > To keep all your passwords in sync,
> > All I can suggest is that your usermanager be an additional
> > application that receives manage user activities and posts them onto
> > each of your servers.
> > Perhaps it would be possible to establish events on isc4.gdb and
> > intercept these events with a script that send the information to your
> > other servers - but I think you'd find that the password is already
> > encrypted.
> >
> > The first solution lokks easier.
> >
> > Mick
> >
> >
> >
> >
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Visit http://firebird.sourceforge.net and click the Resources item
> > on the main (top) menu. Try Knowledgebase and FAQ links !
> >
> > Also search the knowledgebases at http://www.ibphoenix.com
> >
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>