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

Jerome Yuzyk jerome at supernet.ab.ca
Tue Dec 29 02:03:34 UTC 2015


On Tuesday, December 29, 2015 02:09:51 PM Stephen Worthington wrote:
> On Mon, 28 Dec 2015 13:05:02 -0700, 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.
> 
> Too heavy activity on the system drive or in the database (I am not
> sure which) can cause bad recordings.  I currently have one DVB-T
> recording that happens regularly during my database optimise time, and
> it has recorded with gaps in it three times out of five in the last
> seven days.  This did not happen before I started using the updated
> optimise script that does defragmentation on the big tables.  I am
> saving up for an SSD drive.  However, my database is huge compared to
> most people - 14,340 recordings!  Today's compressed backup is
> 898,810,192 bytes.  The recordedseek .myd and .myi files are 2.9
> Gibytes each.  For most people with smaller databases, there is
> normally not a problem with the optimise or backup processes happening
> at the same time as a recording, especially if the recording is going
> to a different hard drive.
> 
> I also can not afford to turn off the defragmentation, as that causes
> some long delays to happen in mythfrontend.  However, I suspect that I
> could turn off defragmentation in the daily optimise cron job and only
> do it manually when needed, so I could choose a safe time to do it
> when there is an hour without recordings.  I have not experimented
> with that yet.

Handy to know from someone with a hardcore setup. (Geesh, I've only made 19k recordings over a decade with 175 currently). I am most concerned with effects on the database - recordings during my sleepytime IT maintenance window can usually be requeued and I just wrote a little tool that can tell me what those are - but a trashed database, even with a fresh backup, is a morning-spoiler.

Once I saw that optimize_mythdb.pl was enhanced in 0.27.5 I made a copy of the one in 0.27.4 and use that until I can make the enhancements seamless by either confirming that MySQL/MythTV can handle it or implementing a WillBeQuiet script I wrote. The original script has worked for me since 0.21 without database problems, but it may have caused recording problems that I never attributed to it.

My MySQL ignorance (but database savvy) keeps me from just dropping the new version in.

I would think that with 14K recordings you aren't deleting them often and so would suffer less from fragmentation issues and could do defrags on a longer cycle. 

-- 
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/7bb28519/attachment.html>


More information about the mythtv-users mailing list