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
#
# Check replication protocol packet size handling
# Bug#19402 SQL close to the size of the max_allowed_packet fails on slave
#
# max-out size db name
source include/master-slave.inc;
let $db= DB_NAME_OF_MAX_LENGTH_AKA_NAME_LEN_64_BYTES_____________________;
2006-11-08 16:17:28 +01:00
disable_warnings;
eval drop database if exists $db;
enable_warnings;
eval create database $db;
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
connection master;
2008-03-31 16:32:45 +02:00
SET @@global.max_allowed_packet=1024;
SET @@global.net_buffer_length=1024;
# Restart slave for setting to take effect
connection slave;
STOP SLAVE;
source include/wait_for_slave_to_stop.inc;
START SLAVE;
source include/wait_for_slave_to_start.inc;
# Reconnect to master for new setting to take effect
2006-11-08 16:17:28 +01:00
disconnect master;
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
2006-11-08 16:17:28 +01:00
# alas, can't use eval here; if db name changed apply the change here
connect (master,localhost,root,,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
2006-11-08 16:17:28 +01:00
connection master;
2008-03-31 16:32:45 +02:00
select @@net_buffer_length, @@max_allowed_packet;
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
create table `t1` (`f1` LONGTEXT) ENGINE=MyISAM;
INSERT INTO `t1`(`f1`) VALUES ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa1023');
save_master_pos;
connection slave;
sync_with_master;
2006-11-08 16:17:28 +01:00
eval select count(*) from `$db`.`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
2006-11-08 16:17:28 +01:00
connection master;
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
eval drop database $db;
save_master_pos;
connection slave;
sync_with_master;
2007-03-16 15:25:20 +01:00
#
# Bug #23755: Replicated event larger that max_allowed_packet infinitely re-transmits
#
# Check that a situation when the size of event on the master is greater than
# max_allowed_packet on the slave does not lead to infinite re-transmits.
connection master;
# Change the max packet size on master
SET @@global.max_allowed_packet=4096;
SET @@global.net_buffer_length=4096;
# Restart slave for new setting to take effect
connection slave;
STOP SLAVE;
2008-03-31 16:32:45 +02:00
source include/wait_for_slave_to_stop.inc;
2007-03-16 15:25:20 +01:00
START SLAVE;
2008-03-31 16:32:45 +02:00
source include/wait_for_slave_to_start.inc;
2007-03-16 15:25:20 +01:00
# Reconnect to master for new setting to take effect
disconnect master;
2007-06-01 13:39:54 +02:00
connect (master, localhost, root);
2007-03-16 15:25:20 +01:00
connection master;
CREATE TABLe `t1` (`f1` LONGTEXT) ENGINE=MyISAM;
INSERT INTO `t1`(`f1`) VALUES ('aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa2048');
# The slave I/O thread must stop after trying to read the above event
2007-08-29 18:57:10 +02:00
connection slave;
--source include/wait_for_slave_io_to_stop.inc
--replace_result $MASTER_MYPORT MASTER_MYPORT
# import is only the 11th column Slave_IO_Running
--replace_column 1 # 8 # 9 # 12 # 23 # 33 #
query_vertical show slave status;
2007-03-16 15:25:20 +01:00
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
# End of tests
