Bug #25597 Extraneous error message displayed for slave SQL thread errors.
Submitted: 12 Jan 2007 21:55 Modified: 9 Feb 2007 9:15
Reporter: Chuck Bell Email Updates:
Status: In progress Impact on me:
None 
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.0, 5.1 OS:Any (All)
Assigned to: Assigned Account CPU Architecture:Any

[12 Jan 2007 21:55] Chuck Bell
Description:
Whenever a serious error occurs in the slave's SQL thread, replication stops with an appropriate message. However, there is an erroneous error message displayed that has no meaning. The code displays:

070112 16:39:17 [ERROR] Slave: Error 'FUNCTION test.myfunc_int does not exist' on query. Default database: 'test'. Query: 'insert into t11 values (myfunc_int(10))', Error_code: 1305
070112 16:39:17 [Warning] Slave: FUNCTION test.myfunc_int does not exist Error_code: 1305
070112 16:39:17 [Warning] Slave: Unknown error Error_code: 1105
070112 16:39:17 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'mysql-bin.000001' position 102

This error is produced from the code in slave.cc @line#575:

my_error(ER_UNKNOWN_ERROR, MYF(0), msg);

The code then proceeds to set the actual error, making the 1105 error extraneous.

How to repeat:
One of the ways to predictably crash the slave is to setup replication where the master has a compiled UDF library and the slave does not. Create a function on the master for one of the compiled UDFs and then insert data into a table calling the function. For example:

CREATE TABLE t1 (col_a INT);
CREATE FUNCTION myfunc_int RETURNS INTEGER SONAME 'udf_example';
INSERT INTO t1 VALUES (myfunc_int(10));

Under SBR, when the slave attempts to execute the function the slave's SQL thread will crash. Note: replication of compiled UDFS is being worked in WL#3629.

Suggested fix:
Supress printing of the error 1105 message when a known error is generated.
[18 Jan 2007 10:27] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/18322

ChangeSet@1.2372, 2007-01-18 11:26:27+01:00, rafal@quant.(none) +6 -0
  BUG#25597 (Extraneous error message displayed for slave SQL thread errors):
  This is incomplete patch for review purposes.
  
  The patch re-works error reporting in replication code. Some goals of the patch:
  
  - Move error reporting as close as possible to the place where error was 
    detected (to have more information about the error).
  
  - When errors happen during calls to handler methods, print handler and method
    name in error messages so that the error code can be correctly interpreted.
  
  - Write to the error log more information about exceptional situations such as
    skipping events, re-reading and re-executing event groups.
  
  - Add consistent message headers such as "Slave I/O thread ..." and "Slave SQL 
    thread ..." informing about the place where error was detected.
  
  - Suppress confusing message printouts in error log such as reporting the same
    error twice or printing non-informative "Unknown error" messages.
  
  - Some refactoring in event reading and execution code: analyzing errors from 
    Query event, master reconnection logic in I/O thread, remove base class 
    initialization order compiler warnings.
  
  TODO:
  
  - Review/update error messages generated by helper functions of the I/O thread.
  
  - After calling exec_relay_log_event() the SQL thread prints waring pushed 
    during event execution. Since exec_relay_log_event() can re-execute events it 
    sometimes create confusing output. Move warning printing code inside 
    exec_relay_log_event() so that they are printed just after an event was 
    executed.
  
  - Polish the patch.
[4 Dec 2007 19:56] Andrei Elkin
Error reporting is slightly changed by fixes of bug#31552. That fix revealed another issues reported in bug#32971 which might be a duplicate for the current.
[15 Jan 2008 11:00] Andrei Elkin
At least some parts, namely 1,2,5 of the issue list
http://lists.mysql.com/commits/18322
will be addressed with bug#32971 patch.
Other need verification as the code has been changed.