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.
How the copy works
Section titled “How the copy works”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.
Run it
Section titled “Run it”# --dry-run prints the preflight checklist and the exact plan without changing anythingzb migrate --from ./shop.sql.gz --engine mariadb --to inst_abczb migrate --from local --engine mariadb --db shop --to inst_abc # runs mariadb-dump / mysqldump locallyFollow it with zb migrate status <mig_id>, or in the portal under the instance’s Migrate in tab.
What is verified
Section titled “What is verified”Row counts per table, AUTO_INCREMENT values, index count and a schema hash. Mismatches are listed in the result; nothing is switched for you.
Not carried over
Section titled “Not carried over”- 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.