[RDD] Synchronizing carts and logs
waynemerricks at thevoiceasia.com
Mon Jun 13 14:43:59 EDT 2016
I use syncthing to handle the physical file transfers but thats the
easy bit. Its a judgement call how you want to update the DB after
that. You could set up slave replication in MySQL but then if you slave
client B to A and you write to B it all breaks.
Obviously CART/CUT info changes all the time (number of plays, last
played etc), you've also got either the _STACK or _SRT table used in the
play out reports, potential changes on the sound panels in airplay etc
If you could list out what you need replicating between the two, which
bits should always be the most current version on the master and which
bits your happy to leave as whatever is the newest time stamp I'm sure
you could do some MySQL bash/perl scripting magic to get it sorted but
thats the best I can come up with.
To be honest I kept it simple, I just overwrite the remote clients
every night with the home server database. I put in an exception for
the sound panels, the remote presenters use panels 11 - 20 and home is 1
- 10. That way I can do a dump of the panels table and re-insert after
the mysql import every night.
You do lose any remote files that were imported by drop box stuff
On 2016-06-13 19:26, Rob Landry wrote:
> I had a discussion with a Rivendell user in western New Hampshire
> this morning -- not one of my clients -- who said he wished Rivendell
> had the ability to transfer files with metadata seamlessly from one
> server to another, as (he claims) Wide Orbit and NexGen do.
> I mentioned that I wrote a couple of Perl scripts to do this
> (actually, one script handles files, while the other handles logs). I
> use the METADATA_DATETIME field in the CART table and the
> MODIFIED_DATETIME field in LOGS to determine which copy of a record
> more recent, and synchronize accordingly. The only hitch is that it
> isn't possible to delete a log or cart, since the time stamp for a
> record is deleted with the record. If we need to delete something, we
> must delete it manually from both machines simultaneously. While
> that's not a problem with just two servers, it might be a challenge
> were we synchronizing a dozen of them.
> What concerns me is upgrading to new versions of Rivendell and the
> need to go through both scripts to see if any changes have been made
> to the CART, CUTS, LOGS, or *_LOG tables that might break the
> If a future database schema omits, say, METADATA_DATETIME, one or
> both scripts might break irreparably.
> Is there a better way to solve the synchronization problem (say,
> through the Web interface)?
> Doing a database backup/restore once a day and rsync'ing /var/snd, as
> some have suggested, is impractical.
> I am curious how other RD users have approached this problem.
More information about the Rivendell-dev