Open Source for mission-critical systems (slightly OT)

[David Thornton]

I try to stick with silly database work instead of serious database work..
works for me everytime

david

Andrew Hammond wrote:

>-----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
>  
>

-- 
Let one walk alone,
commiting no sin with few wishes,
like an elephant in the forest.

--
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