And now it works fine with 152 threads connected, so unable to reproduce this.

I'll keep an eye out for this behavior and file an issue if it pops up again.

For the record:

FusionAuth 1.27
installed via zip file
Mysql 8.0.23 installed/managed via homebrew on the mac.

Just for clarity, this code was provided by a community member and has not been tested nor will it be supported by the FusionAuth team. It is occasionally shared by the FusionAuth team as a service to folks running MySQL, but the expectation is you'll review, test and support this code yourself should you find a need for it.

There is no easy way to do this. You'd have to migrate your configuration, your users and your DNS (if you are standing up a separate system).

If you have all your configuration as scripts, that should be easy to migrate, otherwise you need to move things over manually.

You could probably script a retrieve and then add of all the configuration, but there is no 'export all configuration' option.

For your users, you could do a database dump to get the hashes and do a bulk import. Or if you have developer edition you could set up a slow migration using connectors. The user migration process is broadly documented here: https://fusionauth.io/docs/v1/tech/guides/migration/

DNS migration is like any other DNS migration.

Doing so will allow FusionAuth to run even when utf8mb4 is not configured properly. We added that enforcement to ensure the limitation is understood before you turn off the enforcement.

The implication is that if you attempt to store a 4 byte unicode character the INSERT or UPDATE request will fail. The initial MySQL UTF-8 support only allowed for 3 byte characters, they then came out with utf8mb4 to support 4 byte characters.

For example, many emoji are 4 byte characters, so if you tried to store a piece of text with a smiley such as 😁 it will fail. The 😁 is a four byte character, U+1F601 or \xF0\x9F\x98\x81.

Unless you configure MySQL to use utf8mb4 any character points between U+10000 and U+10FFFF will fail to be stored.

Extracted from https://github.com/FusionAuth/fusionauth-issues/issues/234#issuecomment-632757441

Making this change will allow FusionAuth to run even when utf8mb4 is not configured properly. We added that configuration option to ensure the limitation is understood before you turn off the enforcement.

The implication is that if you attempt to store a 4 byte unicode character the INSERT or UPDATE request will fail. The initial MySQL UTF-8 support only allowed for 3 byte characters, they then came out with utf8mb4 to support 4 byte characters. More here: https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8.html

For example, many emoji are 4 byte characters, so if you tried to store a piece of text with a smiley such as 😁 it will fail. The 😁 is a four byte character, U+1F601 or \xF0\x9F\x98\x81.

Unless you configure MySQL to use utf8mb4, any character points between U+10000 and U+10FFFF will fail to be stored.

As long as your meet our minimum database requirements in theory it should work. I do know that MySQL Group Replication is not supported.