[mythtv-users] DB charset pre-conversion test failed! Your database seems to be partially corrupted.

[Michael T. Dean]

On 11/09/2009 10:04 AM, Tom Dexter wrote:
> On Mon, Nov 9, 2009 at 8:54 AM, Brian J. Murrell <brian at interlinx.bc.ca> wrote:
>   
>> On Sun, 2009-11-08 at 22:25 -0500, Michael T. Dean wrote:
>>     
>>> Most likely the same problem as:
>>> http://www.gossamer-threads.com/lists/mythtv/users/406111#406111 (which
>>> was missing tables).  Same solution, too.
...
>> This really is a bug that needs to be fixed in the upgrade, IMHO.  I am
>> at least the second person to run into it and making people have to grub
>> through the database and lose all of their setting just to upgrade is
>> not nice.
> If the problem is in fact from missing tables, that's a serious issue.
>  I can't imagine the schema upgrade handling such a thing gracefully.
> It looks to me like the 1214->1215 upgrade is doing an alter table to
> like 44 tables.  Accounting for a missing table would mean that every
> one of those would have to check for the existence of the table first
> and then recreate it in proper 1214 form if it wasn't there.
>   

Exactly.  Not to mention the fact that all the data that references 
other tables or that's referenced from other tables would have to 
somehow be invented and linked up.

> If more than a tiny handful of people had this happen, I'd be curious
> as to what caused it in the first place.  A missing table caused by a
> mysql crash or the like, that doesn't show up as an issue earlier
> seems like something that should be really rare.
>   

Exactly.  It could be missing for a variety of reasons.

a) The table was crashed when the user did a backup of her 0.21-fixes 
database, so it wasn't backed up
b) The user decided that he would "optimize" his MySQL database by 
changing certain tables from the MyISAM storage engine to the InnoDB 
storage engine, then backed up his 0.21-fixes database (which has the 
instructions to create the table using the InnoDB storage engine), and 
restored the backup into a database server on which the distro was kind 
enough to disable the "unnecessary/RAM-consuming" InnoDB storage engine
c) The table was corrupt and mysqlcheck was unable to repair it, so the 
user just deleted it and didn't see any problems so figured she had fixed it
d) The user accidentally deleted the table
e) The user at some point in the past did the backup/restore thing 
mentioned above and has been running without that table (and getting 
tons of error messages in his logs) since then
f) The user had problems with his DB schema in the past, and /rather 
than fixing the problem properly/ (as my suggestion would do), he 
decided to just hack at the DB/schema until he saw no signs of the issue 
he had noticed (but left other brokennes in place)
g)...

> If you want to try and determine what might be missing you can do:
>
> mysql -umythtv -p mythconverg -e 'show tables' > list_of_tables.txt
>
> ...and I can compare it to my 1214 database.

Again, finding out what tables are missing would likely only lead the OP 
to fixing the one, extremely /major/ issue noticed so far.  If there are 
other issues that aren't noticed during the upgrade, his system will be 
broken, will likely be less stable than a system using the schema/data 
for which the application is designed, and may be missing critical 
information/data and/or linkage to other data in the database.

Mike