Database Failure Issues

If your build fails while importing its database - or the build completes but the site cannot connect to its data - the most common cause is a collation mismatch between the database that produced your dump and the database running in your Probo build.

Recognizing the Problem

Look at the log output for the database import step on your build page. A collation problem shows up as an error like:

ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_0900_ai_ci'

or

ERROR 1273 (HY000) at line 25: Unknown collation: 'utf8mb4_uca1400_ai_ci'

The import stops at the first table using the unknown collation, leaving your build with a partial database or none at all.

Why It Happens

MySQL and MariaDB have diverged in their default collations. MySQL 8 defaults to utf8mb4_0900_ai_ci, which MariaDB does not support. Newer versions of MariaDB introduced the utf8mb4_uca1400_* collations, which MySQL and older versions of MariaDB do not support. A dump taken from one server will fail to import on the other, even though both are “MySQL compatible.”

The first thing to check is the database tag in your .probo.yaml file. If your production environment runs MariaDB 11.4, matching that in your build configuration avoids the problem entirely:

database: mariadb:11.4

Fixing the Dump

When you cannot match the database versions - or you are moving between MySQL and MariaDB - rewrite the incompatible collations in your dump file before uploading it as a build asset. The sed command below replaces the problem collations with utf8mb4_unicode_ci equivalents that both databases support, and also rewrites ROW_FORMAT=COMPRESSED (which can fail on servers where compressed tables are unavailable) to ROW_FORMAT=DYNAMIC:

sed -i \
  -e 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_ai_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_ai_cs/utf8mb4_unicode_cs/g' \
  -e 's/utf8mb4_uca1400_as_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_as_cs/utf8mb4_unicode_cs/g' \
  -e 's/utf8mb4_uca1400_bin/utf8mb4_bin/g' \
  -e 's/ROW_FORMAT=COMPRESSED/ROW_FORMAT=DYNAMIC/g' \
  dump.sql

The full workflow for an existing gzipped dump:

gunzip dump.sql.gz
sed -i \
  -e 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_ai_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_ai_cs/utf8mb4_unicode_cs/g' \
  -e 's/utf8mb4_uca1400_as_ci/utf8mb4_unicode_ci/g' \
  -e 's/utf8mb4_uca1400_as_cs/utf8mb4_unicode_cs/g' \
  -e 's/utf8mb4_uca1400_bin/utf8mb4_bin/g' \
  -e 's/ROW_FORMAT=COMPRESSED/ROW_FORMAT=DYNAMIC/g' \
  dump.sql
gzip dump.sql

Then upload the corrected dump.sql.gz as your build asset and rebuild.

You can check whether a dump contains incompatible collations before uploading it:

grep -o 'utf8mb4_0900[a-z_]*\|utf8mb4_uca1400[a-z_]*' dump.sql | sort -u

If this prints nothing, the dump is free of the problem collations.

Still Failing?

If the import still fails, open the SSH Terminal from the Advanced Functions on your build page and try importing the database manually to see the full error output:

mysql -uroot -pstrongpassword mydatabase < $ASSET_DIR/dump.sql

Large databases can also hit build timeouts rather than collation errors - see SQL Timeouts if your import runs for a long time before failing.

Related Articles & Information

---

General SQL Error Importing Databases Database Configuration