I've noticed a weird issue in our chained replication environment where when setting user-defined variables, the first time the variable is used in a session the value is NULL, but all uses thereafter work correctly.
The environment is such: we have a master (master1), which has a slave which is also a master (master3), which itself has slaves (master3-slave1), i.e.: master1 -> master3 -> master3-slave1 I can replicate my issue with a very simple setup. I simply create a test table with one TEXT column, and I set a user-defined variable: CREATE TABLE test_table (id INT(10) PRIMARY KEY AUTO_INCREMENT, result TEXT) ENGINE=InnoDB; SET @mynewvariable = "testvalue" And then insert the variable into the test table: INSERT INTO test_table VALUES (NULL, @mynewvariable); The first time I run this insert, the value is correctly inserted in to master1 and its slave, master3 (as you'd expect). However, a NULL value is inserted into master3-slave1. However, if I run the INSERT a second time (just the insert, no re-declaration of the user-defined variable), the value is correctly inserted in to all three servers, so that the contents of test_table on the three servers looks as follows: master1 master3 master3-slave1 --------- --------- -------------- testvalue testvalue NULL testvalue testvalue testvalue I don't believe this is related to replication delay, because even if I leave a while between setting the variable and running the first INSERT, the result is always the same. The problem is agnostic of table format or how complex the table is, we can reproduce it exactly like this all of the time. Is this a known issue in MySQL with chained replication like this, or have I discovered a bug? Server version information: master1: Percona Server 5.5.28-29.1 master3: Percona Server 5.5.28-29.3 master3-slave1: Percona Server 5.5.20-55 -- Global Personals is a limited company registered in England and Wales. Registered number: 04880697. Registered office: Minton Place, Victoria Street, Windsor, Berkshire, SL4 1EG, United Kingdom.
