[mythtv-users] mythtv dropping mysql???

Gary Buhrmaster gary.buhrmaster at gmail.com
Wed Oct 22 16:15:51 UTC 2014


On Wed, Oct 22, 2014 at 2:46 PM, Karl Newman <newmank1 at asme.org> wrote:
.....
> Wait, are you saying that the database backup and optimize_mythdb.pl that I
> run via cron every night could corrupt my database or result in a corrupt
> backup file?

Anything is possible, if things happen at just the
wrong moment.  To demonstrate, randomly and
repeatedly the plug on your system while it is
performing updates, backups, and optimization
and eventually you will be unhappy (and your
backup may be partial, or itself corrupt, and then
if you try to restore it, you end up with more
issues).

Consumers tend to ignore those random unlikely
events.  And then, when things go sideways,
complain to the supplier that their software is
crap, and question their lineage and morals,
and wish the developers and their family to die
painfully in a terrible fiery accident.

But when there are enough people using the
solution, *someone*, *somewhere* will
encounter the randomness (probability sucks
if you are the one hit by lightening).

Competent enterprise admins, on the other hand,
actually know that "stuff happens".  They plan
accordingly.  Many spend as much, or more, on
maintaining operations (and having a DRP for
when the stuff really hits the fan) than on the
base functionality.  And they test, test, and
test.  Because an untested backup is not a
backup, it is (no more than) a promise, and who
has not been lied to (hint: there is no Santa Claus).

Now, MythTV is "just TV".  So if worse comes
to worst, you just start over.  But if you want
to play that it is "critical to your life", you need
to step up your game, and learn about all the
things that *can* go wrong (and, therefore,
*will* eventually go wrong), and either choose
to knowingly accept the risks, or implement
mitigations to reduce them (you cannot eliminate
all risks; the gamma ray burst from WR 104
could cause mass extinctions).  Better yet,
submit patches to mitigate some of the risks.
Or you can just step back, and let the devs do
what they do well, and try to make MythTV the
best DVR on the planet.

And there are some contributory factors.

MythTV uses the MyISAM engine.  It also does not
use transactional updates internally.  There are a
number of limitations in that environment.  And is also
why tables that are crashed tend to remain crashed
(automated recovery is limited with MyISAM).

Now, it would be absolutely goodness if someone
wanted to go through the entire code base and
fix the MyISAM requirements to be *able* to use
a transactional engine with better recovery
capability (it has been some time, but as I recall,
while *much* of the code is engine agnostic,
there are a couple of cases where there are
implicit MyISAM dependencies; I think it is
documented somewhere, and if not, it should
be).

And once a transactional database engine can
be fully used, and can be supported, then one
can start adding in the appropriate transactional
support to the code (update all the tables, or
none at all, for example).

And then, a mysqldump --single-transaction will
make it far more likely that a backup has
the needed (referential) integrity (and even then,
"stuff can happen"), and that no locking of the
database has to occur at all during the backup.
Absolute goodness.


More information about the mythtv-users mailing list