[mythtv-users] Problem with latest run of optimize_mythdb.pl

[Hika van den Hoven]

Hoi Mike,

Tuesday, December 29, 2015, 3:09:12 AM, you wrote:

> On 29 December 2015 at 11:45, Hika van den Hoven <hikavdh at gmail.com> wrote:

>> Hoi Mike,
>>
>> Tuesday, December 29, 2015, 1:21:33 AM, you wrote:
>>
>> > The moral of this story is to finish debugging the issue first, rather
>> than
>> > rush in and start deleting data.
>>
>> True, but it would not have made any real difference and there was no
>> data lost as it was all recreatable. The table needed to get cleared
>> as it had already crashed.
>> Checking earlier would only possibly have prevented the table crashing
>> again!
>>

> No issues this time ...

> That was more a pointer for someone in 6 months' time who has similar
> issues with a crashed table, and who finds this thread via Google, and
> who's first action is to truncate their "recorded" table, or their
> "channel" table by following this advice, and then finds that their backup
> isn't working properly, or is several weeks out of date, or any number of
> other scenarios where they wouldn't be able to easily get back to a working
> system.

Again True. In this kind of situations you always have conflicting
priorities. You want it up and running as fast as possible to not miss
future recordings and you don't want to loose any data needlessly.
As far as I know trying to repair a crashed table is not possible, but
my knowledge is limited. Also neither backup nor optimize will run
until the crashed table is out of the way. In the case of a not
recreatable table I would truncate, run a fresh backup, restore the
newest intact backup, run optimize and check further restored
functionality. And of course this always after checking the logs! I
might also make a raw file copy of the mysql directory to analyze
afterwards. And last when up and running again a fresh backup!

And then at leisure look at what can be salvaged out of the in between
time span. Probably only importing into the video table.

I think the only way to mostly prevent these kind of things is to
create a complex mirrored database as I have with ldap. Also, as I
have, set your system to mail on any volume going below a save
percentage of free space or on smart failure! Next to power outage I
think that's the most common cause of these kind of crashes.

Tot mails,
  Hika                            mailto:hikavdh at gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens