[mythtv] Developing database and program synchronization for remote frontend/backend

[Rob Smith]

On 4/14/07, Subbyz <subbyz at kinison.puremagic.com> wrote:
> On Sat, 14 Apr 2007, Rob Smith wrote:
>
> > Replication is perfectly valid solution. He might need to putz around
> > with a newer mysql and use the auto-increment offset magic, but that's
> > easy enough to do and would alllow both sides do schedule recordings
> > and have them sync up correctly and the like.
>
> I considered replication, but there is still a master-slave relationship,
> and I don't think it would always do the "right thing" when there was a sync
> conflict on certain rows in a table.  Plus, that would also require a fairly
> new version of mysql, and I'm not sure I like that requirement.

Actually, basic replication has been supported in mysql from the 3.x
versions, so to do just basic replication, it's a peice of cake. To
use the safe autoincrement method, you just need mysql 5.0.2 or newer
(see http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html
). You would want to setup a multi-master setup and it would just work
automagically and correctly all the time.

> I don't yet know that I particularily care about keeping the databases
> "consistent" such that recordid's or whatever match, I just want to make
> sure that changes in one are reflected in the other in a sane and safely
> syncable way.  Keeping them consistent might end up being the easiest path,
> but I'm not making that a design requirement, at least not yet.

If you delete id 5 on one and want that to sync, but it's id 7 on the
other, how would you handle that? And keep in mind, if you plan on
syncing your RV's db over to the home one without replication or the
like, any shows recorded on the home one would go poof, as it's a all
or nothing sync outside of the world of replication.

Really, a correct replication setup is the answer in my opinion. In
anycase, g'luck.

~Rob