[mythtv-users] upgrading MySQL
Michael T. Dean
mtdean at thirdcontact.com
Fri Apr 3 19:57:38 UTC 2009
On 04/03/2009 03:16 PM, David Brodbeck wrote:
> On Fri, April 3, 2009 8:26 am, Michael T. Dean wrote:
>
>>> So the bottom line on copying binary databases is: Maybe. But the
>>> standard advice of making backups with mysqldump definitely holds. You
>>> certainly cannot count on being able to read binary database files from
>>> a system backup, as I have learned the hard way at the cost of several
>>> evenings' worth of effort.
>>>
>> And, IMHO, why waste the time trying (and not being /absolutely/ certain
>> all your data is good) when all it takes for peace of mind is a simple
>> backup and restore? (Where the backup and restore are both easy with
>> the backup/restore scripts. :)
>>
> The main reason you see people doing binary backups is speed. On a large
> database running mysqldump can take tens of minutes, and during that time
> all the tables are write-locked, effectively making the database unusable
> until the backup is complete.
>
While true, this is /never/ a problem for MythTV as the database is
never large***. In my system I have 777 MPEG-2 HDTV recordings and my
binary database is 325MiB and takes only 1min 12sec real time to backup
on my Athlon XP 2400+ using the official backup script, which also gzip
compresses the backup (down to just under 50MiB).
$ time /usr/local/share/mythtv/mythconverg_backup.pl
real 1m11.621s
user 0m45.159s
sys 0m6.697s
If I told the script not to compress the file****, it only takes 32sec:
$ time /usr/local/share/mythtv/mythconverg_backup.pl --compress none
real 0m31.211s
user 0m11.447s
sys 0m5.675s
So, if my pathetic backend hardware can backup my
large-by-MythTV-standards mythconverg database in 30 seconds, skipping a
backup of the Myth database won't save anyone any time--it will likely
just waste a ton of their time when they a) try to get things working
again, and b) fail and have to go back to making a backup of the old
stystem to restore.
Basically, Myth databases won't get large enough for anyone to need to
consider doing a binary file copy. :)
Mike
***Remember, this /is/ the mythtv-users mailing list--not MySQL-users.
****Note, the above command is actually telling the backup script to use
the system command "none" to perform the compression--it's not saying
not to compress it. However, since the script is unable to execute a
command called "none" on my system, it doesn't compress the file. So,
if you want to do a backup and do not want compression, do /not/ specify
"--compress none" if you actually have a command in the PATH whose name
is "none". Instead use something else you /know/ you don't have. Guess
maybe I should special case "none" and/or "no" and/or "uncompressed" as
a compression mechanism for no compression.
More information about the mythtv-users
mailing list