[HOME]
Before version 1.19.0, dbdeployer assumed that it was dealing to some version of MySQL, using the version to decide which features it would support. In version 1.19.0 dbdeployer started using the concept of capabilities, which is a combination of server flavor + a version. Some flavors currently supported are
mysql: the classic MySQL serverpercona: Percona Server, any version. For the purposes of deployment, it has the same capabilities as MySQLmariadb: MariaDB server. Mostly the same as MySQL, but with differences in deployment methods.pxc: Percona Xtradb Clusterndb: MySQL Cluster (NDB)tidb: A stand-alone TiDB server.villagesql: VillageSQL server, a MySQL drop-in replacement with extensions. It uses the same capabilities as MySQL and is detected by the presence ofshare/villagesql_schema.sqlin the tarball.
To see what every flavor can do, you can use the command dbdeployer admin capabilities.
To see the features of a given flavor: dbdeployer admin capabilities FLAVOR.
And to see what a given version of a flavor can do, you can use dbdeployer admin capabilities FLAVOR VERSION.
For example
$ dbdeployer admin capabilities
$ dbdeployer admin capabilities percona
$ dbdeployer admin capabilities mysql 5.7.11
$ dbdeployer admin capabilities mysql 5.7.13VillageSQL is a MySQL drop-in replacement with extensions (custom types, VDFs). dbdeployer supports it as a first-class flavor starting from version 2.2.2.
Download the VillageSQL tarball from GitHub Releases:
curl -L -o villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz \
https://github.com/villagesql/villagesql-server/releases/download/0.0.3/villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gzVillageSQL uses its own version scheme (0.0.3) which does not correspond to MySQL's version numbers. Since VillageSQL is built on MySQL 8.x, you must tell dbdeployer which MySQL version to use for capability lookups:
dbdeployer unpack villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz --unpack-version=8.0.40This maps VillageSQL to MySQL 8.0.40 capabilities (mysqld --initialize, CREATE USER, GTID, etc.), which is required for sandbox deployment to work. Without --unpack-version, dbdeployer would extract version 0.0.3, which is below every MySQL capability threshold, resulting in a broken init script.
You can verify the flavor was detected correctly:
$ cat ~/opt/mysql/8.0.40/FLAVOR
villagesqldbdeployer deploy single 8.0.40
~/sandboxes/msb_8_0_40/use -e "SELECT VERSION();"
# +-----------------------------------------+
# | VERSION() |
# +-----------------------------------------+
# | 8.4.8-villagesql-0.0.3-dev-78e24815 |
# +-----------------------------------------+dbdeployer deploy replication 8.0.40
~/sandboxes/rsandbox_8_0_40/test_replicationThe VillageSQL 0.0.3 tarball contains two symlinks that point outside the extraction directory:
mysql-test/suite/villagesql/examples/vsql-complex -> ../../../../villagesql/examples/vsql-complex/test
mysql-test/suite/villagesql/examples/vsql-tvector -> ../../../../villagesql/examples/vsql-tvector/test
dbdeployer's security check rejects these. If you encounter this error, remove the broken symlinks before unpacking:
tar xzf villagesql-dev-server-0.0.3-dev-linux-x86_64.tar.gz
rm -f villagesql-dev-server-0.0.3-dev-linux-x86_64/mysql-test/suite/villagesql/examples/vsql-complex
rm -f villagesql-dev-server-0.0.3-dev-linux-x86_64/mysql-test/suite/villagesql/examples/vsql-tvector
tar czf villagesql-clean.tar.gz villagesql-dev-server-0.0.3-dev-linux-x86_64
dbdeployer unpack villagesql-clean.tar.gz --unpack-version=8.0.40This issue is tracked at villagesql/villagesql-server#237.