@dan I know this is old thread and OP didn't reply. But I have same issue and I did see mysql Connector when I echo $CLASSPATH in script .. I am getting that It cannot access database. I am using Connector 8.0.33 but my mysql is 5.7 is that a problem? Because I check authentication setting to mysql and using PHP Script I can connect fine but not from fusionAuth 1.48

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.

@sander

Thanks for the update. We're bummed that we can't include the mysql connector as part of the docker image.

If FusionAuth is stuck in maintenance mode, this thread might prove useful: https://fusionauth.io/community/forum/topic/135/can-t-get-by-maintenance-mode

Can you give me any more details about the issue?

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.