[mythtv-users] mysqlcheck buffers output?

[John Pilkington]

On 22/10/15 10:34, Mike Perkins wrote:
> On 22/10/15 01:39, Hika van den Hoven wrote:
>> Hoi Tom,
>>
>> Thursday, October 22, 2015, 2:16:39 AM, you wrote:
>>
>>> I apologize because this a bit off topic...more related to mysql
>>> itself as apposed to my MythTV system, but I figured there might be
>>> someone here that's run into this or knows something about it:
>>
>>> I've noticed for years now that the mysqlcheck program inexplicably
>>> buffers it's output in a way where you can *never* truly know what
>>> table it's on without going into mysql separately and doing a show
>>> processlist.
>>
>>> For example, I've seen cases were one of the first tables in alpha
>>> order was a massive table that takes a long time to check, where it
>>> will output *nothing* at all, until it's several tables past that
>>> table.  It appears to be buffering the output, possibly in 1K blocks
>>> or the like.  If you were sending the output to a file for example,
>>> and the server happened to go down, you might not even have *any* way
>>> to know how far it got.
>>
>>> This is an *insane* manner for something that important to behave, and
>>> searching the web I see no mention of this.  I can't possibly be the
>>> only one whose ever noticed this.
>>
>>> Does anyone know if there's any way to prevent that buffering?  I sure
>>> can't find one.
>>
>>> Thanks in advance!
>>> Tom
>>> _______________________________________________
>>
>> This is standard Linux behavior. In order to save on writes the
>> diskdriver by default only actually writes to disk if the file is
>> closed or if the size of a disk unit is reached. If you do not like
>> this behavior in this program you have to go upstream and ask the
>> developer(s) to incorporate more regular disk commits.
>>
> Individual table-by-table checks, perhaps, with a disk flush in between.
> Something that could be knocked up in a script to iterate over a database.
>
I tweaked my copy of optimize_mythdb.pl to show timing info earlier this 
year, after the addition of table defragging. Maybe it's immediately 
obvious, but it could be a model:

https://code.mythtv.org/trac/attachment/ticket/12451/optimizedb.diff