Hi again, I'm pretty sure it was a SELECT statement that killed it but my memory might be off, its been 3 years since the program was used and about 4 since I made it. What annoyed me was that MySQL would just sit there reporting that the slave was waiting for a bin log update (this was before I knew about things like Nagios so the first I knew was a phone call from the India office moaning that things aren't updating).
Multi-master inserts can be quite simple but get very complicated very quickly the more nodes you have. In its simplest form its very easy, you have two nodes. Node A has its auto number entries starting at 1 and increments by 2 (all the odd numbers), hence node B has even auto numbers. With a bit of foresight you can do things like the following, auto number increments by 10. Server A starts at 1, then 11, 21 etc. Server B, 2, 22 etc Obviously this falls over with more than 10 nodes. You still have problems with updates and deletes though especially after a failure and this is where I'm not sure what MySQL does (in my experience MySQL generally goes into "hmm its all gone Pete Tong so I will sit here doing nothing until someone notices"). I haven't looked into the DB side of Riv in detail to figure out if the auto number field is critical to any part of it though. As you can have a situation where Server B not being used very often is sitting at auto number position 4 while Server A has already gone up to 213. Wayne Merricks The Voice Asia 0121 522 6080 On 30/04/12 11:38, Fred Gleason wrote: > 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 ####################### Scanned by MailMarshal ####################### ############ Attention: The information contained in this message is confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Christian Vision or any of its subsidiaries will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. Please note that we reserve the right to monitor and read any e-mails sent or received by the company under the Telecommunications (Lawful Business Practice) (Interception of Communications) Regulation 2000. Christian Vision is registered in England as a limited company 2842414 and as a charity 1031031 ############ _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
