Subject | Re: [Firebird-Architect] WAL and JOURNAL |
---|---|
Author | Olivier Mascia |
Post date | 2004-01-19T13:52:10Z |
Dear,
Thanks for this article on how WAL was originally designed.
On Mon, 19 Jan 2004 07:55:58 -0500,
Jim Starkey wrote :
sense ? A kind of master-slave remote on-line replication but at
page/system level, not at row/application level ?
Going even further, couldn't we even think (or is dream the right word ?)
of a kind of cluster-like configuration (basic "classic server" with distributed
lock manager), working on two replica of the DB (different physical
locations) instead of a common one ?
--
Best Regards,
Olivier Mascia
Thanks for this article on how WAL was originally designed.
On Mon, 19 Jan 2004 07:55:58 -0500,
Jim Starkey wrote :
> There were at least two problems with journalling. One was a measurableWould shadowing (and not journalling) to a *different* server make
> performance hit necessary to send page changes to the journalling
> server. The other, more serious, is that journal tapes fill up, so
> using journalling pretty much dictated hiring someone to watch the tape
> spin waiting for it to fill up. The availability of a 2.8 GHz super
> scalar processor with 100 MB ethernet, 512MB memory, and a 120 GB disk
> (yesterday's Sunday flyer's bargain) might have changed the tradeoffs.
>
> The other factor what the implementation of shadowing, not as robust of
> journalling to a different server, was almost as good and a lot easier
> to use.
sense ? A kind of master-slave remote on-line replication but at
page/system level, not at row/application level ?
Going even further, couldn't we even think (or is dream the right word ?)
of a kind of cluster-like configuration (basic "classic server" with distributed
lock manager), working on two replica of the DB (different physical
locations) instead of a common one ?
--
Best Regards,
Olivier Mascia