MySQL Bugs: #43797: "Flush logs " bring the error "1594" ,slave will not be sync!

Bug #43797	"Flush logs " bring the error "1594" ,slave will not be sync!
Submitted:	23 Mar 2009 8:13	Modified:	11 Sep 2009 6:24
Reporter:	Yao roman	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S1 (Critical)
Version:	5.1.30	OS:	Linux (2.6.18-92.el5)
Assigned to:		CPU Architecture:	Any
Tags:	Error_code: 1594

Description:
My Servers are in master-slave mode,i've a timing work to "flush logs",sometimes slave may have a error below ,therefore the slave will not sync:
(I just ouput the key works)
----------------------------------------------------------------------------
rootnone)> show slave status \G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Log_File: 2100.001355
Read_Master_Log_Pos: 65311388
Relay_Log_File: 379-relay-bin.000064
Relay_Log_Pos: 18446697150789051856   
Relay_Master_Log_File: 2100.001355           
Slave_IO_Running: Yes
Slave_SQL_Running: No
Last_Errno: 1594
Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave'sMySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
Last_SQL_Errno: 1594
----------------------------------------------------------------------------
In the error logs ,There are some statements about this error!
----------------------------------------------------------------------------
090314 20:00:05 [ERROR] Error reading relay log event: slave SQL thread aborted because of I/O error
090314 20:00:05 [ERROR] Slave SQL: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave. Error_code: 1594
090314 20:00:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVESTART". We stopped at log '2100.001355' position 4 
090314 20:05:05 [Note] Slave I/O thread killed while reading event
090314 20:05:05 [Note] Slave I/O thread exiting, read up to log '2100.001355', position 86001983
090314 20:06:32 [Note] Slave SQL thread initialized, starting replication in log '2100.001355' at position 4, relay log './379-relay-bin.000001' position: 4 
090314 20:06:32 [Note] Slave I/O thread: connected to master 'repl@10.10.2.100:3306',replication started in log '2100.001355' at position 4
----------------------------------------------------------------------------

You can see "Relay_Log_Pos: 18446697150789051856 "，this is extremely too large ,and when i use mysqlbinlog to parse the binlog contents ,just :
----------------------------------------------------------------------------
mysqlbinlog 379-relay-bin.000064 :
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#090313 13:08:23 server id 379 end_log_pos 106 Start: binlog v 4, server v 5.1.30-log created 090313 13:08:23
BINLOG '
R+q5SQ97AQAAZgAAAGoAAAAAAAQANS4xLjMwLWxvZwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAEzgNAAgAEgAEBAQEEgAAUwAEGggAAAAICAgC
'/*!*/;
# at 106
#090314 20:00:01 server id 2100 end_log_pos 995694021 Rotate to 2100.001355 pos: 4  995694021
# at 144
#090313 13:08:23 server id 379 end_log_pos 191 Rotate to 379-relay-bin.000065 pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET [email=COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/]COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/[/email];
----------------------------------------------------------------------------
When i use "change master to master_log='2100.00135' ,master_log_pos=4;slave start;". the slave will sync.

How to repeat:
when you use "flush logs" may this error occur ,but not every time.

Suggested fix:
I think this may a bug ,so can you explain it ,thank you!

Looks related to bug #37768. Do you have a repeatable test case for this?

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I got the same error on the slave, when master executed "flush logs".
But not every time.

-----------------------------------------------------------

root:(none)> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.10.2.152
                  Master_User: repl
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: 2152.006639
          Read_Master_Log_Pos: 41547969
               Relay_Log_File: 365-relay-bin.000361
                Relay_Log_Pos: 18446697160050056448
        Relay_Master_Log_File: 2152.006639
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: 
          Replicate_Ignore_DB: mysql
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: mysql.%
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the m
aster's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is cor
rupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's
 MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issui
ng 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 4
              Relay_Log_Space: 774921237
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the m
aster's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is cor
rupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's
 MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issui
ng 'SHOW SLAVE STATUS' on this slave.
1 row in set (0.00 sec)

root:(none)> select version();
+------------+
| version()  |
+------------+
| 5.1.30-log | 
+------------+
1 row in set (0.01 sec)

-------------------------------------------------------

Ivan,

thank you for the feedback. Please try with current version 5.1.37 and inform us if problem still exists: at least 2 similar bugs were fixed after 5.1.30.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".