[mythtv-users] Conversion from single backend to new master/slave backend?

[Brian Guilfoos]

David Frascone wrote:
> 1) Move the database to a *third* server -- one with raid 5.
> 2) Move the tuner card(s) and firewire over to the "new" rackmount server.
> 3) Make the "old" server a storage / transcoding backend.  I could 
> possibly leave at tuner here too.
> 
> So - -what's the best way to do this?  Copy the entire database first?  
> (With mysqlbackup?  what's the best way to do that)?

I'd probably move the DB first.  Get mysql up and running on the new
machine.  Use mysql dump to back up the DB, and then copy that file over
to the new machine and reload that data.  Go around to each machine (er,
one right now), and make sure .mythtv/mysql.txt points at the new IP.
Shut down the old mysql server, and make sure everything still works.
If it does, you can probably go ahead and clean up the old server
(uninstall mysql, delete the old data files, whatever) if you like.

> Then what?  I'm assuming the newer box with mondo CPU's would be better 
> used as a full backend -- but -- if it'd be best to split tuners around, 
> I could do that too (I have a HDHomeRun, PVR_500, and a firewire card).  
> I'm expecing to have the rack-mount server (Dual xeon) be the master, 
> and the old backend (P4 - 2.4Ghz) be a slave. . . possibly with a tuner.

My master backend is an old Athlon 650MHz box, with a PVR500 and two
A180 cards, and it manages to record up to four things at a time
(streaming the data to an NFS server).  However, it's not beefy enough
to any kind of commflagging or transcoding, so my NFS server runs
mythjobqueue overnight to help process any queue backlog, and my
frontend (Athlon64 3400+) runs 24/7 to process the job queue (also
running just mythjobqueue, not the full-blown mythbackend).  My database
is also remote, on the NFS server.

Knowing what I know now, this is how I'll be upgrading in the future.

1) Migrate as many of the tuners over to the current frontend as I can
manage (don't think I have 3 free slots) and make it the new master
backend.  I'll probably continue to keep this a functional frontend (tho
rarely used).

2) Decommission the old backend.  If I need it for tuners, I'll keep it,
but see if I can get WOL working so it can shut down to reduce power
consumption except in high-volume recording periods.

3) Build a new storage system, separate from the current NFS server
(which will remain in commission as a TFTP/mysql server and nighttime
queue processor, in addition to it's non-myth duties) to fix disk
thruput issues. (I learned a lot about what NOT to do when I set up my
current 1.5TB LVM/RAID5 system on 8 250GB IDE drives, but I can't really
decommission the server to fix it since it provides home directories,
roaming windows profiles, a web server, and the mail server.  More RAM
fixed the most egregious error, but I'm still pushing it's performance.)

4) Build diskless frontends.

My goal is to make my system utilize as little power as possible, while
retaining 100% functionality at all times, and make it easy to maintain.
(Pick two, right? :) )  Given how little juice recording actually
requires, stuffing tuners in one box seems to make a lot of sense, and
that box should be able to process the job queue on its own, IMO.  I
like Athlons because of Cool'n'Quiet.

In your case, I'd go ahead and shove all the tuners in your master
backend.  That'll give you additional flexibility when it comes to
upgrading your P4 storage box.  Just run mythjobqueue on boot, and that
machine can process jobs too.

If you don't need the P4 to provide queue processing or tuner
capabilities, you might want to take a look at FreeNAS.  I'm planning on
trying it out for my next storage system - boots off of CD, stores it's
configuration to floppy, allowing 100% of the drive space to be used as
NAS.  Plus then you don't have yet another machine to upgrade whenever
you update your MythTV version.