My approach is to have a master machine at station A which has, in addition to the Rivendell MySQL database, another MySQL database called Rivendell_sync that has just two tables: CART and CUTS. A Perl script runs every five minutes (via cron) and compares the contents of these two tables to their counterparts in the Rivendell database. When an addition or change is detected, the corresponding /var/snd file is uploaded to the other ("slave") machines, followed by a text file containing the contents of the relevant Rivendell CART and CUTS records. Then, the Rivendell_sync tables are updated to reflect the addition or change.
At each of the "slaves", another Perl script receives the uploads and updates the local Rivendell CART and CUTS tables accordingly.
I make no attempt to propagate deletions, but that capability would be easy enough to add.
Rob On Fri, 27 Apr 2012, Wayne Merricks wrote:
Hi all, I've been kicking this around the scary place that is my head for quite a while and thought I'd throw this over to the mailing list for any better ideas. Apologies for the length of the email, the brain dump got a bit out of control. What I'm trying to achieve is a way of continuing with on air play out in the case of a network failure. In this particular case its planned failure (my UPS has seen better days). Temporarily I can rsync the /var/snd from the server to the studio file system and then mysql dump (or slave replication) from the server to the studio. Edit the rd.conf file and kick airplay during a live link and nobody will notice. However it got me thinking about a more permanent solution by trying to make the default situation be that Rivendell plays locally at all times. MySQL: 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. I had a custom program made for call handling (really basic) a few years ago and when I set up a simple slave replicator I found that I couldn't do things like ordered SQL selects with limits e.g. ORDER BY id DESC LIMIT 1 as it broke the replication. Problems like this make me think multi master is a bad idea for Riv. /var/snd: Being lazy you'd want something like a continuous rsync. I looked into things like DBRD and Gluster FS but they all seem to have big warnings about shooting the other node in the head and I gave up at that point. Then I thought I would do something more intelligent. Have a "drop box" share on the server that is nothing to do with Riv. When this share receives files a daemon script copies it into the server /var/snd via rdimport. The output of this gives you the cart number (and as such the file name the cart has). After the import has finished the script then copies the file to each critical clients /var/snd. This has downsides, the time between the import and the copy (assuming MySQL replication happens right away) could potentially mean this would happen: "Hi presenter, I've imported the news for 12, please shove it into the play list" "OK" <presenter sees a nice big red cart with an audio problem as its still copying across> Would it be easier to just do snapshot updates once an hour (rsync and MySQL) and have some sort of script that tweaked rd.conf and kicked airplay whenever it noticed there was a network outage? Any DB activity during the outage would kill the slave replication so I'd probably have to script/manually repair the damage before replication continued. I could probably even script in a 30 second Station ID stored locally while the change was taking place so that Riv wasn't strictly needed. Just wondering if this is something anyone has seriously thought about? -- Wayne Merricks The Voice Asia 0121 522 6080 ____________________________________________________________________________ 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
