Skip to content

Migrate into MariaDB

Tested with: MariaDB 11.8 on Databasezy · zb CLI 0.1

Sources: Self-hosted MariaDB or MySQL, Amazon RDS for MariaDB, Docker containers, .sql / .sql.gz dumps, another Databasezy instance.

A logical dump streamed straight into the target: mysqldump --single-transaction --quick --routines --triggers --events --hex-blob | mysql. MariaDB sources are dumped with MariaDB-safe flags (--loose-column-statistics=0, --loose-set-gtid-purged=OFF), because MariaDB has neither MySQL’s COLUMN_STATISTICS table nor MySQL GTIDs.

MySQL to MariaDB is a planned conversion: the dump goes through a rewrite stage that maps utf8mb4_0900_* collations to utf8mb4_uca1400_*, neutralises MySQL-8-only /*!80xxx */ clauses and strips DEFINERs. See engine conversions.

shell
# --dry-run prints the preflight checklist and the exact plan without changing anything
zb migrate --from "mysql://migrator:[email protected]:3306/shop" --engine mariadb --to inst_abc
zb migrate --from ./shop.sql.gz --engine mariadb --to inst_abc
zb migrate --from local --engine mariadb --db shop --to inst_abc # runs mariadb-dump / mysqldump locally

Follow it with zb migrate status <mig_id>, or in the portal under the instance’s Migrate in tab.

Row counts per table, AUTO_INCREMENT values, index count and a schema hash. Mismatches are listed in the result; nothing is switched for you.

  • Copy only: continuous sync is available for MySQL targets, not MariaDB.
  • Users and grants are not copied; Databasezy issues new credentials.
  • From MySQL 8: functional indexes and multi-valued JSON indexes fail the load; JSON columns become LONGTEXT with a json_valid() check.

How migrations work covers preflight, verification and cutover; engine conversions covers moves between engines.