On Apr 30, 2012, at 04:36 57, Benjamin D. Fillmore wrote: > When writes to master fail, it triggers the unavailable flag. Which > sets Rivendell to write only to spool DB, and launches daemon to > periodically check for the master. Once master is back online, that > daemon flushes the spool to master, resets the flag, checks for any > entries in spool as a result of a race condition, processes them, and > exits gracefully.
Ok, now imagine that we have two workstations (or three, or six, or 'N'), each of which fails over to its respective 'spool' DB instance. While in that mode, they each make different, mutually contradictory changes to the DB. Now we'd need a way to resolve all of that as part of the recovery process. Failover is easy. It's the *recovery* that's the nasty part. Architecturally, my current thinking is a pair of MySQL instances in 'master-master' replication, with some application logic to ensure that only one get's written to at any time. If *both* of those fail, we could still have a 'doomsday' mode that would permit operation from a local MySQL instance on each workstation, but I don't see a way to support automatic recovery from that state -- any changes made to the various local DBs while in that mode would basically be lost (or require manual re-integration by a DBA, which takes it outside the scope of automatic failover). Cheers! |-------------------------------------------------------------------------| | Frederick F. Gleason, Jr. | Chief Developer | | | Paravel Systems | |-------------------------------------------------------------------------| | "No, `Eureka!' is Greek for `This bath is too hot!'" | | -- Dr. Who | |-------------------------------------------------------------------------| _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
