Bug #69249 master_delay does not perform proper type checking
Submitted: 16 May 2013 4:14 Modified: 19 Sep 2013 13:33
Reporter: Justin Swanhart Email Updates:
Status: Closed Impact on me:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:5.6.11 OS:Any
Assigned to: CPU Architecture:Any
Tags: Delay, delay_master, DELAYED, replication, SECONDS

[16 May 2013 4:14] Justin Swanhart
slave2 [localhost] {msandbox} ((none)) > change master to master_delay=18446744073709552001;
Query OK, 0 rows affected (0.14 sec)

slave2 [localhost] {msandbox} ((none)) > show slave status\G
                    SQL_Delay: 385
          SQL_Remaining_Delay: NULL
1 row in set (0.00 sec)

slave2 [localhost] {msandbox} ((none)) > change master to master_delay=340282366920938500000000000000000000000;
ERROR 1729 (HY000): The requested value 4294967295 for the master delay exceeds the maximum 2147483647

How to repeat:
change master to master_delay=18446744073709552001;

Suggested fix:
Don't allow sizes larger than signed int
[16 May 2013 4:15] Justin Swanhart
fix synopsis
[16 May 2013 13:09] MySQL Verification Team
Hello Justin,

Thank you for the report.
Verified as described.

[19 Sep 2013 13:33] Jon Stephens
Fixed in 5.6+. This also fixes BUG#69469. 

Documented as follows in the MySQL 5.6.14 and 5.7.2 changelogs:

        It was possible in CHANGE MASTER TO statements to set MASTER_DELAY
        greater than the supported maximum value (2^31 - 1). In addition, 
        the error resulting from setting MASTER_DELAY to a value greater 
        than 2^32 was not handled correctly.