It's OK to max out the max_allowed_packet
to 1G. Whenever a MySQL Packet is constructed, it will not jump to 1G from the start. Why?
First you need to know what a MySQL Packet. Page 99 of the Book
explains it in paragraphs 1-3 as follows:
MySQL network communication code was
written under the assumption that
queries are always reasonably short,
and therefore can be sent to and
processed by the server in one chunk,
which is called a packet in MySQL
terminology. The server allocates the
memory for a temporary buffer to store
the packet, and it requests enough to
fit it entirely. This architecture
requires a precaution to avoid having
the server run out of memory---a cap
on the size of the packet, which this
option accomplishes.
The code of interest in relation to
this option is found in
sql/net_serv.cc. Take a look at my_net_read(), then follow the call to my_real_read() and pay
particular attention to
net_realloc().
This variable also limits the length
of a result of many string functons.
See sql/field.cc and
sql/intem_strfunc.cc for details.
Compare that with the MySQL Documentation on max_allowed_packet
:
The maximum size of one packet or any generated/intermediate string,
or any parameter sent by the mysql_stmt_send_long_data() C API
function. The default is 4MB as of MySQL 5.6.6, 1MB before that.
The packet message buffer is initialized to net_buffer_length bytes,
but can grow up to max_allowed_packet bytes when needed. This value by
default is small, to catch large (possibly incorrect) packets.
You must increase this value if you are using large BLOB columns or
long strings. It should be as big as the largest BLOB you want to use.
The protocol limit for max_allowed_packet is 1GB. The value should be
a multiple of 1024; nonmultiples are rounded down to the nearest
multiple.
When you change the message buffer size by changing the value of the
max_allowed_packet variable, you should also change the buffer size on
the client side if your client program permits it. On the client side,
max_allowed_packet has a default of 1GB. Some programs such as mysql
and mysqldump enable you to change the client-side value by setting
max_allowed_packet on the command line or in an option file.
Given this information, you should be glad MySQL will expand and contract the MySQL Packet as needed. Therefore, go ahead and
Master and Slave should match in terms of who they transmit data, especially BLOB data.
UPDATE 2013-07-04 07:03 EDT
From your messages concerning the relay log, it looks like you have the following
- a corrupt relay log
- a good master log
SUGGESTION
SHOW SLAVE STATUS\G
STOP SLAVE;
CHANGE MASTER TO
MASTER_LOG_FILE='(Relay_Master_Log_File from SHOW SLAVE STATUS\G)',
MASTER_LOG_POS=(Exec_Master_Log_Pos from SHOW SLAVE STATUS\G);
START SLAVE;
Running CHANGE MASTER TO
clears all relay logs and starts with a new one. You will be replicating from the Last Master BinLog Event (BinLog,Position) that executed on the Slave.
Give it a Try !!!
Replication status and lag are vital monitors you should take care of. Before start a backup you must know if your slave goes well.
A simple show slave status
will show you all needed infos:
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 172.30.40.61
Master_User: replica
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.021934
Read_Master_Log_Pos: 205924047
Relay_Log_File: relay-bin.004199
Relay_Log_Pos: 205924192
Relay_Master_Log_File: mysql-bin.021934
Slave_IO_Running: Yes
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: 205924047
Relay_Log_Space: 205924384
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: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)
The mains "counters" are Slave_IO_Running
and Slave_SQL_Running
for replication status and Seconds_Behind_Master
for lag (ideally at 0 second).
If you have a slave dedicated to backups (that is a good practice), I recommend you to make a binary copy of your datadir instead (or in addition) of your mysqldump. The restore will be much more easier and quick. However mysqldump is good if you want to restore a partial backup (especially InnoDB tables) or restore a clean shrinked dataset.
If your are afraid by corrumption or delta between Master and Slaves you can use the Percona tool pt-table-checksum (available in the Percona Toolkit) that "Verify MySQL replication integrity" easily.
Max.
Best Answer
It's pretty easy to create a slave either from the running master or slave. Here Percona explains how to do it with XtraBackup http://www.percona.com/doc/percona-xtrabackup/2.1/howtos/setting_up_replication.html#adding-more-slaves-to-the-master
You can use this procedure with slight variation to add new slaves to a master. We will use Percona XtraBackup to clone an already configured slave. We will continue using the previous scenario for convenience but we will add TheNewSlave to the plot.
At TheSlave, do a full backup:
By using the --slave-info Percona XtraBackup creates additional file called xtrabackup_slave_info.
Apply the logs:
Copy the directory from the TheSlave to TheNewSlave (NOTE: Make sure mysqld is shut down on TheNewSlave before you copy the contents the snapshot into its datadir.):
rsync -avprP -e ssh /path/to/backupdir/$TIMESTAMP TheNewSlave:/path/to/mysql/datadir Add additional grant on the master:
Copy the configuration file from TheSlave:
Make sure you change the server-id variable in /etc/mysql/my.cnf to 3 and disable the replication on start:
After setting server_id, start mysqld.
Fetch the master_log_file and master_log_pos from the file xtrabackup_slave_info, execute the statement for setting up the master and the log file for The NEW Slave:
and start the slave:
If both IO and SQL threads are running when you check the TheNewSlave, server is replicating TheMaster.