Blog

A comment to a comment

Mark Callaghan blogged this: http://www.facebook.com/note.php?note_id=10150236650815933

He refers a bug report that has now  been marked as private for some reason. I have been subscribed to it from the beginning (and thus have all details in my inbox) and I think Mark misses the point raised by the bug reporter here.  Mark has another and equally important point.  What they have in common is that there are situations where a statement longer than max_allowed_packet is written to the binlog.  If the host where it happens is a replication master there are scenarios where this will break replication where it should not.

The ‘how to repeat’ section of the original report (that was verified by inspection of the binlog) reads:

1) Make sure the max_allowed_packet variable is set to 16777216 in MySQL.
2) Make sure binary logging is enabled
3) Send an UPDATE query that is slightly less than 16777216 bytes long. This update query has a large amount of text including many tab characters (\x0a).
4) MySQL writes a binlog event that is 16784830 bytes long.

(except for that I will respect Oracle’s decision and not reveal more details of the discussion – even though the ‘privatization’ here seems ‘overkill’ to me.  But maybe they know more than what I do)

I understand this case like the UPDATE actually succeeds (on the the machine where it executes that happens to be a master)  but next fail to replicate (due to the fact that the event binlogged is longer than the original statement and exceeds max_allowed_packet).  Here the client actually does respect the max_allowed_packet setting. Mark’s concern seems to be another (where the client does not respect the max_allowed_packet setting).  Correct me and enlighten me if I am wrong!

Actually I think it is not possible for a client to know whether a server is a replication master or not. It should be safe to execute statments up to max_allowed_packet setting. Or at least what ‘safe margin’ is required should be documented (but just documenting seems to be not satisfactory).

(and BTW: I am not replying raising this discussion in Mark’s post because it would require me to to have a Facebook account what I do not have and do not want to have)

One thought on “A comment to a comment

  1. I suspect that my clients still respect max_allowed_packet given the code that exists in the client. I don’t know why I get a 17MB or 19MB binlog event with max_allowed_packet=16MB. Maybe encoding the string for the binlog event is the problem but I don’t intend to explain how this happened. I expect to spend one day adding an option to let the slave use a larger value for max_allowed_packet.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>