[mythtv-users] sanity check or repairing DB for 0.22 upgrade.
Michael T. Dean
mtdean at thirdcontact.com
Thu Nov 19 01:20:56 UTC 2009
On 11/18/2009 08:09 PM, Alan Anderson wrote:
> Sanity check please.
> I have one master backend mythbackend version: 0.21.20080304-1 and three
> front ends. I have had the same data base for 5 or more years. Typically
> when I upgrade I backup /var/lib/mysql upgrade the version of fedora and
> restore /var/lib/mysql. So far it has always worked. I have backups of
> mythconverg but never needed them. I also run the script
> /usr/share/doc/mythtv-docs-0.21/contrib/optimize_mythdb.pl weekly.
> When I tried to install V0.22 I ran into the following scheme update issue.
> Query was:
> ALTER DATABASE mythconverg DEFAULT CHARACTER SET latin1;
> Driver error was [2/1283]:
> QMYSQL3: Unable to execute statement
> Database error was:
> Column 'filename' cannot be part of FULLTEXT index
> Every time I start a front end the error occurs.
> From my understanding this is issue where some UTF characters got into the
> data base when everything should be latin1. I need to do a partial restore
> to fix this. I need to fix the data base before I can upgrade to V0.22.
That's something very different. I'd bet you're running with MySQL
strict mode enabled (which is the default for MySQL on Windows)--which
will break Myth.
(and I'm 99% positive that even TRADITIONAL mode will break myth).
If not, the problem is just the way you restored with binary data
files. You should /always/ use a SQL-based mythconverg backup when
upgrading the MySQL server***.
Also note that dropping a 0.21-fixes database data files on top of a
0.22-fixes database schema's database files will break Myth. You need
to ensure you DROP the 0.22-fixes database (or otherwise remove it
***Yeah, I said "mythconverg backup," thereby implicitly excluding
backups performed by MySQL database admins on work database systems.
Basically, you have to know what you're doing /and/ what MySQL changes
occured to reliably do binary-file restores. There's no reason any
MythTV user should /ever/ be expected to do this, so just use SQL-based
More information about the mythtv-users