[mythtv-users] Must mythbackend be running when executing optimize_mythdb.pl and/or mythlink.pl?
Michael T. Dean
mtdean at thirdcontact.com
Fri Apr 6 15:05:16 UTC 2012
On 04/06/2012 07:44 AM, Craig Huff wrote:
> I currently run these scripts as part of my shutdown process on the
> backend, along with other things. It seems I'm taking too long
> shutting down and sometimes mythbackend gets impatient and tries to
> restart things, occasionally ending up in a deadlock instead of
> actually shutting down. In an attempt to fix this, I'm wondering if I
> can move execution of either (or both) of these scripts to run after
> mythbackend is killed in the shutdown process sequence. Can anyone
> advise me on this?
mythlink.pl can definitely be run when mythbackend is running without
having any effect on the backend or recordings or frontend or playback
or ... (assuming your backend host/MySQL server is not severely
underpowered). (Before the support for use in MythTV System Events/user
jobs,) I used to run it at 2 and 32 minutes after the hour, every hour,
every day (but I almost never use the renamed links, now, so I only run
it once per day), and never had any problems.
optimize_mythdb.pl can be run while mythbackend is running, but--as
you've noticed--may take a while to complete. While it's running, it
locks tables, preventing other processes (such as mythbackend) from
reading or writing those tables. Therefore, running it when MythTV
needs access to the data in the database may cause issues (including
loss of some data for the new recording(s)). So, we highly recommend
that you run the script at some time when it's extremely unlikely that
you'll be doing a recording. I run it in a daily cron job that occurs
at 4:38am.
Also, the only reason we don't automatically run optimize_mythdb.pl type
functionality (repair/analyze/optimize)--we already have code in MythTV
to do it all--is because if it were being run and the MySQL server
crashes (mysqld crash/power outage/full file system/...) during a table
repair, it's critical that a repair is run, again, after restarting the
server and before any client attempts to read any data from the table
that was being repaired--otherwise, you could lose all of the data in
the table. Therefore, since we can't guarantee that we'll be able to
run the repair before anyone else reads from the table before, and
because even doing a quick check to see if tables are good before
starting the master backend slowed startup sufficiently, on some
systems, that we had to remove the check. That means
repair/analyze/optimize are left to the user/"db admin" for the system.
And, if there's a database crash, you should probably shut down all
MythTV applications, then do an optimize_mythdb.pl or mysqlcheck -r
before restarting MythTV (really, that's a good idea any time there's a
MySQL crash, even if you weren't running a repair at the time).
(Unfortunately, currently optmize_mythdb.pl requires a working settings
table, so if your settings table is crashed, you'll need to run
mysqlcheck -r directly--and figure out all the right command-line
arguments. I'm hoping to fix that, sometime.)
Mike
More information about the mythtv-users
mailing list