Why does this CASE based update cause replication skew? - mysql

Question

Using MySQL 5.6 with statement based replication between a single master and slave, the following scenario creates replication skew:
Create this table:
CREATE TABLE `ReplicationTest` (
`TestId` int(11) NOT NULL,
`Tokens` int(11) NOT NULL,
PRIMARY KEY (`TestId`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1$$
Insert this data:
Insert into ReplicationTest (TestId, Tokens) VALUES
(1, 0),
(2, 0),
(3, 0),
(4, 0);
Create this proc:
CREATE PROCEDURE `MyDatabase`.`ReplicationTestProc` (vTestId int, pSuccessful BIT, pAmount DECIMAL(19, 4))
BEGIN
START TRANSACTION;
Update MyDatabase.ReplicationTest Set Tokens = CASE WHEN pSuccessful THEN Tokens - (pAmount * 100) ELSE Tokens END
where TestId = vTestId;
COMMIT;
END
Run these 4 statements in a single execution
call `MyDatabase`.`ReplicationTestProc`(1, 1, 1);
call `MyDatabase`.`ReplicationTestProc`(2, 1, 1);
call `MyDatabase`.`ReplicationTestProc`(3, 1, 1);
call `MyDatabase`.`ReplicationTestProc`(4, 0, 1);
You will now have different values in the ReplicationTest table between master and replication. It looks like the pSuccessful variable is being treated as a global, with the last value set the one that is being used on the replication server.

Answer 1

You can get a clue what's happening by observing what statements actually get logged in the binary log. View the binlog with:
$ mysqlbinlog <datadir>/mysql-bin.000001
(Of course the filename containing these statements is probably different on your system.)
The statements inside the called procedure are logged to the binary log, but constant values that are based one procedure variables are slightly modified. This is explained in http://dev.mysql.com/doc/refman/5.6/en/stored-programs-logging.html:
A statement to be logged might contain references to local procedure variables. These variables do not exist outside of stored procedure context, so a statement that refers to such a variable cannot be logged literally. Instead, each reference to a local variable is replaced by this construct for logging purposes.
Here's what we see in the binlog for your test. The references to local variables have been replaced with a string representation of the BIT values:
. . .
Update test.ReplicationTest Set Tokens = CASE
WHEN NAME_CONST('pSuccessful',_binary'' COLLATE 'binary')
THEN Tokens - ( NAME_CONST('pAmount',1.0000) * 100) ELSE Tokens END
where TestId = NAME_CONST('vTestId',1)
. . .
Update test.ReplicationTest Set Tokens = CASE
WHEN NAME_CONST('pSuccessful',_binary'' COLLATE 'binary')
THEN Tokens - ( NAME_CONST('pAmount',1.0000) * 100) ELSE Tokens END
where TestId = NAME_CONST('vTestId',2)
. . .
Update test.ReplicationTest Set Tokens = CASE
WHEN NAME_CONST('pSuccessful',_binary'' COLLATE 'binary')
THEN Tokens - ( NAME_CONST('pAmount',1.0000) * 100) ELSE Tokens END
where TestId = NAME_CONST('vTestId',3)
. . .
Update test.ReplicationTest Set Tokens = CASE
WHEN NAME_CONST('pSuccessful',_binary'\0' COLLATE 'binary')
THEN Tokens - ( NAME_CONST('pAmount',1.0000) * 100) ELSE Tokens END
where TestId = NAME_CONST('vTestId',4)
. . .
Notice how the BIT values 1 is replaced with the string literal _binary''.
When your expression evaluates that for true/false, the empty string is equivalent to false, which is why the statement doesn't update your column on the slave:
mysql> select false = _binary'';
+-------------------+
| false = _binary'' |
+-------------------+
| 1 |
+-------------------+
Why is a BIT value of 1 replaced with an empty string? BIT values are sort of strings by nature, as if using the BINARY data type. Here's an example of a BIT value corresponding to the ASCII code for 'Z' coming out as a 'Z':
mysql> select b'01011010';
+-------------+
| b'01011010' |
+-------------+
| Z |
+-------------+
How does BIT treat the value of b'1'? It's just like an ASCII value 0000001, which prints as an unprintable, zero-length string:
mysql> select b'1';
+------+
| b'1' |
+------+
| |
+------+
You can force this value to be converted to an integer by referencing it in an integer context:
mysql> select b'1'+0;
+--------+
| b'1'+0 |
+--------+
| 1 |
+--------+
But even if we were to change your stored procedure to use this trick, it's too late. The value has been converted in the binary log to an empty string _binary'' and that string can't be converted to anything but 0 in an integer context.
mysql> select _binary''+0;
+-------------+
| _binary''+0 |
+-------------+
| 0 |
+-------------+
Why isn't the BIT value converted to b'1' in the binary log like a real BIT literal? This appears to be deliberate. There's even a comment in the binary logging code for stored procedures (file sql/sp.c, function sp_get_item_value()).
/* Bit type is handled as binary string */
What I would recommend to you is to forget about using BIT for booleans in MySQL. There are too many cases of unexpected behavior of the MySQL BIT data type. For more on this, see Why you should not use BIT columns in MySQL.
Instead, use BOOLEAN or TINYINT (BOOLEAN or BOOL are really just aliases for TINYINT(1) in MySQL). I tested your procedure with the parameter changed to TINYINT, and it works as expected:
slave1 [localhost] {msandbox} (test) > select * from ReplicationTest;
+--------+--------+
| TestId | Tokens |
+--------+--------+
| 1 | -100 |
| 2 | -100 |
| 3 | -100 |
| 4 | 0 |
+--------+--------+