Bug #89630 Invalid ThreadConfig error

• Submitted: 12 Feb 2018 15:45
• Modified: 21 Jul 2020 1:37
• Reporter: Daniël van Eeden (OCA)
• Status: Closed
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S4 (Feature request)
• Version: 7.6.4
• OS: Any
• CPU Architecture: Any

[12 Feb 2018 15:45] Daniël van Eeden

Description:
When starting ndbmtd:

Time: Monday 12 February 2018 - 16:39:21
Status: Permanent error, external action needed
Message: Invalid configuration received from Management Server (Configuration error)
Error: 2350
Error data: Invalid configuration fetched, invalid ThreadConfig
Error object: Cannot set realtime on idxbld threads
Program: ndbmtd
Pid: 3593
Version: mysql-5.7.20 ndb-7.6.4
Trace file name: ndb_2_trace.log.18
Trace file path: /var/lib/mysql-cluster/ndb_2_trace.log.18 [t1..t0]
***EOM***

However in my ini file there is no ThreadConfig set. 
Removing 'RealTimeScheduler=1' allows ndbmtd to start.

How to repeat:
See description

Suggested fix:
Change the error to make it more obvious that this is related to RealTimeScheduler. Maybe print the Thread Config which was 'generated' from RealTimeScheduler, MaxNoOfExecutionThreads, etc.

Maybe also give more details about why realtime couldn't be set on idxbld threads.

[12 Feb 2018 17:27] MySQL Verification Team

Thanks for the report, 

all best
Bogdan

[27 Nov 2019 19:28] MySQL Verification Team

Hi Daniël,

Having your full (failing) config.ini would be good to have to roundup the bug report. Thanks

[28 Nov 2019 2:34] hiroshi yamakawa

hello

[28 Nov 2019 5:44] Daniël van Eeden

I don't have the failing config.ini anymore

[2 Jan 2020 21:11] Kenneth Culbert

Can I get an explanation of why this problem didn't occur in previous versions?  Was the setting ignored, or was it actully applied?  If the latter, what effect did it have?

[21 Jul 2020 1:37] Jon Stephens

Documented fix as follows in the NDB 7.6.16 and 8.0.22 changelogs:

    Data nodes did not start when the RealtimeScheduler
    configuration parameter was set to 1. This was due to the fact
    that index builds during startup are performed by temporarily
    diverting some I/O threads for use as index building threads,
    and these threads inherited the realtime properties of the I/O
    threads. This caused a conflict (treated as a fatal error) when
    index build thread specifications were checked to ensure that
    they were not realtime threads. This is fixed by making sure
    that index build threads are not realtime threads regardless of
    any settings applying to their host IO threads, which is as
    actually intended.

Closed.