<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 2, 2023 at 11:43 AM Mike Perkins <<a href="mailto:mikep@randomtraveller.org.uk">mikep@randomtraveller.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 02/06/2023 15:36, James Abernathy wrote:<br>
> <br>
(snip)<br>
> <br>
> My whole /var/lib/mysql directory is only 500MB with the only active<br>
> database (mythconverg) being less than 100MB. I think the database only<br>
> changes when data changes related to the metadata for TV recordings. So<br>
> very infrequent updating.<br>
> <br>
Heh. Did you forget the recordedseek table? That gets a lot of action every time you do a recording.<br>
<br>
-- <br>
<br>
Mike Perkins<br></blockquote><div><br></div><div>I'm  really not the judge of what is too much database writing.  I record no more than 3 hours a day some days.  I just know that I've not had a problem where the database didn't check out and  optimize successfully every day for 16 months.  It may help that my btrfs boot drive is 500GB where I only need < 50GB. The recordings and other mythtv directories are on a separate disk array so they don't get used except for writing recordings where COW would possibly be an issue.  They are NAS HDDs so not a problem. </div><div><br></div><div>The BTRFS snapshots saved my bacon a few weeks ago when I accidentally clicked on upgrade database schema on a frontend thinking it was talking about my test system when it was really for my production backend.  One cmd fixed that: sudo timeshift --restore, then select the hourly snapshot just before my screwup.</div><div><br></div><div>JimA</div><div><br></div></div></div>