Bug #38129 | agent floods its log with "executing regex for innodb ... failed" | ||
---|---|---|---|
Submitted: | 15 Jul 2008 10:13 | Modified: | 25 Jun 2009 13:19 |
Reporter: | Axel Schwenke | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Enterprise Monitor: Agent | Severity: | S2 (Serious) |
Version: | 1.3.x | OS: | Any (Vista 32) |
Assigned to: | Jan Kneschke | CPU Architecture: | Any |
Tags: | innodb, regex |
[15 Jul 2008 10:13]
Axel Schwenke
[16 Jul 2008 20:36]
Jan Kneschke
fixed in 9174 reduced the log-level to g_warning() and added a comment
[15 Sep 2008 19:59]
Moshe Hyzon
It is interesting to note for bug #19825, "A workaround is to use innodb_monitor" (i.e. read directly from .err log). Which is exactly what mysql_agent does not do. Of course the proper solution (in my mind) is to fix 19825.
[15 Sep 2008 20:08]
Mark Leith
Hi Moshe, I think that the correct workaround for it would be to require enabling innodb_status_file: http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#option_mysqld_innodb_status_... Then reading that file directly via the agent (though this requires the agent to be within the mysql group on unix like systems then as well, though that should not be a problem). This stops the error log from getting flooded as well then.. I agree the right fix would be to lift the limit on the output (people have raised it to 1024Kb without issues as far as I know, however.
[18 Sep 2008 14:26]
Axel Schwenke
Moshe, Mark, both your "solutions" would spoil an important feature of the agent - it does not have to run on the same machine as the monitored MySQL server. But I think using the InnoDB status file and SELECT READ_FILE(...) should do the trick.
[18 Sep 2008 14:27]
Axel Schwenke
Oops. SELECT LOAD_FILE(...) of course
[28 Jan 2009 11:55]
Carsten Segieth
- checked that the log level for the 'regex' messages changed to 'warning' after upgrading the agent to 1.3.3.9247 - I did not check exact the described dead lock situation, but in my test env. I had an agent writing also tons of similar 'regex' messages that after the upgrade only appeared in the log when using log-level=warning'.
[28 Jan 2009 15:24]
Tony Bedford
Is this actually fixed and if so which version did the fix go into? Thanks.
[21 May 2009 16:33]
Mark Matthews
We should consider supporting the I_S tables that the innodb plugin uses as well: http://www.innodb.com/doc/innodb_plugin-1.0/innodb-information-schema.html#innodb-informat...
[21 May 2009 16:36]
Mark Matthews
We also want to support the google patches for innodb status that went into 5.4 - http://code.google.com/p/google-mysql-tools/wiki/NewShowInnodbStatus
[15 Jun 2009 20:29]
Mark Leith
This was fixed in 1.3.3 as noted by Carsten. I have added Bug #45509 which is a feature request to work on some better INNODB STATUS parsing as well. However, the verbosity is now dialed down, and this bug is resolved until the better approach is taken in Bug #45509.
[25 Jun 2009 13:19]
Tony Bedford
An entry was added to the 1.3.3 changelog: The Agent flooded its log file with messages such as: (critical) agent/src/agent_result_cache.c.390: executing the regex for innodb pattern "Total memory allocated \d+; in additional pool allocated (\d+)" (62) failed: -1 This made the Agent log file rapidly increase in size, as approximately 20 messages per minute were generated. This led to the log file's size increasing to an unacceptable level.
[25 Jun 2009 13:22]
Tony Bedford
An entry was added to the 1.3.3 changelog: The Agent flooded its log file with messages such as: (critical) agent/src/agent_result_cache.c.390: executing the regex for innodb pattern "Total memory allocated \d+; in additional pool allocated (\d+)" (62) failed: -1 This made the Agent log file rapidly increase in size, as approximately 20 messages per minute were generated. This led to the log file's size increasing to an unacceptable level.