-
sousaedu authored
Change-Id: I7b3290ca9d9fdb0c3b9521f8d12c4ba76ddcbbcb Signed-off-by:
sousaedu <eduardo.sousa@canonical.com>
958cf65b
Overview
mysql for Kubernetes
Usage
You must specify key configuration attributes when deploying, or else arbitary defaults will be used. The attributes which should be set are:
- user
- password
- database
- root_password
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
Actions
Backup
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|SECONDARY
if you want this action to be run in a specific mongo unit. IfSECONDARY
is set, but the mongo unit isn't theSECONDARY
, the action will fail.
Restore
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
Remove backup
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
Backup remotely
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-databases
is 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
Testing
The tests of this charm are done using tox and Zaza.
Prepare environment
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
Test charm with Tox
tox -e black # Check syntax
tox -e build # Build the charm
tox -e func # Test charm