@vordan Sorry to hear this! We have other folks running with MySQL, so I'm not sure what your particular issue is.

Can you echo $CLASSPATH in start.sh to ensure the mysql library is being picked up?

Here's an excerpt of start.sh:

# Start it up echo "Starting fusionauth-app..." echo " --> Logging to ${LOG_DIR}/fusionauth-app.log" cd "${APP_DIR}" CLASSPATH="" for file in lib/*; do CLASSPATH=${CLASSPATH}:${file} done CLASSPATH=${CLASSPATH:1} if [[ ${1} == "--debug" ]]; then

Add echo $CLASSPATH on a new line after CLASSPATH=${CLASSPATH:1}. Do you see your mysql lib file?

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.