dbdeployer features

March 31, 2019 · View on GitHub

This table compares features from MySQL-Sandbox and dbdeployer.

FeatureMySQL-Sandboxdbdeployerdbdeployer planned
Single sandbox deploymentyesyes
unpack commandsort of 1yes
multiple sandboxesyesyes
master-slave replicationyesyes
"force" flagyesyes
pre-post grants SQL actionyesyes
initialization optionsyesyes
my.cnf optionsyesyes
custom my.cnfyesyes
friendly UUID generationyesyes
global commandsyesyes
test replication flowyesyes
delete commandyes 2yes
show data dictionary tablesyesyes
lock/unlock sandboxesyesyes
finding free portsyesyes
semi-sync replicationyesyes
group replication SPnoyes
group replication MPnoyes
prevent port collisionnoyes 3
visible initializationnoyes 4
visible script templatesnoyes 5
replaceable templatesnoyes 6
configurable defaultsnoyes 7
list of source binariesnoyes 8
list of installed sandboxesnoyes 9
test script per sandboxnoyes 10
integrated usage helpnoyes 11
custom abbreviationsnoyes 12
version flagnoyes 13
sandboxes global catalognoyes
concurrent deploymentnoyes
command line completionnoyes
MySQL upgradenoyes
MySQLX supportnoyes
fan-innoyes 14
all-mastersnoyes 15
Percona Xtradb clusternoyes
MySQL Clusternoyes
Inter-sandbox replicationlimited 16yes
pre-post grants shell actionyesnomaybe
getting remote tarballsyesyes
load pluginsyesyes 17
circular replicationyessort of 18
master-master (circular)yesnono
Windows supportnono 19

Footnotes

  1. It's achieved using --export_binaries and then abandoning the operation. ↩

  2. Uses the sbtool command ↩

  3. dbdeployer sandboxes store their ports in a description JSON file, which allows the tool to get a list of used ports and act before a conflict happens. ↩

  4. The initialization happens with a script that is generated and stored in the sandbox itself. Users can inspect the init_db script and see what was executed. ↩

  5. All sandbox scripts are generated using templates, which can be examined and eventually changed and re-imported. ↩

  6. See also note 5. Using the flag --use-template you can replace an existing template on-the-fly. Group of templates can be exported and imported after editing. ↩

  7. Defaults can be exported to file, and eventually re-imported after editing. ↩

  8. This is little more than using an O.S. file listing, with the added awareness of the source directory. ↩

  9. Using the description files, this command lists the sandboxes with their topology and used ports. ↩

  10. It's a basic test that checks whether the sandbox is running and is using the expected port. ↩

  11. The "usage" command will show basic commands for single and multiple sandboxes. ↩

  12. the abbreviations file allows user to define custom shortcuts for frequently used commands. ↩

  13. Strangely enough, this simple feature was never implemented for MySQL-Sandbox, while it was one of the first additions to dbdeployer. ↩

  14. Uses the multi source technology introduced in MySQL 5.7. ↩

  15. Same as n. 14. ↩

  16. Single sandboxes could replicate from another using option --slaveof ↩

  17. Using pre-grants and post-grants options, all plugins can be loaded. ↩

  18. Circular replication should not be used anymore. There are enough good alternatives (multi-source, group replication) to avoid this old technology. However, using the script replicate_from, it is possible to run circular replication. There is an example in the cookbook. ↩

  19. I don't do Windows. But you can fork the project if you do. ↩