BUG#19402 SQL close to the size of the max_allowed_packet fails on the slave
A communication packet can also be a binlog event sent from the master to the slave.
To be sent by master dump and accepted by slave io thread both have to have
the value of max_allowed_packet bigger than one that client connection had.
In the patch there is the MAX possible replicatio header size estimation for events
in binlog that embedded user query. Only these events of query_log_event type, i.e
just plain queries, require attention.
sql/log_event.h:
MAX value of the header of the replication packet, i.e the value of exceeding
the query string part.
sql/slave.cc:
Private value of max allowed packet slave io, sql threads can accept from master.
The value is increased by the MAX possible size of replication event header.
Note, that my_net_init is redundant for slave io because the thread uses instance of
NET struct, embedded into MYSQL, as a client to server. We have left old code and even
increment, redundantly as well, thd->net.max_packet_size just for the sake of
consistency. TODO: eliminate my_net_init from execution path of slave io.
sql/sql_repl.cc:
Increasing the private max allowed packet that the dump thread reads from master
binlog and sends to net. Note, that happened prior this writting to binlog is
safe from the current artifact because it is done by steps that each chunk can not
exceed @@global.max_allowed_packet.
mysql-test/r/rpl_packet.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/r/rpl_packet.result
mysql-test/t/rpl_packet-master.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-master.opt
mysql-test/t/rpl_packet-slave.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-slave.opt
mysql-test/t/rpl_packet.test:
test examines repliation of a max-sized query when database name is set to have
NAME_LEN bytes. This makes replication header size the maximum.
2006-09-11 23:19:05 +02:00
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
2006-11-08 16:17:28 +01:00
drop database if exists DB_NAME_OF_MAX_LENGTH_AKA_NAME_LEN_64_BYTES_____________________;
create database DB_NAME_OF_MAX_LENGTH_AKA_NAME_LEN_64_BYTES_____________________;
BUG#19402 SQL close to the size of the max_allowed_packet fails on the slave
A communication packet can also be a binlog event sent from the master to the slave.
To be sent by master dump and accepted by slave io thread both have to have
the value of max_allowed_packet bigger than one that client connection had.
In the patch there is the MAX possible replicatio header size estimation for events
in binlog that embedded user query. Only these events of query_log_event type, i.e
just plain queries, require attention.
sql/log_event.h:
MAX value of the header of the replication packet, i.e the value of exceeding
the query string part.
sql/slave.cc:
Private value of max allowed packet slave io, sql threads can accept from master.
The value is increased by the MAX possible size of replication event header.
Note, that my_net_init is redundant for slave io because the thread uses instance of
NET struct, embedded into MYSQL, as a client to server. We have left old code and even
increment, redundantly as well, thd->net.max_packet_size just for the sake of
consistency. TODO: eliminate my_net_init from execution path of slave io.
sql/sql_repl.cc:
Increasing the private max allowed packet that the dump thread reads from master
binlog and sends to net. Note, that happened prior this writting to binlog is
safe from the current artifact because it is done by steps that each chunk can not
exceed @@global.max_allowed_packet.
mysql-test/r/rpl_packet.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/r/rpl_packet.result
mysql-test/t/rpl_packet-master.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-master.opt
mysql-test/t/rpl_packet-slave.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-slave.opt
mysql-test/t/rpl_packet.test:
test examines repliation of a max-sized query when database name is set to have
NAME_LEN bytes. This makes replication header size the maximum.
2006-09-11 23:19:05 +02:00
select @@net_buffer_length, @@max_allowed_packet;
@@net_buffer_length @@max_allowed_packet
1024 1024
create table `t1` (`f1` LONGTEXT) ENGINE=MyISAM;
INSERT INTO `t1`(`f1`) VALUES ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1023');
2006-11-08 16:17:28 +01:00
select count(*) from `DB_NAME_OF_MAX_LENGTH_AKA_NAME_LEN_64_BYTES_____________________`.`t1` /* must be 1 */;
BUG#19402 SQL close to the size of the max_allowed_packet fails on the slave
A communication packet can also be a binlog event sent from the master to the slave.
To be sent by master dump and accepted by slave io thread both have to have
the value of max_allowed_packet bigger than one that client connection had.
In the patch there is the MAX possible replicatio header size estimation for events
in binlog that embedded user query. Only these events of query_log_event type, i.e
just plain queries, require attention.
sql/log_event.h:
MAX value of the header of the replication packet, i.e the value of exceeding
the query string part.
sql/slave.cc:
Private value of max allowed packet slave io, sql threads can accept from master.
The value is increased by the MAX possible size of replication event header.
Note, that my_net_init is redundant for slave io because the thread uses instance of
NET struct, embedded into MYSQL, as a client to server. We have left old code and even
increment, redundantly as well, thd->net.max_packet_size just for the sake of
consistency. TODO: eliminate my_net_init from execution path of slave io.
sql/sql_repl.cc:
Increasing the private max allowed packet that the dump thread reads from master
binlog and sends to net. Note, that happened prior this writting to binlog is
safe from the current artifact because it is done by steps that each chunk can not
exceed @@global.max_allowed_packet.
mysql-test/r/rpl_packet.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/r/rpl_packet.result
mysql-test/t/rpl_packet-master.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-master.opt
mysql-test/t/rpl_packet-slave.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-slave.opt
mysql-test/t/rpl_packet.test:
test examines repliation of a max-sized query when database name is set to have
NAME_LEN bytes. This makes replication header size the maximum.
2006-09-11 23:19:05 +02:00
count(*)
1
2007-04-03 11:24:35 +02:00
SHOW STATUS LIKE 'Slave_running';
Variable_name Value
Slave_running ON
select * from information_schema.session_status where variable_name= 'SLAVE_RUNNING';
VARIABLE_NAME VARIABLE_VALUE
2007-05-15 09:45:50 +02:00
SLAVE_RUNNING ON
BUG#19402 SQL close to the size of the max_allowed_packet fails on the slave
A communication packet can also be a binlog event sent from the master to the slave.
To be sent by master dump and accepted by slave io thread both have to have
the value of max_allowed_packet bigger than one that client connection had.
In the patch there is the MAX possible replicatio header size estimation for events
in binlog that embedded user query. Only these events of query_log_event type, i.e
just plain queries, require attention.
sql/log_event.h:
MAX value of the header of the replication packet, i.e the value of exceeding
the query string part.
sql/slave.cc:
Private value of max allowed packet slave io, sql threads can accept from master.
The value is increased by the MAX possible size of replication event header.
Note, that my_net_init is redundant for slave io because the thread uses instance of
NET struct, embedded into MYSQL, as a client to server. We have left old code and even
increment, redundantly as well, thd->net.max_packet_size just for the sake of
consistency. TODO: eliminate my_net_init from execution path of slave io.
sql/sql_repl.cc:
Increasing the private max allowed packet that the dump thread reads from master
binlog and sends to net. Note, that happened prior this writting to binlog is
safe from the current artifact because it is done by steps that each chunk can not
exceed @@global.max_allowed_packet.
mysql-test/r/rpl_packet.result:
BitKeeper file /home/elkin/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/r/rpl_packet.result
mysql-test/t/rpl_packet-master.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-master.opt
mysql-test/t/rpl_packet-slave.opt:
BitKeeper file /net/koti/usr_rh9/home/elkin.rh9/MySQL/TEAM/FIXES/4.1/bug19402-max_allowed/mysql-test/t/rpl_packet-slave.opt
mysql-test/t/rpl_packet.test:
test examines repliation of a max-sized query when database name is set to have
NAME_LEN bytes. This makes replication header size the maximum.
2006-09-11 23:19:05 +02:00
drop database DB_NAME_OF_MAX_LENGTH_AKA_NAME_LEN_64_BYTES_____________________;
2007-03-16 15:25:20 +01:00
SET @@global.max_allowed_packet=4096;
SET @@global.net_buffer_length=4096;
STOP SLAVE;
START SLAVE;
CREATE TABLe `t1` (`f1` LONGTEXT) ENGINE=MyISAM;
INSERT INTO `t1`(`f1`) VALUES ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa2048');
2007-08-29 18:57:10 +02:00
show slave status;
Slave_IO_State #
Master_Host 127.0.0.1
Master_User root
Master_Port MASTER_MYPORT
Connect_Retry 1
Master_Log_File master-bin.000001
2007-09-16 12:07:00 +02:00
Read_Master_Log_Pos #
2007-08-29 18:57:10 +02:00
Relay_Log_File #
Relay_Log_Pos #
Relay_Master_Log_File master-bin.000001
Slave_IO_Running No
Slave_SQL_Running #
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
2007-09-16 12:07:00 +02:00
Exec_Master_Log_Pos #
2007-08-29 18:57:10 +02:00
Relay_Log_Space #
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 #
2007-09-16 12:07:00 +02:00
Master_SSL_Verify_Server_Cert No
Last_IO_Errno 0
Last_IO_Error
Last_SQL_Errno 0
Last_SQL_Error
