170
|
|
|
Oleg Tsarev |
12 years ago
|
|
|
169
|
|
|
Oleg Tsarev |
12 years ago
|
|
|
168
|
|
|
Alexey Kopytov |
12 years ago
|
|
|
167
|
|
|
Oleg Tsarev |
12 years ago
|
|
|
166
|
|
|
Alexey Kopytov |
12 years ago
|
|
|
165
|
|
|
Alexey Kopytov |
12 years ago
|
|
|
164
|
|
|
Oleg Tsarev |
12 years ago
|
|
|
163
|
|
|
Alexey Kopytov |
12 years ago
|
|
|
162
|
|
Initial implementation of max_binlog_packet.patch
The problem solved by the patch is that the limit set by max_allowed_packet does not work well with row-based replication. Even if it is not possible to INSERT/UPDATE values larger than the limit set by max_allowed_packet, the limit may still be exceeded when shipping the binary log due to the fact that for each modified row there may be one or two full row images in the binary log. So, for example, for a table with a BLOB column, even if only an INT column is changed, there will be one or two BLOB images stored into the corresponding RBR event, so it may break replication by exceeding the max_allowed_packet limit on either master or slave.
A similar problem exists when replaying the binary log with mysqlbinlog, but in this case the base64 overhead is added on top of it.
max_binlog_packet.patch addresses both problems by introducing the max_binlog_packet system variable. The variable's semantics is quite different depending whether it is used in the global or a session scope:
- The global max_binlog_packet value, when it is not 0, represents an effective packet size limit for binary log operations on both the master and slaves. i.e. reading a binlog event from the binary log on the master, sending it to a slave, reading it by a slave, and reading it from the relay log by the slave are all performed with the effective max_allowed_packet value equal to "max_binlog_packet + RBR event header length" regardless of the actual value of max_allowed_packet.
The default value for max_binlog_packet is zero (i.e. the real value of max_allowed_packet will be used in all contexts).
Unlike most other variables, the client's session max_binlog_packet value is NOT initialized from the global max_binlog_packet value. When a new client connects, its max_binlog_packet session variable is set to 0 regardless of the global variable value.
- The session max_binlog_packet variable can only be set by users with the SUPER privilege. Once it is set to a non-zero value, it changes the effective value of max_allowed_packet for the current session so that the BINLOG event corresponding to an event at most max_binlog_packet bytes long could be read by the server, that is:
the effective max_allowed_packet = (session's max_binlog_event + event header length) * 4 / 3
where the 4/3 multiplier is the base64 overhead.
The session max_binlog_packet variable is used by mysqlbinlog which now has a new command line option with the same name. When passed on the command line, --max-binlog-packet makes mysqlbinlog to prepend it's output with "SET LOCAL max_binlog_packet=<option value>;".
In other words, max_binlog_packet allows to define a limit on the maximum possible RBR event for both replication and binlog rollforwarding independently from max_allowed_packet.
|
Alexey Kopytov |
12 years ago
|
|
|
161
|
|
|
Alexey Kopytov |
12 years ago
|
|
|
160
|
|
|
Alexey Kopytov |
13 years ago
|
|
|
159
|
|
|
kinoyasu |
13 years ago
|
|
|
158
|
|
|
kinoyasu |
13 years ago
|
|
|
157
|
|
|
Yasufumi Kinoshita |
13 years ago
|
|
|
156
|
|
|
Alexey Kopytov |
13 years ago
|
|
|
155
|
|
|
Oleg Tsarev |
13 years ago
|
|
|
154
|
|
|
Oleg Tsarev |
13 years ago
|
|
|
153
|
|
|
Oleg Tsarev |
13 years ago
|
|
|
152
|
|
|
Oleg Tsarev |
13 years ago
|
|
|
151
|
|
|
Oleg Tsarev |
13 years ago
|
|
|