Binary log events larger than max_allowed_packet can lead to slave failure even after fix of MySQL bug #60926

Bug #1477734 reported by Sveta Smirnova
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
MySQL Server
Unknown
Unknown
Percona Server moved to https://jira.percona.com/projects/PS
Status tracked in 5.7
5.6
Triaged
High
Unassigned
5.7
Triaged
High
Unassigned

Bug Description

To fix bug #60926 new variable, --slave-max-allowed-packet, were introduced, but its size is limited to 1G. In this way if master created row event, larger than 1G, slave will fail.

How to repeat:
Start master and slave with max-allowed-packet=1G and slave-max-allowed-packet=1G (maximum)

On master:

set binlog_format='row';
create table t1(f1 longtext);
insert into t1 values(repeat('a', 1073741824/4));
create table t2 like t1;
flush logs;
insert into t2 select concat(f1,f1,f1,f1) from t1;

Ensure data inserted properly into t2:

mysql> select count(*) from t2;
+----------+
| count(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)

On slave:

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State:
                  Master_Host: 127.0.0.1
                  Master_User: root
                  Master_Port: 13000
                Connect_Retry: 1
              Master_Log_File: master-bin.000002
          Read_Master_Log_Pos: 337
               Relay_Log_File: slave-relay-bin.000004
                Relay_Log_Pos: 369
        Relay_Master_Log_File: master-bin.000002
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB:
           Replicate_Do_Table:
       Replicate_Ignore_Table:
      Replicate_Wild_Do_Table:
  Replicate_Wild_Ignore_Table:
                   Last_Errno: 0
                   Last_Error:
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 154
              Relay_Log_Space: 807
              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: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event '' at 4, the last event read from './master-bin.000002' at 337, the last byte read from './master-bin.000002' at 356.'
               Last_SQL_Errno: 0
               Last_SQL_Error:
  Replicate_Ignore_Server_Ids:
             Master_Server_Id: 1
                  Master_UUID: 4e4741d5-316d-11e5-9104-1caff70598d3
             Master_Info_File: /home/sveta/build/mysql-5.7/mysql-test/var/mysqld.2/data/master.info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 10
                  Master_Bind:
      Last_IO_Error_Timestamp: 150723 22:11:35
     Last_SQL_Error_Timestamp:
               Master_SSL_Crl:
           Master_SSL_Crlpath:
           Retrieved_Gtid_Set:
            Executed_Gtid_Set:
                Auto_Position: 0
         Replicate_Rewrite_DB:
                 Channel_Name:
1 row in set (0.01 sec)

mysql> select count(*) from t2;
+----------+
| count(*) |
+----------+
| 0 |
+----------+
1 row in set (0.00 sec)

Events less than 1G replicated successfully:

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
| 1 |
+----------+
1 row in set (0.00 sec)

Suggested fix:
Make slave ignore max-allowed-packet value completely, because with ROW format is easy to create such big events

Changed in percona-server:
milestone: none → 5.6.25-73.2
milestone: 5.6.25-73.2 → none
no longer affects: percona-server/5.7
tags: added: upstream
Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-915

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.