[mythtv-users] Is locking tables important when backing up mythconverg?

Brad DerManouelian myth at dermanouelian.com
Sat Apr 7 03:39:15 UTC 2007


On Apr 6, 2007, at 7:33 PM, Yeechang Lee wrote:

> So I have this script
> (<URL:http://www.gossamer-threads.com/lists/mythtv/users/ 
> 247868#247868>)
> that I run every two hours to back up mythconverg. As the earlier
> message notes, during the 100 seconds or so the script runs my
> frontend won't respond to commands. If I'm watching a recording at the
> time the playback normally but I can't pause, stop, or do other
> things. If I am not playing back a recording and try to start watching
> one, the frontend hangs at the black screen (that normally appears for
> a after a second or two before the video appears). In both cases, once
> the script completes running, things resume as normal.
>
> The mysqldump man page tells me that it by default runs with --opt,
> which is the equivalent of
>
>     --add-drop-table
>     --add-locks
>     --create-options
>     --disable-keys
>     --extended-insert
>     --lock-tables
>     --quick
>     --set-charset
>
> --lock-tables is what causes the fleeting frontend freezeup. Some
> quick experimenting with running my script with the addition of
> --skip-lock-tables verifies this.
>
> So, what am I risking here, if anything, by backing up the system with
> --skip-lock-tables? Even as a database dunce I know enough about the
> concept of table locking to ensure data integrity, but does it really
> matter for what is fundamentally a single-user (mythbackend) database?

My question is do you really need to back up your database every 2  
hours? Maybe you should schedule your job to run while you're not  
using the system to avoid the issue.


More information about the mythtv-users mailing list