Rivendell 2.0.2 and up has support for replicating parts of the DB to remote sites but I'm not sure if that includes support for replicating to another Rivendell install just yet. That'd be the best way to do it, I suspect, if that works.
Aside from that - why not just do replication? Have your transmitter sites be read-only MySQL clones of the studio. If you need write access (ie for logging) then have two MySQL servers and MySQL Proxy in front to direct read/writes of the CUTS/CART tables to the read slave from the studio and the rest to your local server, or you could simply have them run a local server slaved to the studio for reads, with writes directed at the server in the studio. You can copy up any changed data with rsync every so often, or even better, use unionfs with copyup mode to have data streamed from the studio to the TX sites then stored on the TX site, using NFS/SMB to handle accessing the data acrosss the WAN, assuming sufficient bandwidth exists. This may not be feasible on slower links, of course. The benefits of doing things this way are that you're less likely to suffer from inconsistencies as a result of script errors or changes in the middle of script runs. You'll have everything on the same logical network, and faults should be quite easy to diagnose and fix. It's a little more complexity, but it's a bit more off-the-shelf than a bunch of custom DB extensions and shell scripts, which could be tricky to maintain longer-term. In principle I think your way would work, though I'd probably have the script keep its own DB away from the Rivendell DB for simplicity's sake and to stop it being an issue when doing DB upgrades. Cheers, James Harrison On 12/01/2012 23:17, Rob Landry wrote: > One of my clients runs a Rivendell system at each of his stations' > transmitter sites. Currently he uploads audio files to drop boxes at the > sites where they get rdimported; but now he wants to use rdlibrary to > produce cuts in his studio, so I need to figure out how to move the cuts > and their associated metadata from one database to another. > > My current thought is to create a "Rivendell_sync" MySQL database on the > production file. It will have a copy of the CUTS table, and a script will > wake up periodically and scan this table and the one in the Rivendell > database for differences. When it finds one, it will know that a cut has > been added or changed, and it will copy the corresponding audio file to > the transmitter site(s) associated with its Rivendell group. Then it will > send a text file containing the dumped contents of the CART and CUTS > record for the cut in question. > > At the transmitter site, another script will check the incoming text file > against the CUTS and CART tables in its own Rivendell database. If they > are different, it will plant the incoming audio file in /var/snd and > update the two tables with the data from the text file. > > My questions of y'all is: does this make sense? What are the potential > pitfalls? Is there a better way to do this? > > Thanks, > > > Rob > > _______________________________________________ > Rivendell-dev mailing list > [email protected] > http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev _______________________________________________ Rivendell-dev mailing list [email protected] http://lists.rivendellaudio.org/mailman/listinfo/rivendell-dev
