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.

Community member Francesco Latini wrote a github gist for exactly this purpose:

The gist is here: https://gist.github.com/checco/c752b15671b9f846ce40bb0e5bf810b0

but here are the contents:

# pgloader help docker run --rm --name pgloader dimitri/pgloader:latest pgloader --help # run pgloader docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \ "mysql://odyssey-auth:${mysql_password}@${digitalocean_mysql_host}:25060/odyssey-auth" "postgresql://odyssey-staging-auth:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # first error, because of mysql_native_password on MySQL 8 ERROR mysql: Failed to connect to mysql at "odyssey-staging-do-user-4848868-0.b.db.ondigitalocean.com" (port 25060) as user "odyssey-auth": Condition QMYND:MYSQL-UNSUPPORTED-AUTHENTICATION was signalled. # create a dump from MySQL 8, because we have to do it on MySQL 5.7 # as we don't have any kind of control on the MySQL conf file on DigitalOcean mysqldump -u odyssey-auth -p${mysql_password} -h ${digitalocean_mysql_host} -P 25060 odyssey-auth > data/odyssey-staging-auth.sql # restore dump into a mysql 5.7 docker container docker run --name staging-mysql -p 3306:3306 -e MYSQL_ROOT_PASSWORD=password -d mysql:5.7 docker exec -i staging-mysql sh -c 'exec echo "CREATE DATABASE IF NOT EXISTS \`odyssey-staging-auth\`;" | mysql -uroot -p"password"' docker exec -i staging-mysql sh -c 'exec echo "SHOW DATABASES;" | mysql -uroot -p"password"' docker exec -i staging-mysql sh -c 'exec mysql -uroot -p"password" odyssey-staging-auth' < data/odyssey-staging-auth.sql docker exec -i staging-mysql sh -c 'exec echo "SHOW TABLES;" | mysql -uroot -p"password" odyssey-staging-auth' # run again pgloader from the local mysql to the DigitalOcean instance docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification --verbose --debug \ "mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \ "postgresql://doadmin:${postgresql_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # you'll have another error about the unkown collation ERROR 1273 (HY000) at line 77: Unknown collation: 'utf8mb4_0900_ai_ci' # Replace utf8mb4_0900_ai_ci collation with utf8mb4_bin # (an example with VIM) :%s/utf8mb4_0900_ai_ci/utf8mb4_bin/g # run again pgloader and this time it should work but when you try to startup FusionAuth, you'll have the error: # ERROR: operator does not exist: bytea = uuid # run pgloader again introducing the cast to change the type from binary to uuid # because, by default, pgloader casts all the records with binary type to bytea # here the docs: https://pgloader.readthedocs.io/en/latest/ref/mysql.html#default-mysql-casting-rules docker run --rm --name pgloader dimitri/pgloader:latest pgloader --no-ssl-cert-verification \ -L staging-migration.log --verbose --debug \ --cast "type binary to uuid drop typemod using sql-server-uniqueidentifier-to-uuid" \ "mysql://root:${mysql_password}@192.168.0.101:3306/odyssey-staging-auth" \ "postgresql://doadmin:${postgres_password}@${digitalocean_postgres_host}:25060/odyssey-staging-auth?sslmode=require" # check if the first command has been already executed by pgloader # it should be the last one before the summary and it's really important ALTER DATABASE "odyssey-staging-auth" SET search_path TO public, "odyssey-staging-auth"; # alter all the grants to the right user ALTER DATABASE "odyssey-staging-auth" OWNER TO "odyssey-staging-auth"; ALTER SCHEMA "odyssey-staging-auth" OWNER TO "odyssey-staging-auth"; REASSIGN OWNED BY doadmin TO "odyssey-staging-auth";

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.