Bug #82474 Cluster log truncates long messages
Submitted: 5 Aug 2016 13:04 Modified: 6 Aug 2018 8:52
Reporter: Hartmut Holzgraefe Email Updates:
Status: Verified Impact on me:
Category:MySQL Cluster: Cluster (NDB) storage engine Severity:S3 (Non-critical)
Version:mysql-cluster-7.2.14, probably all OS:Linux
Assigned to: CPU Architecture:Any

[5 Aug 2016 13:04] Hartmut Holzgraefe
There's a limit of 96 characters for messages sent to the management nodes for logging in the cluster log (100 byte signal payload limit minus 4 bytes used for storing the event type?)

There are log messages that exceed this limit though, e.g.

  2016-08-01 10:33:04 [MgmtSrvr] INFO     -- Node 14: Out of event buffer: nodefailure will cause event failures, consider increasing MaxBufferedEpoc

which should actually end in "... increasing MaxBufferedEpochBytes"

There are also long messages where more important information gets truncated though, e.g.:

  2016-08-01 10:33:00 [MgmtSrvr] INFO     -- Node 14: Pending nodes '0000000000000000000000000000000000000000000000000000000001800000', epoch 1892115

Here the epoch number, which is a 18 digit digital integer in other messages, gets truncated to its first 7 digits.

How to repeat:
See e.g. ndb_1_cluster.log in ndb_error_reporter bundle attached to bug #82394

Suggested fix:
Either make sure that format strings passed to SimulatedBlock::infoEvent() and friends can never exceed the 96 byte limit when expanded, or split up long messages into multiple signals instead of just silently truncating them at 96. Or maybe at least warn about the truncation in the generating nodes *_out.log and show the full untruncated message there ...
[5 Aug 2016 18:00] MySQL Verification Team
In my humble opinion , this is a feature request.

Fix would lead to one embarrassment less, but, still a feature request.
[5 Aug 2016 18:06] Hartmut Holzgraefe
Finally we disagree on something again ;)

IMHO truncating values like epoch numbers is a bug as it makes the log messages sort of useless ... I'm almost tempted to say that the log is actively lying, but I for sure think it is a bug if wrong information is logged
[8 Aug 2016 8:58] MySQL Verification Team
Hello Hartmut,

Thank you for the report and feedback!

[16 Aug 2016 10:25] Hartmut Holzgraefe
Forgot to mention this in the original description:

The main problem with the example message shown is that it's not clear whether it recommends to raise MaxBufferedEpochBytes or MaxBufferedEpochs. Raising the later might actually be counter-productive in this case, but it may easily be taken as what seems to be recommended as "Epoc" and "Epochs" are visually similar, and sound even more similar. So when reading the error message, opening the manual, then looking for the parameter you are more likely to end up looking at the wrong than the actual right one ...
[6 Aug 2018 8:52] Hartmut Holzgraefe
Any news on this?