[mythtv-commits] Ticket #4613: Backup database before schema upgrade

[MythTV]

#4613: Backup database before schema upgrade
----------------------------------------------+-----------------------------
 Reporter:  sphery <mtdean at thirdcontact.com>  |       Owner:  ijr    
     Type:  patch                             |      Status:  new    
 Priority:  minor                             |   Milestone:  unknown
Component:  mythtv                            |     Version:  head   
 Severity:  medium                            |     Mlocked:  0      
----------------------------------------------+-----------------------------
 The attached patch, mythtv-database_backups_before_upgrade.patch, adds
 functionality to automatically backup the user's database before a
 database schema upgrade.  Note that the current implementation will /only/
 backup the DB if the schema needs to be upgraded.  The fact that a backup
 is being created and its location is written at VB_IMPORTANT level, so it
 should show in the user's log.

 Users may define the location for the backups with the specially-named "DB
 Backups" storage group.  If there is no "DB Backups" storage group, the
 "Default" storage group will be used.  If a user upgrades from a version
 of Myth that did not support StorageGroups, the StorageGroup code will
 fall back to using the old RecordFilePrefix (the upgrade from 0.20 is
 untested, but the code in StorageGroup seems to indicate it will work).

 If the "DB Backups" or "Default" storage group is used and the user has
 specified multiple directories in the storage group, the backup will be
 written to the directory with the most free space.  Users who always want
 the backup written to a specific directory (i.e. to use an external
 rotation or archiving script) should define a "DB Backups" storage group
 with a single directory.  Note that the first backup when upgrading from a
 version of Myth before storage groups was added (i.e. 0.20) will have to
 be moved to this directory, then a "DB Backups" storage group can be
 defined for all future backups.

 The backup filename will use the format <dbName>-<dbSchemaVer>-<time>.sql.
 The time format is the same as is used by the recording files.  This
 should allow for easy sorting and rotation.

 The patch also modifies the recently-added DBMS version check in
 UpgradeTVDatabaseSchema() (in dbcheck.cpp) to use the new
 DBUtil::CompareDBMSVersion() and DBUtil::GetDBMSVersion().  The new
 functions are significantly more robust as the MySQL server version string
 does not always fit the Major.Minor.Point format (i.e. it could be
 something like 5.0.44-standard or 5.0.44-enterprise-gpl, or may have even
 been changed to something unrecognizable by the person/packager who
 compiled the MySQL server--all of which will result in the unpatched
 version refusing to run).  The DBUtil functionality simply parses the
 string and assumes the first digits found are the major version, the
 second digits are the minor version, and the third digits are the point
 version.  It will also allow (appropriate) version comparisons if minor
 and/or point versions are not found.  For those cases where even this
 won't work, there is an "undocumented" setting, "DBMSVersionOverride,"
 users can manually add to their DB to allow Myth to continue to work
 (though this is not intended to allow using MySQL 4.x with Myth versions
 that require 5.x or above).  For a user running a MySQL 5.0.44 version
 with an unrecognizable version string, the "DBMSVersionOverride" setting
 should get the data "5.0.44".

 Though DBUtil::GetTables() is not currently used, it will be used in an
 upcoming patch (to detect crashed tables and put warnings in the logs, as
 well as by the code that will eventually do automatic OPTIMIZE/ANALYZE on
 all tables and/or REPAIR crashed tables when the DB is sufficiently idle).

 The backups currently rely on the MySQL client program, mysqldump.  If it
 is not installed on the system from which the schema upgrade is being
 requested (i.e. the master backend), the backup will fail and a log
 message will be logged suggesting the user exit before the database
 upgrade and backup the database.  Exiting will only be possible if the
 user is being prompted for the schema upgrade (i.e. not in non-interactive
 shells).

 I've actually got a 90% complete patch for doing the backup without
 mysqldump (using queries against the DB).  If there's any way the backup
 functionality is going into 0.21, I would recommend we use the mysqldump
 version (or at least only include the "native SQL" backup as a fallback if
 the mysqldump program is not available or fails).  Since mysqldump has
 been tested by a lot of MySQL users and since the mythtv automatic backup
 will probably receive little actual testing (i.e. the backup won't
 actually be used to restore databases /that/ often), having a known
 working backup implementation would be a good thing.  I think a
 potentially-buggy backup implementation is worse than having no backup
 implementation at all.  If desired, I will complete the native SQL backup
 approach and add it as a fallback.

 Unfortunately, this patch does not modify the schema version, so there is
 no visible effect after its application.  An easy way to test is to move
 the "if (!dbutil.BackupDB())" clause up 3 lines (to just above "if (dbver
 == currentDatabaseVersion)").

-- 
Ticket URL: <http://svn.mythtv.org/trac/ticket/4613>
MythTV <http://svn.mythtv.org/trac>
MythTV