mysql for Kubernetes
You must specify key configuration attributes when deploying, or else arbitary defaults will be used. The attributes which should be set are:
eg
$ juju deploy mysql
--config user=fred
--config password=secret
--config database=test
--config root_password=admin
These values may also be in a config.yaml file, eg
$ juju deploy mysql --config config.yaml
Execute the following steps to do a backup.
$ juju run-action mariadb-k8s/0 backup --wait unit-mariadb-k8s-0: UnitId: mariadb-k8s/0 id: "1" results: copy: cmd: kubectl cp zaza-9769f2bf245e/mariadb-k8s-0:/var/lib/mysql/backup.sql.gz backup.sql.gz restore: cmd: kubectl cp backup.sql.gz zaza-9769f2bf245e/mariadb-k8s-0:/var/lib/mysql/backup.sql.gz juju: juju run-action mariadb-k8s/0 restore --wait status: completed timing: completed: 2020-02-27 14:16:09 +0000 UTC enqueued: 2020-02-27 14:16:08 +0000 UTC started: 2020-02-27 14:16:09 +0000 UTC $ kubectl cp zaza-9769f2bf245e/mariadb-k8s-0:/var/lib/mysql/backup.sql.gz backup.sql.gz
Additional note: You can add
--string-args target=PRIMARY|SECONDARYif you want this action to be run in a specific mongo unit. IfSECONDARYis set, but the mongo unit isn't theSECONDARY, the action will fail.
When the backup function is executed, you will see the commands you need to execute for restoring from a backup.
$ kubectl cp backup.sql.gz zaza-9769f2bf245e/mariadb-k8s-0:/var/lib/mysql/backup.sql.gz $ juju run-action mariadb-k8s/0 restore --wait unit-mariadb-k8s-0: UnitId: mariadb-k8s/0 id: "2" results: message: Backup restored successfully status: completed timing: completed: 2020-02-27 14:18:17 +0000 UTC enqueued: 2020-02-27 14:18:07 +0000 UTC started: 2020-02-27 14:18:11 +0000 UTC
When a backup is made, it is stored in the unit. To easily remove the backup, execute this action:
$ juju run-action mariadb-k8s/0 remove-backup --wait unit-mariadb-k8s-0: UnitId: mariadb-k8s/0 id: "3" results: Stdout: | Backup successfully removed! status: completed timing: completed: 2020-02-27 14:18:41 +0000 UTC enqueued: 2020-02-27 14:18:36 +0000 UTC started: 2020-02-27 14:18:41 +0000 UTC
If we want to perform a backup remotely, follow the next steps:
$ sudo apt install mariadb-client-10.1 -y $ juju status mariadb-k8s Model Controller Cloud/Region Version SLA Timestamp zaza-9769f2bf245e microk8s-localhost microk8s/localhost 2.7.2 unsupported 15:20:42+01:00 App Version Status Scale Charm Store Rev OS Address Notes mariadb-k8s rocks.canonical... active 2 mariadb-k8s local 0 kubernetes 10.152.183.109 Unit Workload Agent Address Ports Message mariadb-k8s/0* active idle 10.1.31.185 3306/TCP,4444/TCP,4567/TCP,4568/TCP ready mariadb-k8s/1 active idle 10.1.31.186 3306/TCP,4444/TCP,4567/TCP,4568/TCP ready $ mysqldump -uroot -posm4u --single-transaction \ --databases database \ --host 10.152.183.109 \ --port 3306 | gzip > backup.sql.gz $ gunzip -c backup.sql.gz | mysql -uroot -posm4u --host 10.152.183.109 --port 3306
Note: The remote backups should be done for each database. If
--all-databasesis step, when restoring from a database, you will see this error:ERROR 1556 (HY000) at line 825: You can't use locks with log tables
The tests of this charm are done using tox and Zaza.
The machine in which the tests are run needs access to a juju k8s controller. The easiest way to approach this is by executing the following commands:
sudo apt install tox -y sudo snap install microk8s --classic sudo snap install juju microk8s.status --wait-ready microk8s.enable storage dns juju bootstrap microk8s k8s-cloud
tox -e black # Check syntax tox -e build # Build the charm tox -e func # Test charm