In this blog post, we’ll discuss how to set a replication from MySQL 8.0 to MySQL 5.7. There are some situations that having this configuration might help. For example, in the case of a MySQL upgrade, it can be useful to have a master that is using a newer version of MySQL to an older version slave as a rollback plan. Another example is in the case of upgrading a master x master replication topology.

Officially, replication is only supported between consecutive major MySQL versions, and only from a lower version master to a higher version slave. Here is an example of a supported scenario:

5.7 master –> 8.0 slave

while the opposite is not supported:

8.0 master –> 5.7 slave

In this blog post, I’ll walk through how to overcome the initial problems to set a replication working in this scenario. I’ll also show some errors that can halt the replication if a new feature from MySQL 8 is used.

Here is the initial set up that will be used to build the topology:

First, before executing the CHANGE MASTER command, you need to modify the collation on the master server. Otherwise the replication will run into this error:

This is because the default character_set and the collation has changed on MySQL 8. According to the documentation:

The default value of the character_set_server and character_set_database system variables has changed from latin1 to utf8mb4.

The default value of the collation_server and collation_database system variables has changed from latin1_swedish_ci to utf8mb4_0900_ai_ci.

Let’s change the collation and the character set to utf8 on MySQL 8 (it is possible to use any option that exists in both versions):

You need to restart MySQL 8 to apply the changes. Next, after the restart, you have to create a replication user using mysql_native_password.This is because MySQL 8 changed the default Authentication Plugin to caching_sha2_password which is not supported by MySQL 5.7. If you try to execute the CHANGE MASTER command with a user using caching_sha2_password plugin, you will receive the error message below:

To create a user using mysql_native_password :

Finally, we can proceed as usual to build the replication:

Checking the replication status:

Executing a quick test to check if the replication is working:

Caveats

Any tentative attempts to use a new feature from MySQL 8 like roles, invisible indexes or caching_sha2_password will make the replication stop with an error:

Summary

Replicating from MySQL 8 to MySQL 5.7 is possible. In some scenarios (especially upgrades), this might be helpful, but it is not advisable to have a heterogeneous topology because it will be prone to errors and incompatibilities under some cases.

You May Also Like

Read our solution brief to learn how to setup MySQL Amazon RDS instances. The ease of initial setup makes Amazon RDS capable of accommodating rapid deployment, as well as application development. Our brief also includes failover and basic business continuity components.

For a proven MySQL database architecture that is similarly easy to set up, check out our solution brief: Get Up and Running with Percona Server for MySQL. This solution is ideal for startup organizations and small businesses.

Links to more resources that might be of interest:

7 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Gauravkumar Mishra

Hi Vinicius,
I have been trying to do this for past few days. I then bumped into your post , but still seems to be an issue for me.
I am trying replication only for one particular database.
On slave which is 5.7 has replicate-do-db=”databasename” set in my.cnf
The replication works for almost a day and then we get this error as below:
Last_SQL_Error: Error ‘Character set ‘#255’ is not a compiled character set and is not specified in the ‘/usr/share/mysql/charsets/Index.xml’ file’ on query. Default database: ‘mysql’. Query: ‘BEGIN’

even though I am using the parameter replicate-do-db it is still throwing an error for query on database ‘mysql’.
I am wondering why? Let me know what do you think of this error.

I will try your solution and will update here.
Wish me good luck!!

Steve

I realize it has been awhile; but I am getting the same #255 error with replication from 8.0.13-4 to 5.7.

[ERROR] Slave SQL for channel ”: Error ‘Character set ‘#255’ is not a compiled character set and is not specified in the ‘/usr/share/percona-server/charsets/Index.xml’ file’ on query.

The character sets and collations are the same and using UTF8.

master 8.0> show global variables like ‘%character%’;
+————————–+————————————-+
| Variable_name | Value |
+————————–+————————————-+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/percona-server/charsets/ |

master 8.0> show global variables like ‘%collation%’;
+——————————-+——————–+
| Variable_name | Value |
+——————————-+——————–+
| collation_connection | utf8_unicode_ci |
| collation_database | utf8_unicode_ci |
| collation_server | utf8_unicode_ci |
| default_collation_for_utf8mb4 | utf8mb4_0900_ai_ci |
+——————————-+——————–+

slave 5.7> show global variables like ‘%character%’;
+————————–+————————————-+
| Variable_name | Value |
+————————–+————————————-+
| character_set_client | utf8 |
| character_set_connection | utf8 |
| character_set_database | utf8 |
| character_set_filesystem | binary |
| character_set_results | utf8 |
| character_set_server | utf8 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/percona-server/charsets/ |
+————————–+————————————-+

slave 5.7> show global variables like ‘%collation%’;
+———————-+—————–+
| Variable_name | Value |
+———————-+—————–+
| collation_connection | utf8_unicode_ci |
| collation_database | utf8_unicode_ci |
| collation_server | utf8_unicode_ci |
+———————-+—————–+

New database created on master 8.0:

master 8.0> select * from information_schema.schemata where schema_name = ‘steve_test’;
+————–+————-+—————————-+————————+———-+
| CATALOG_NAME | SCHEMA_NAME | DEFAULT_CHARACTER_SET_NAME | DEFAULT_COLLATION_NAME | SQL_PATH |
+————–+————-+—————————-+————————+———-+
| def | steve_test | utf8 | utf8_unicode_ci | NULL |
+————–+————-+—————————-+————————+———-+

This is an upgrade on a replicated server from 5.7.25-28 to 8.0.13-4 so all users were in place and using the correct plugin.

Any ideas why the replicated statement from 8.0 generates an error in replication to 5.7?

Steve

Update:
Using SET NAMES utf8;
Before running statements successfully replicates to 5,7 from 8.0.

Steve

The default-character-set=utf8 in [client] works but you have to make sure it is in all instances of my.cnf that client might look at. Adding it to local my.cnf file fixed the issue.

Steve

The init-connect option was plausible; but it does not work for users with the super privilege,