At this point I can’t figure out how to drop the table since I didn’t think you could drop a table using a prepared statement?

I’m glad my talks were helpful at the conference. Whether or not the temporary table should be replicated depends on whether any queries depend on the data in it. If you’re inserting into the temporary table then selecting back out of it to insert into another table, or updating from a join, or any other statement that changes data depending on the data in the temporary table, the temporary table needs to be replicated to the slave, or replication will break on the slave.

I’ve thought a lot about this over the years and had many interesting conversations with people who are doing different things with their data. I have yet to find a situation where temporary tables can be used safely in replication. Replication has many flaws, and it is not possible to make it reliable even in the best of circumstances, but I find the temporary tables are a pretty severe problem in many common scenarios. So in my mind, they are a top 10 problem and it’s well worth avoiding them entirely.

Regarding using slave-side ignores on SBR, wouldn’t it be desireable in the case of tmp data used to satisfy queries only (selects) to not have the tmp table data replicated at all (since it serves no purpose on the slave)? I’m interested to avoid the IO on the master and for the slave thread when the result will always be discarded. Particularly since I’m running in the cloud, every bit of IO saved seems to count.

Currently the only “safe” option I see for this is SET SESSION SQL_LOG_BIN=0/1 during the tmp table operations from the app, which has the unfortunate (but also reasonable) side effect of requiring giving your app user SUPER.

Any thoughts or master-side solution that you would endorse?

That said, your solution, variants of which I have also used in the past, seems to be more useful under row-based repl where it appears the master-side ignore* params seem to behave correctly.