[slurm-users] Extreme long db upgrade 16.05.6 -> 17.11.3
Ole Holm Nielsen
Ole.H.Nielsen at fysik.dtu.dk
Wed Apr 3 10:53:11 UTC 2019
Hi Lech,
Thanks for submitting the patch to SchedMD:
https://bugs.schedmd.com/show_bug.cgi?id=6796
SchedMD already decided that they won't fix the problem:
> Thank you for the submission, but I will not be merging this upstream at this time.
>
> Support for the 17.11 release is nearly ended, and we do not expect to make any further maintenance releases on that branch.
>
> For 18.08, we're rather late in to the lifecycle to make a change this significant to the MySQL conversion code, and I will not be passing this along in to our review process for further evaluation. Our recommendation to sites to run a modern MySQL/MariaDB version stands as our primary means of avoiding this class of issues.
Can you confirm that your patch is only relevant for an old MySQL 5.1?
On our CentOS 7 systems we run the OS's MariaDB server 5.5. Would
MySQL/MariaDB version 5.5 be affected by your patch or not?
Best regards,
Ole
On 4/3/19 12:30 PM, Lech Nieroda wrote:
> Hello Chris,
>
> I’ve submitted the bug report together with a patch.
> We don’t have a support contract but I suppose they’ll at least read it ;)
> The code is identical for 18.08.x and 19.05.x, it’s just a different offset.
>
> Kind regards,
> Lech
>
>> Am 02.04.2019 um 15:18 schrieb Ole Holm Nielsen <Ole.H.Nielsen at fysik.dtu.dk>:
>>
>> Hi Lech,
>>
>> IMHO, the Slurm user community would benefit the most from your interesting work on MySQL/MariaDB performance, if https://bugs.schedmd.com/show_bug.cgi?id=6796your patch could be made against the current 18.08 and the coming 19.05 releases. This would ensure that your work is carried forward.
>>
>> Would you be able to make patches against 18.08 and 19.05? If you submit the patches to SchedMD, my guess is that they'd be very interested. A site with a SchedMD support contract (such as our site) could also submit a bug report including your patch.
>>
>> /Ole
>>
>> On 4/2/19 2:56 PM, Lech Nieroda wrote:
>>> That’s probably it.
>>> Sub-queries are known for potential performance issues, so one wonders why the devs didn’t extract it accordingly and made the code more robust or at least compatible with RHEL/CentOS 6 rather than including that remark in the release notes.
>>>> Am 02.04.2019 um 07:20 schrieb Chris Samuel <chris at csamuel.org>:
>>>>
>>>> On Monday, 1 April 2019 7:55:09 AM PDT Lech Nieroda wrote:
>>>>
>>>>> Further analysis of the query has shown that the mysql optimizer has choosen
>>>>> the wrong execution plan. This may depend on the mysql version, ours was
>>>>> 5.1.69.
>>>>
>>>> I suspect this is the issue documented in the release notes for 17.11:
>>>>
>>>> https://github.com/SchedMD/slurm/blob/slurm-17.11/RELEASE_NOTES
>>>>
>>>> NOTE FOR THOSE UPGRADING SLURMDBD: The database conversion process from
>>>> SlurmDBD 16.05 or 17.02 may not work properly with MySQL 5.1 (as was the
>>>> default version for RHEL 6). Upgrading to a newer version of MariaDB or
>>>> MySQL is strongly encouraged to prevent this problem.
More information about the slurm-users
mailing list