WL#11150: Add <component> to error log messages by default
Affects: Server-8.0 — Status: Complete — Priority: Medium
to error log messages by default. must have one of three values: [Server], [InnoDB], [Repl] will be placed between [ ] and Example: 2017-09-07T08:15:04.448690Z 0 [Warning]  [Repl] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=vide27-bin' to avoid this problem.
1 Func-Req 1.1 Traditional log The traditional log shall feature another new field. This field will appear between '['
']' and '[' ']'. The value of this field should be "InnoDB" (for errors thrown in the InnoDB storage engine proper), "Repl" (for those thrown by the replication subsystem), or "Server" (otherwise). As with the new error-number field (WL#11009), this should result in legacy tools that are not aware of this new field interpreting it as part of the human- readable error-text. Those tools will therefore hopefully "fail" gracefully, that is, being unaware of the new format should not prevent "legacy" fields from being read correctly. This is however not something we can test and verify as those tools are not under our control; therefore, there will not be a non-functional for this.
I-1 Semantics NO CHANGE I-2 Instrumentation NO CHANGE I-3 Error and Warnings NO CHANGE I-4 Install/Upgrade NO CHANGE I-5 Commercial plugins Minimal code/behaviour change: logged errors now include the new field, and one of the three specified values. I-6 Replication Minimal code/behaviour change: logged errors now include the new field, and one of the three specified values. I-7 XProtocols NO CHANGE I-8 Protocols NO CHANGE I-9 Security NO CHANGE I-10 Log Files YES: The traditional error log file will have a new field; this field is non- empty and has one of the following 3 values; "Repl", "InnoDB", or "Server". It is inserted between the error-number field, and final field containing the human-readable error message. I-11 MySQL clients NO CHANGE I-12 Auth plugins Minimal code/behaviour change: logged errors now include the new field, and one of the three specified values. I-13 Globalization NO CHANGE I-14 Configuration NO CHANGE I-15 File formats NO CHANGE (see log files for that) I-16 Plugins/APIs Using the APIs will remain unchanged; some of the wrappers have however been updated to automatically set labels compliant with this spec. I-17 Other programs NO CHANGE I-18 Storage engines InnoDB: Minimal code/behaviour change: logged errors now include the new field with a value of "InnoDB" when reported in InnoDB proper. I-19 Data types NO CHANGE
I - New code a) Which label is used for a given call can be controlled by a dedicated particle in the error logging code, subsys(). (This nomenclature is chosen to avoid confusion with the component framework.) b) This particle will automatically be added by the new standard call, LogErr(), and its plug-in related variants. c) Its value is controlled by a #define, LOG_SUBSYSTEM_TAG. This is distinct from LOG_COMPONENT_TAG which is primarily intended for components as defined in WL#4102, "Service registry and component infrastructure", and uses its nomenclature. Plug-ins that use the component API for error-logging (as opposed to the legacy plug-in API) must also set LOG_COMPONENT_TAG to their own name if they wish to utilize that LogPluginErr*() family of macros. If LOG_COMPONENT_TAG is undefined, only LogEvent() and LogErr() will be available. See also WL#9651 and WL#9342 (filtering error-log events) for working with these key/value pairs and WL#9323 (structured error logging). d) This #define will be set up automatically for the cases laid out in the WL: da) "InnoDB" will be set up for the InnoDB storage engine as a -D define in the SE's CMakeList. db) "Repl" will be set up if the common include, log_shared.h, identifies the current source file to be starting with the prefix "rpl_". dc) A source file can set this value individually where needed. dd) Where none of the above applies, the logging core is reached with no value set; it will then use "Server" as the default value. e) For rare corner-cases where LogErr() and friends are not suitable or sufficient, engineers may use the LogEvent() call that is wrapped by the aforementioned calls. In these cases, they may need to manually include the subsys(LOG_SUBSYSTEM_TAG) particle where not the default, "Server". These cases are expected to be rare. II - Clean-up Some of the code base currently sets up these tags with a higher granularity than requested; these cases need to be aligned with the new requirements. Specifically, calls from plug-ins or components should be tagged with one of the three values specified above ("Server", "Repl", "InnoDB"); usually "Server" (which is applied if the component does not specify another value). Specific plug-in/component names where given must not appear in the context of these labels, but may as before appear in structured writers as information in addition that specified in this WL, or may appear in the actual error-message field itself in the traditional format, either as part of the message string itself (as registered in errmsg-utf8.txt), or as part of a template added by a a wrapper (e.g. LogPluginErr() / LogPluginErrMsg(), which use a prefix of "Plugin xy reported" to keep previous semantics -- see WL#9344 and friends, 4eac7bc40882320e3d4d961c49f665021573b6b1). The following would therefore be considered compliant: [MY-012356] [Server] My message here [MY-123457] [Repl] Team rpl's message here [MY-013458] [InnoDB] Team Inno's message here [MY-654321] [Server] Plugin myPlugin reported: 'Some plugin's message here'
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.