Date: Thu, 5 Mar 1998 10:11:35 -0100 (GMT) From: Remy NONNENMACHER <remy@synx.com> To: Simon Shapiro <shimon@simon-shapiro.org> 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... Message-ID: <Pine.A32.3.91.980305095428.16895P-100000@rs1> In-Reply-To: <XFMail.980304155830.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.A32.3.91.980305095428.16895P-100000>