MySQL Bugs: #96891: Validate clone_buffer_size vs max_allowed

Bug #96891	Validate clone_buffer_size vs max_allowed_packet
Submitted:	16 Sep 2019 23:34	Modified:	21 Nov 2019 17:54
Reporter:	Simon Mudd (OCA)	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Clone Plugin	Severity:	S3 (Non-critical)
Version:	8.0.17	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	cloning

Description:
As reported here, http://blog.wl0.org/2019/09/mysql-cloning-more-thoughts/, I see that setting clone_buffer_size > max_allowed_packet breaks cloning and generates the following error in response to running 

... <other presetup of plugins etc> ...
source: SET GLOBAL MAX_ALLOWED_PACKET = 1024 * 1024
target: SET GLOBAL MAX_ALLOWED_PACKET = 1024 * 1024
source: SET GLOBAL CLONE_BUFFER_SIZE = 64 * 1024 * 1024
target: CLONE INSTANCE FROM some_user@'some_host':<some_port> IDENTIFIED BY 'some_pass';

ERROR 1153 (08S01) at line 1: Got a packet bigger than 'max_allowed_packet' bytes

How to repeat:
I'll upload a sample script I have which uses dbdeployer to trigger the error.  I'm sure a smaller, simpler script could be used.

Suggested fix:
* Document current behaviour and the need for clone_buffer_size to be smaller then max_allowed_packet. (how much smaller?)

* Be as safe as you can be and avoid having to make the DBA change settings to make this work, and so automatically reducing clone_buffere_size to a value less than max_allowed_packet that should work
* generate a warning if this change is made as it may reduce expected performance

Validate (if necessary) that using different values for clone_buffer_size on source and target boxes will not cause issues with the cloning process such as buffer overruns etc.

Ad hoc script which can trigger the issue.

Attachment: clone_script2 (application/octet-stream, text), 3.94 KiB.

Hello Simon,

Thank you for the report and feedback.

regards,
Umesh

Test results - 8.0.17

Attachment: 96891_8.0.17.results (application/octet-stream, text), 6.58 KiB.

Umesh,

Unless I'm mistaken creating the clone user on the recipient is not needed. (referencing your results). Documentation here is confusing and not clear and probably needs updating to be more precise. If I'm correct it allows you to slightly simplify your test case.

Posted by developer:
 
Fixed as of the upcoming 8.0.19 release, and here's the changelog entry:

A clone_buffer_size value greater than the max_allowed_packet value
caused the following error: ERROR 1153 (08S01) at line 1: Got a packet
bigger than 'max_allowed_packet' bytes. The error message was revised to
indicate the minimum required clone_buffer_size value.

Posted by developer:
 
Revised entry as follows:

Fixed as of the upcoming 8.0.19 release, and here's the changelog entry:

A low max_allowed_packet value caused the following error: ERROR 1153
(08S01) at line 1: Got a packet bigger than 'max_allowed_packet' bytes.
The error message was revised to indicate the minimum required
max_allowed_packet value for cloning operations.

This does of course lead to the question why this can't be auto-configured so the user doesn't have to worry about it.  An extra couple of statements when initiating cloning would avoid the need for this to be ever touched and might remove the need for a special clone_buffer_size setting. Maybe.

Either way thanks for addressing the problem.