Another concern I have with multi-master systems is what happens if the network splits in 2 so that 2 master systems are taking commits for 2 separate sets of clients. It seems to me that to re-sync the 2 databases upon the network healing would be a very complex task or impossible task.
On Sunday 15 December 2002 04:16 am, Al Sutton wrote: > Many thanks for the explanation. Could you explain to me where the order or > the writeset for the following scenario; > > If a tranasction takes 50ms to reach one database from another, for a > specific data element (called X), the following timeline occurs > > at 0ms, T1(X) is written to system A. > at 10ms, T2(X) is written to system B. > > Where T1(X) and T2(X) conflict. > > My concern is that if the Group Communication Daemon (gcd) is operating on > each database, a successful result for T1(X) will returned to the client > talking to database A because T2(X) has not reached it, and thus no > conflict is known about, and a sucessful result is returned to the client > submitting T2(X) to database B because it is not aware of T1(X). This would > mean that the two clients beleive bothe T1(X) and T2(X) completed > succesfully, yet they can not due to the conflict. > > Thanks, > > Al. > > ----- Original Message ----- > From: "Darren Johnson" <[EMAIL PROTECTED]> > To: "Al Sutton" <[EMAIL PROTECTED]> > Cc: "Bruce Momjian" <[EMAIL PROTECTED]>; "Jan Wieck" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > "PostgreSQL-development" <[EMAIL PROTECTED]> > Sent: Saturday, December 14, 2002 6:48 PM > Subject: Re: [mail] Re: [HACKERS] Big 7.4 items - Replication > > > >b) The Group Communication blob will consist of a number of processes > > which > > > >need to talk to all of the others to interrogate them for changes which > > may > > > >conflict with the current write that being handled and then issue the > > >transaction response. This is basically the two phase commit solution > > with > > > >phases moved into the group communication process. > > > > > >I can see the possibility of using solution b and having less group > > >communication processes than databases as attempt to simplify things, > > > but this would mean the loss of a number of databases if the machine > > > running > > the > > > >group communication process for the set of databases is lost. > > > > The group communication system doesn't just run on one system. For > > postgres-r using spread > > there is actually a spread daemon that runs on each database server. It > > has nothing to do with > > detecting the conflicts. Its job is to deliver messages in a total > > order for writesets or simple order > > for commits, aborts, joins, etc. > > > > The detection of conflicts will be done at the database level, by a > > backend processes. The basic > > concept is "if all databases get the writesets (changes) in the exact > > same order, apply them in a > > consistent order, avoid conflicts, then one copy serialization is > > achieved. (one copy of the database > > replicated across all databases in the replica) > > > > I hope that explains the group communication system's responsibility. > > > > Darren > > > > > > > > > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 5: Have you checked our extensive FAQ? > > > > http://www.postgresql.org/users-lounge/docs/faq.html > > ---------------------------(end of broadcast)--------------------------- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
