MySQL Bugs: #82474: Cluster log truncates long messages

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:	None
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

Description:
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 ...

In my humble opinion , this is a feature request.

Fix would lead to one embarrassment less, but, still a feature request.

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

Hello Hartmut,

Thank you for the report and feedback!

Thanks,
Umesh

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 ...

Any news on this?