Open Source for mission-critical systems (slightly OT)

[Andrew Hammond]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lennart Sorensen wrote:
> On Thu, Jun 02, 2005 at 12:18:24PM -0400, Christopher Browne wrote:
> 
>>PostgreSQL doesn't yet have anything meaningful in terms of answers
>>for multimaster replication, but that represents a tough problem. 
>>(Albeit one where efforts are under way. 
>><http://www.slony2.org/wiki/index.php?title=Main_Page>)
>>
>>There have historically been several ways of doing single-master
>>replication, notably including:
>>- eRServer <http://gborg.postgresql.org/project/erserver/projdisplay.php>
>>- Mammoth Replicator
>><http://www.commandprompt.com/products/mammothreplicator/?page=products&item=mammothpostgresql>
>>- Slony-I <http://slony.info/>
> 
> 
> Certainly 3 or 4 years ago none of them were capable enough to really be
> called live replication.  Some even required adding all sorts of
> triggers and mess to yoru database whenever you created new tables,
> which was asking way too much when you were trying to keep things
> portable to another database if necesary.

Mammoth Replicator has always been transparent (or nearly so) IIRC.
Beyond the most trivial applications, inter-database portability does
not exist.

http://www.powerpostgresql.com/Downloads/database_depends_public.swf

And that's the PHB friendly version.

> If a database goes down, the applications (clients) should be using the
> other one without really noticing anything had happened.  When I looked
> at the solutions in opensource 3-4 years ago, nothing existed so we did
> the best we could with only one live database.

That requires synchronous replication. Oracle RAC for example. Unless
you're willing to allow for committed transactions to be lost on
failover. To do RAC properly, you better forget running it on some pissy
little quad Xeon box.

And for those of you who think a quad xeon wasn't a pissy little box 3
or 4 years ago, we're talking about database servers here. Anyone who'd
spec a quad xeon for database work is clearly incompetent. The Xeon's
FSB architecture (even for NUMA Xeon systems) has totally insufficient
IO capacity for serious database work.

- --
Andrew Hammond    416-673-4138    ahammond-swQf4SbcV9C7WVzo/KQ3Mw at public.gmane.org
Database Administrator, Afilias Canada Corp.
CB83 2838 4B67 D40F D086 3568 81FC E7E5 27AF 4A9A

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCn0zMgfzn5SevSpoRAr4NAKDAX3mpXnijdSlc7Bg/yFbPGlNIZACgv7tO
my30r+lR6cPkTM9zZa7TpKM=
=46Bj
-----END PGP SIGNATURE-----
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml