I know you’re not supposed to do this, but I have a MySQL 5.5 master and a MySQL 5.1 replication slave. That’s supposed to be okay, unless I do something stupid like use utf8mb4 that isn’t supported by 5.1. Well, everything has been going well for a while and today I got a replication slave failure because character_set_client #45 isn’t supported by MySQL 5.1.

I spent a lot of time trying to find out what #45 was… you see, it doesn’t appear in any of MySQL’s configuration files — even on 5.5. I finally determined it was utf8mb4 (which I had suspected) but I’m not sure why it’s being used. I performed a static query on the master … something simple like UPDATE table SET field='value' and it replicated to the slave by setting the character set to utf8mb4. I executed hundreds of similar UPDATE statements at the same time, but some of them triggered the use of utf8mb4.

So… I’m going to be upgrading my slave to 5.5, but in the mean time is there a way to tell MySQL to never use utf8mb4?

POLITICALLY CORRECT ANSWER

You cannot do MySQL Replication from a New Master to an Old Slave

I have written many posts about this:

• Nov 26, 2012 : Replicate MySQL 5.0 Master to 5.5 Slave?
• Feb 08, 2012 : will replication from 5.5.20 to 5.0.XX server work?
• Dec 22, 2011 : What does the base64 BINLOG statements in mysqlbinlog output mean?
• Feb 04, 2011 : MySQL master binlog corruption

In addition, there is the likelihood of dealing with the internal BINLOG magic number being in the wrong place and replication going senile. Here are my posts on the BINLOG magic number:

• Oct 28, 2012 : Binlog has bad magic number
• Dec 26, 2011 : mysql emits BINLOG rows even though binlog_­format=­STATEMENT

Since there is nothing in the meantime you can do, please upgrade your Slave to MySQL 5.5

ALTERNATE PERSPECTIVE

In all fairness, @ChristopherSchultz is correct in that you can implement it. I just yell and scream “RISK !!!” to be more cautious because of the BINLOG magic number’s place in the MySQL Replication Universe.