From owner-freebsd-hackers Thu Mar 5 02:23:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id CAA20238 for freebsd-hackers-outgoing; Thu, 5 Mar 1998 02:23:27 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id CAA20217 for ; Thu, 5 Mar 1998 02:23:12 -0800 (PST) (envelope-from remy@synx.com) Received: from s3.synx.com (s3 [192.1.1.247]) by bsd.synx.com (8.6.12/8.6.12) with SMTP id LAA00108; Thu, 5 Mar 1998 11:27:02 +0100 Received: from rs1 by s3.synx.com id aa04974; 5 Mar 98 11:12 GMT Date: Thu, 5 Mar 1998 10:11:35 -0100 (GMT) From: Remy NONNENMACHER To: Simon Shapiro cc: sbabkin@dcn.att.com, wilko@yedi.iaf.nl, tlambert@primenet.com, jdn@acp.qiv.com, blkirk@float.eli.net, hackers@FreeBSD.ORG, grog@lemis.com, karl@mcs.net Subject: RE: SCSI Bus redundancy... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 4 Mar 1998, Simon Shapiro wrote: > > On 04-Mar-98 sbabkin@dcn.att.com wrote: > > ... > > I have a better solution, which was implemented here at my work (and I'll > repeat if my employer ahd the guy that wote it do not contribute it); > This is NOT my original idea, but so old I do not remember who did it first; > > You start with two identical databases. You modify the (postgres) libpq, > or (Oracle) SQL*Net interface to intercept all data-modifying SQL > statements (you do not care about SELECT and such). You cache those until > you see a COMMIT. If you see a ROLLBACK, you discard all that cache. > When you capture the SQL statements, you stamp each with a high precision > time stamp (does not have to be accurate, but has to be precise). When you > see a COMMIT, you ship the whole thing to a remote machine. The remote > machine can simply log these, or apply them against a reference database. > If you just logthem, you sort them by the timestamp before you apply them. > The quality of the resultant database is surprisingly good. Especially for > an OLTP system. the advantages are obvious. > And what about sending all packets to two RDBMS at the same time and dropping one of the results when it come back?. Instead of having only a copy, you can also have fault tolerancy since if one machine goes down, you simply send the result from the other ? (Would probably need clock synchonisation and on random numbers that can be generated by either machine and a physical DB copy before starting). Surely their is a lot of applications that can be forked/merged like this from a network point of vue. (I remember seeing something about equaly MACed NICS with one machine listening the result of the other and the two machine running the same program (using a lightly synchronised kernel)). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message