<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 30, 2014 at 7:20 PM, Tom Lichti <span dir="ltr"><<a href="mailto:tom@redpepperracing.com" target="_blank">tom@redpepperracing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Sep 30, 2014 at 7:57 PM, Brian S <span dir="ltr"><<a href="mailto:inanimatecrbnrod@hotmail.com" target="_blank">inanimatecrbnrod@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/27/2014 05:21 PM, Tom Lichti wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sat, Sep 27, 2014 at 3:56 PM, Brian S <<a href="mailto:inanimatecrbnrod@hotmail.com" target="_blank">inanimatecrbnrod@hotmail.com</a> <mailto:<a href="mailto:inanimatecrbnrod@hotmail.com" target="_blank">inanimatecrbnrod@<u></u>hotmail.com</a>>> wrote:<br>
<br>
<br>
Next, I was able to get the mysql daemon to start by adding the<br>
"innodb_force_recovery = 2" flag to /etc/mysql/my.cnf. First tried<br>
=1 and got the same error as previously noted.<br>
<br>
With mysql up and running I checked all databases/tables with:<br>
mysqlcheck -c -u root -p --all-databases<br>
Output indicated all tables in both the mysql database and the<br>
mythconverg database were "OK." (again can attach output if useful).<br>
This may have been a bad idea, but with mysql running with the<br>
force recovery option, I was able to start the BE process<br>
successfully and begin watching a program on the FE. The DB check<br>
on mythweb also indicated all the mythconverg tables were ok.<br>
<br>
So based on what I have been able to find, the next step seems to<br>
be to dump all the tables and then restore a copy of them, however<br>
based on what I have so far, a corrupt table doesn't seem to be<br>
the problem(?), so I'm not sure dumping/restoring is the best way<br>
to go. Would this be the logical next step, or should I try<br>
something else?<br>
<br>
Thanks again for all your help.<br>
<br>
<br>
The reason myisamcheck didn't work is because it's for fixing ISAM tables, not InnoDB. It looks like you've got it working, I would make a backup, just so you have one, but it's probably not necessary. I'd also remote the force recovery flag, otherwise it's likely going to do it every time you start mysql.<br>
</blockquote>
Thanks, that is what I was wondering re: myisam check.<br>
<br>
Just to make sure I'm understanding - the only way the (mysql/mythtv portion of the) system works presently is with the "innodb_force_recovery = 2" flag in the my.cnf file. Is this ok to just leave it in there and tell mysql to basically ignore whatever the heck is bothering it? If I remove the flag, mysql will not start.<br>
It seems like running the system in what I assume mounts to "safe mode" may cause further problems at a future date. What's further confusing me is everything I've read tells me running mysql in force recovery mode prevents one from updating the tables, however I am able to delete recordings and/or watch live tv (i.e. create a recording) in this state.<br></blockquote><div><br></div><div>To be honest, I don't know. I've not had to deal with this specific situation before.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Tom</div></font></span></div></div></div></blockquote><div><br></div><div>Probably because mythtv uses myisam (with the exception of some mythweather tables) so it's not hitting the innodb engine which has the errors. You could probably leave the force_recovery in place but to me it signifies a serious problem with your install and should be corrected (somehow!).<br><br>Karl<br></div></div></div></div>