[Solved] Upgrade Plan

For discussion related to MythTV which doesn't belong in another forum.

Moderator: Forum Moderators

Post Reply
gpw928
Junior
Posts: 19
Joined: Tue Feb 12, 2019 5:59 am
Location: Rural NSW
Australia

[Solved] Upgrade Plan

Post by gpw928 » Tue Mar 10, 2020 1:38 am

Hi,

My "MythTV Upgrade and Database Conversion Plan" is below.

I'd appreciate any comments so it can be left here for those who follow. I'm particularly interested in maintaining the integrity of the database and recordings at all times (so I can safely retreat, if required).

Code: Select all

The MythTV server has two disks.

The old disk runs MythTV fixes/0.27 on Debian 8.
The recordings are kept on NAS NFS mounted to /var/lib/mythtv.

The new disk runs MythTV fixes/0.30 on Debian 10.
The recordings are kept in the local directory /var/lib/mythtv.

The new Debian 10 MythTV server is tested and working with a new mysql
database that's pretty much empty.

The plan is to:

  - dump the mysql database on the old server;
  - shut down the old server;
  - NFS mount the recordings on the new server; and
  - restore the mysql database to the new server.

1.  Boot the "old" MythTV server.

2.  Shut down MythTV, and disable it:

      # Exit from any running MythTV frontend(s).
      sudo systemctl stop mythtv-backend
      sudo systemctl disable mythtv-backend
      sudo systemctl mask mythtv-backend

3.  Backup the database:

      # As myself (this is what runs from my crontab daily)
      mythconverg_backup.pl # (the version that came with fixes/0.27).

4.  Save all the backups (there's a rotation of 5 of them) for posterity:

      # As myself
      mkdir -p ~/MyMythTVdb_backups
      # This copies the backups from NAS to local disk
      cp -p /var/lib/mythtv/db_backups/* ~/MyMythTVdb_backups

5.  Prevent the "old" MythTV server from touching the recordings, ever again:

      # Comment out the NFS mount of /var/lib/mythtv

      # Unmount the recordings, permanently
      sudo umount /var/lib/mythtv

      # Disable the database
      sudo systemctl stop mysql
      sudo systemctl disable mysql
      sudo systemctl mask mysql

6.  Shut down the "old" MythTV server, permanently.
    
      sudo shutdown -h -P now

7.  Boot the "new" MythTV server:

      # We expect that mysqld will start.
      # Exit from any running MythTV frontend(s).
      # Then stop and disable the backend.
      sudo systemctl stop mythtv-backend
      sudo systemctl disable mythtv-backend

8.  NFS mount /var/lib/mythtv on the "new" MythTV server:

      # Ensure that /tank/mythtv is exported correctly from the NFS server.
      # Edit /etc/fstab to mount /var/lib/mythtv from the NAS
      # sherman10:/tank/mythtv /var/lib/mythtv \
      #     nfs rw,async,bg,hard,intr,noatime,nodiratime,proto=tcp 0 0
      sudo vi /etc/fstab
      sudo mv /var/lib/mythtv /var/lib/mythtv.orig
      sudo mkdir /var/lib/mythtv
      sudo chmod 111 /var/lib/mythtv
      sudo mount /var/lib/mythtv

      mount | grep "/var/lib/mythtv" | grep -q nfs || echo "REPEAT STEP 9!"

9.  Fix file ownership of the recordings
    (this because the old recordings had inappropriate uid:gid):

      sudo chown -R mythtv:mythtv /var/lib/mythtv
      (Faster on the NFS server: "sudo chown -R 124:130 /tank/mythtv")

10. Recover the mysql database from the "old" MythTV server:

      # Using my own account and mythconverge_restore.pl from patches/30
      echo "DBBackupDirectory=/var/lib/mythtv/db_backups" > ~/.mythtv/backuprc
      mythconverg_restore.pl --drop_database --create_database \ 
        --filename $(ls -dtr /var/lib/mythtv/db_backups/mythcon* | tail -1)

11. Update the host name in the datanase

      mythconverg_restore.pl --change_hostname --old_hostname="myth" --new_hostname="mith"

12. Re-enable and start up the MythTV backend:

      sudo systemctl enable mythtv-backend
      sudo systemctl start mythtv-backend

13. Verify the setup (Primary IP Address on Master Backend
    reverted to 127.0.0.1 when I did the upgrade)

      - The mysql bind address = 0.0.0.0 (all interfaces)
	See /etc/mysql/mariadb.conf.d/99-mythserver.cnf above
      - The backend mythtv-setup shows:
	    Security PIN: 0000
	    Allow connections from all subnets: Yes
	    Listen on all IP addresses: Yes
	    Primary IP Address/DNS name: 192.168.1.28
	    This server is the Master Backend: Yes
      - Local frontend is configured with the database on "localhost".  Works.

      - Remote frontend legend (192.168.1.35) is configured with the database
	on "192.168.1.28" (mith).  Works.

14. Retire the old server (myth) and the old remote frontend (legend).
    Add the new server (mith) and new frontend (fable) to the backup schedule.
This plan worked.
Last edited by gpw928 on Mon Mar 16, 2020 4:21 am, edited 4 times in total.

User avatar
bill6502
Developer
Posts: 1463
Joined: Fri Feb 07, 2014 5:28 pm
United States of America

Re: Upgrade Plan

Post by bill6502 » Tue Mar 10, 2020 1:41 pm

I don't see mention of keeping the hostname of the new server the same as the old.
That would make life easier. And, it appears that you don't plan to have both booted
up at the same time.

For 11, you could create a backup of the newly installed DB and then
compare the file size with that of the one restored from. Or, even gunzip
both and diff the files. There will be timestamp(s?) that are different, but
that should be easy to spot/ignore.

I just fire up mythtv-setup and make changes as required, then run the backend
and look at the logs (after a new recording and watching something old.)

gpw928
Junior
Posts: 19
Joined: Tue Feb 12, 2019 5:59 am
Location: Rural NSW
Australia

Re: Upgrade Plan

Post by gpw928 » Wed Mar 11, 2020 1:24 am

Thank you Bill. Well spotted.

I have modified the plan, and will leave it for a day or so before executing.

If I strike issues I'll modify it to reflect what actually happened.

gpw928
Junior
Posts: 19
Joined: Tue Feb 12, 2019 5:59 am
Location: Rural NSW
Australia

Re: Upgrade Plan

Post by gpw928 » Mon Mar 16, 2020 4:21 am

I have now completed the upgrade, and modified the plan above to reflect exactly what I did.

In the end it was a lot easier to use the new IP addresses, as keeping the old ones meant a lot of work with ssh keys.

Post Reply