[mythtv-users] What's the best way to restore a crashed MythTV 0.21 ?

[Michael T. Dean]

On 11/29/2009 06:29 PM, David Brodbeck wrote:
> Andrew Junev wrote:
>> Thanks for the hints! Maybe it was a bad idea, but I just copied all
>> the database files from my old system to the new one. Surprisingly, it
>> just worked "as is" - mysql picked up all the data and it seem to be Ok.
>> I then installed MythTV 0.22 from RPMFusion and ran mythtv-setup,
>> which upgraded my database to the new version.
>> And then mythbackend/mythfrontend just started normally.
>> Is it bad? Should I still drop the database and restart from scratch,
>> restoring only recorded programs?
>>   
> Nah, if it worked at all it should be fine.
>
> The reason for doing a text dump is it's possible that a new 
> installation of MySQL, especially on a different architecture, might 
> not be able to read the binary files from a different version of 
> MySQL.  In my experience it works more often than not, though.  As 
> long as MySQL doesn't complain about the database files you should be 
> fine. 

Agreed.  You're fine--as long as before the upgrade you read the, 
"Upgrading MySQL," section of the MySQL documentation and all of the 
documentation it tells you to read before upgrade and follow all its 
instructions and prerequisites (i.e. to upgrade from 3.23 to 5.1, 
upgrade to 4.0 then 4.1 then 5.0 and finally to 5.1) and do all the 
things required for a successful upgrade--including running the 
appropriate scripts to convert data from the old binary format to the 
new binary format.  http://dev.mysql.com/doc/refman/5.0/en/upgrade.html  
(In other words, there's a reason people who are MySQL database admins 
get paid to do the jobs they do.)

Or, you can just assume that the "magical package manager scripts" did 
everything properly (even the impossible upgrade series mentioned above).

Or--and this is my favorite--you can use a SQL-based backup, which 
always works.

Though, since it takes 30s to make a gzip-compressed SQL-based backup 
(23 of which is compressing it) and maybe about the same to restore it, 
I can see how you may be tempted by the binary restore procedure 
mentioned above.

(This isn't to say that what the OP did won't work--I'd need way more 
info to say anything for sure, and if it seemed to work...--however, I 
/am/ recommending that people who don't care to become qualified MySQL 
database admins just use the SQL-based backup/restore approach when 
upgrading MySQL in the future.)

Of course, I'm sure someone will pipe up to tell us all that, "I did it 
once and it worked, so my (one) real-world experience trumps Mike's 
the-docs-say-to-do-it-this-way, ominous-sounding, 
no-mention-of-specific-problems-you-can-encounter threat of potential 
problems."  But, whatever.  It's your data, so if it's good enough for 
you...

Mike