There's always the single master with local spool caching. Slave DB's are read only, and writes are always done to the master. However if the master is unavailable, writes are spooled locally until the master returns to online status. This would require a bit more expansion of the codebase to implement, as it is an application in and of itself. However, if Rivendell were expanded to utilize this method, and checked for related locally-spooled events (when the master-unavailable flag is set), it would survive any outage and gracefully re-sync on recovery.
The local spool would just be another DB on the same mysql instance with a table structure to hold queued commands/events and statuses. 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. >>> In theory I could set up a multi-master MySQL between the server and >>> critical studios. You can offset auto-numbers to alleviate race conditions >>> on record inserts however I don't know enough about MySQL to know how it >>> handles updates/deletes and how well/badly it recovers from a network loss. >>> >>> Problems like this make me think multi master is a bad idea for Riv. >> On the contrary, I think master-master replication is a perfectly viable >> approach. The trick is to ensure that any active RD systems are using only >> one of the pair for INSERT/SELECT queries at any one time. Basically, this >> means a 'watchdog' process on each MySQL instance with redundant heartbeat >> links to all other watchdogs, along with logic to elect a one-and-only >> 'online master' and transmit that information to the clients in a timely >> manner. Both failover and recovery are easy then -- just change the current >> 'online-master'. >> >> _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
