Heyo good sirs.
I have a master to slave replication using Row-based replication. The master gets a few simple and fast reads but the majority of read load is directed at the slave. They sometimes have queries running for a minute or two.
Lately we needed to have a trigger to copy some new data from one table into a new one. Simple enough, we created the trigger and everything went OK. The slave did not get the trigger but the data was replicated over anyways as is the way with row-based replication.
Then things took a turn for the worse. We did yet another trigger on another table. While we did this I'm guessing a big read query was being run on the slave. Suddenly our monitoring scripts started yelling at us that the amount of queries on the slave was too high so I started checking out the process list on the slave. There was one query running, the huge read. Every other query was "Waiting for table metadata lock" and the only other query which was not a SELECT was the system user replication "connection"/"thread". That query was showing the statement as our CREATE TRIGGER... which we ran on our master. In a panic I killed the long running SELECT query and all the congestion we had just disappeared quickly.
I then checked SHOW TRIGGERS and the information_schema.TRIGGERS for any trigger, there were none. That was as it should, considering the row based replication I guess. However why was the CREATE TRIGGER query even running on the slave, and why was it blocking all our other queries?
We then tried the same when there was no long query running and everything went fine. We even duplicated this behavior on a test setup by manually starting a long query and creating a trigger on the master.
Is this behavior intended and could we do something to make sure creating triggers won't make the slave drop and/or queue our SELECT queries?
I'm sorry for the wall of text.
With best wishes, alu