[mythtv-users] staging an upgrade 0.20 -> 0.23

[Michael T. Dean]

  On 01/05/2011 05:15 AM, Ross Camm wrote:
> with a two young boys who demand zero myth downtime, i am proposing the
> following ( lengthy ) staged major upgrade from 0.20 to 0.23....please
> tell me if it is completely insane  ;)
>
> Environment:
>
> dedicated backend on debian etch with mythbackend 0.20 installed using deb
> packages, and mythtv 0.23 installed from src under /usr/local
>
> MythTV Version   : 0.23.1
> MythTV Branch    : tags/release-0-23-1
> Network Protocol : 23056
> Library API      : 0.23.1.201000710-1
> QT Version       : 4.4.3
>
>
> dedicated various ubuntu 10.4 frontends with mythfrontend 0.20 installed
> from src under /usr/local ( opposite of backend above) and mythtv 0.23
> installed using ubuntu deb packages
>
> MythTV Version   : 24158
> MythTV Branch    : branches/release-0-23-fixes
> Network Protocol : 56
> Library API      : 0.23.20100314-1
> QT Version       : 4.6.2
>
>
> Proposal:
>
> I am preparing for major downtime due to the difference in the versions,
> 0.20 to 0.23.1, and the impact this may have current SLA's !...being a
> single parent and all !<violins>
>
> I am looking at:
>
> 1. backing up the current mythconverg 0.20 database using
> mythconverg_restore.pl...latest version 1.0.10

mythconverg_backup.pl , actually :)

> 2. restoring this to a different database..lets call it mythconverge23, on
> the same backend on the same mysql server
>
>  From what I can see, some manipulation of mythconverg_restore.pl ( latest
> version 1.0.16 ) and the database dump itself to replace mvythconverg with
> mythconverg23 should do the trick.

You /could/ just override the DB name with --DBName=mythconverg23 for 
the backup/restore program.  See:

/usr/local/share/mythtv/mythconverg_restore.pl --help --help

for the detailed help.

> 3. /usr/local/bin/mythtv-setup and configure for new database and new
> ports so I can run two instances of mythbackend, versions 0.20 and 0.23.
>
> I am not sure where it will search for mysql.txt first,

I recommend having a $HOME/.mythtv/config.xml and 
$HOME/.mythtv/mysql.txt that both have the same information.  Those 
should be used first.  You may want to create a different system user so 
you don't accidentally forget to put back the DB information for the 
production system.

>   but I should be
> able to figure that out from log files if I remove all existing instances.
> I also assume at this stage mythtv-setup is not actually writing data and
> will not touch existing mysql.txt files or the existing mythconverg
> database until changes are saved.

As soon as it's run, mythtv-setup will notice it needs to upgrade the 
database, back up the database, then tell you that it needs to upgrade 
the database.  It will then ask if you want to proceed.  If you say yes, 
it will start to change the database data and schema, as required.  
There's no going back--except via restoring an old backup--at this point.

> Is it at this point the database upgrade occurs once the config is saved
> from mythtv-setup ?
>
> 4. start /usr/local/bin/mythbackend with unique log file, PID file etc and
> ensure it is using a unique mysql.txt for the correct database,
> mythconverg23
>
> 5. start /usr/bin/mythfrontend version 23 on the frontend using its new
> mysql.txt and configure port number, and check all functionality other
> than recording, primarily being playback of existing recordings and plugin
> media, including 1080p...which is what this effort is all for ;)
>
> I will need to remove tuners i can foresee so that both mythbackends are
> not trying to record, but I can't see any other pitfalls of going down
> this 'staging' path so that I have adequate time to test all 23
> functionality on the upgraded ( or possibly new, depending on the upgrades
> success )
>
> This should then give me the ability I hope to gradually if possible
> migrate across, or at least take the wisdom learned from the staging
> environment, so surprises are kept to a minimum upon live
> upgrade...primary being in the untested recording department, which is
> tolerable due to the existing content available.
>
> any insights from others who may have some knowledge would be humbly accepted

I would say that trying to install MythTV twice onto a system is a very 
challenging proposition that leaves for a /lot/ of possibilities of 
problems.  I would generally recommend against it--to give you an idea, 
I have my "production" system of 3 MythTV hosts and a separate 
(physical) computer that I use for MythTV development.  It just wasn't 
worth the effort of trying to run 2 incompatible versions of MythTV on a 
single piece of hardware.

My recommendation--since you have multiple systems running MythTV--is 
that you "decommission" on of the systems, such as one dedicated 
frontend.  Upgrade that system (distro, MythTV, etc.), and restore the 
database locally to a MySQL database server on that system (separate 
host from the "real" mythconverg database) but using the "real" database 
name--making sure to set the appropriate hostname in mysql.txt or 
config.xml and to do a DB hostname change ( 
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Change_the_hostname_of_a_MythTV_frontend_or_backend 
).  Then, use that as a "test" system to verify that mythtv-setup will 
upgrade your database without character encoding problems, etc.  If so, 
then you can go ahead and remove that database, and upgrade your master 
backend and other systems.  If not, post a message, and I can help you 
with fixing the database encoding issues.  Then, once you have the fix 
from me, you can test to ensure that it will upgrade your DB, and then 
roll out the real setup on the master backend, etc.

I think with this approach, you'd have a) minimal downtime (however long 
it takes to upgrade the master backend and the most-critical frontend 
system), b) a much less confusing configuration to test--without a much 
lower possibility of accidentally upgrading the production database in 
place, and c) a test that the most-likely-to-cause-issues part of the 
upgrade (DB schema update) will work properly.

Again, running 2 (especially incompatible) copies of MythTV on the same 
host is a huge challenge--IMHO, not worth the effort, especially when 
trying to figure out a /very/ different version of MythTV.

Mike