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

[Jerome Yuzyk]

On Monday, December 28, 2015 10:05:56 PM Hika van den Hoven wrote:
> Hoi Jerome,
> 
> Monday, December 28, 2015, 9:05:02 PM, you wrote:
> 
> > On Monday, December 28, 2015 01:51:19 PM Stephen Worthington wrote:
> >> 
> >> Check the free space on your drives.  One reason for
> >> optimize_mythdb.pl crashing like that with the *.tmm files open is if
> >> it runs out of space writing the *.tmm file, or another temporary file
> >> while the *.tmm file is big.  Since recordedseek is normally larger
> >> than the rest of the database put together, that is the table it will
> >> crash on if the space is too low.
> 
> > Just how robust is MySQL at handling a major table rewrite like
> > this on a live database? I see it's available in 0.27.5 and I wonder
> > if I have to alter the twice-weekly cron-and-forget way I use it now
> > (without the defraggng) or I can just drop it in and it will play
> > nice with an active backend that might be recording at any time of the day.
> 
> I don't have the answer to your question, but those scripts I run at
> night. 4:10 the backup 5:30 optimize and 5:50 my grabber starts, being
> ready around 7. Maybe once a year or less I'm recording at those
> times!
> Like on every IT system, the night is for maintenance!

Tell that to my backend! :) I regularly have overnight recordings, often things punted to the 2nd showing later that night/next morning, so the hopeful crossed-fingers approach won't work. Unless I can tell my backend in some global way to back off for a period I have to treat it as though it's going to be busy at any hour of any day.

Does anyone have a definitive answer or definitive experience with optimizing a running system?

-- 
A little of Jerome's MythTV World: http://mythtv.bss.ab.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20151228/8bca3330/attachment.html>