Customizing dbdeployer


As of version 0.2.1, dbdeployer allows users to customize composite sandboxes more than ever. This is done by manipulating the default settings, which are used to deploy the sandbox templates.

In order to appreciate the customization capabilities, let's start with a vanilla deployment, and then we have a look at the possible changes.

$ dbdeployer deploy replication 8.0.4
Installing and starting master
Database installed in $HOME/sandboxes/rsandbox_8_0_4/master
. sandbox server started
Installing and starting slave 1
Database installed in $HOME/sandboxes/rsandbox_8_0_4/node1
. sandbox server started
Installing and starting slave 2
Database installed in $HOME/sandboxes/rsandbox_8_0_4/node2
. sandbox server started
$HOME/sandboxes/rsandbox_8_0_4/initialize_slaves
initializing slave 1
initializing slave 2
Replication directory installed in $HOME/sandboxes/rsandbox_8_0_4
run 'dbdeployer usage multiple' for basic instructions'

A regular replication sandbox has one master and two slaves. Each slave is inside a directory called nodeX.

The resulting sandbox has a directory called master, two nodeX directories, a shortcut for the master called m, and two shortcuts for the slaves called s1 and s2. There are also two management scripts called initialize_slaves and check_slaves.

    $ ls -l ~/sandboxes/rsandbox_8_0_4/
total 152
-rwxr--r-- 1 user staff 1500 Mar 5 06:21 check_slaves
-rwxr--r-- 1 user staff 1160 Mar 5 06:21 clear_all
-rwxr--r-- 1 user staff 1617 Mar 5 06:21 initialize_slaves
-rwxr--r-- 1 user staff 806 Mar 5 06:21 m
drwxr-xr-x 22 user staff 748 Mar 5 06:21 master
-rwxr--r-- 1 user staff 806 Mar 5 06:21 n1
-rwxr--r-- 1 user staff 804 Mar 5 06:21 n2
-rwxr--r-- 1 user staff 804 Mar 5 06:21 n3
drwxr-xr-x 23 user staff 782 Mar 5 06:21 node1
drwxr-xr-x 23 user staff 782 Mar 5 06:21 node2
-rwxr--r-- 1 user staff 855 Mar 5 06:21 restart_all
-rwxr--r-- 1 user staff 804 Mar 5 06:21 s1
-rwxr--r-- 1 user staff 804 Mar 5 06:21 s2
-rw-r--r-- 1 user staff 173 Mar 5 06:21 sbdescription.json
-rwxr--r-- 1 user staff 1127 Mar 5 06:21 send_kill_all
-rwxr--r-- 1 user staff 1296 Mar 5 06:21 start_all
-rwxr--r-- 1 user staff 1680 Mar 5 06:21 status_all
-rwxr--r-- 1 user staff 1087 Mar 5 06:21 stop_all
-rwxr--r-- 1 user staff 4598 Mar 5 06:21 test_replication
-rwxr--r-- 1 user staff 1315 Mar 5 06:21 test_sb_all
-rwxr--r-- 1 user staff 1100 Mar 5 06:21 use_all

Now, let's see how we can change this. We'll start by listing the current defaults

$ dbdeployer defaults show
# Internal values:
{
"version": "0.2.1",
"sandbox-home": "$HOME/sandboxes",
"sandbox-binary": "$HOME/opt/mysql",
"master-slave-base-port": 11000,
"group-replication-base-port": 12000,
"group-replication-sp-base-port": 13000,
"fan-in-replication-base-port": 14000,
"all-masters-replication-base-port": 15000,
"multiple-base-port": 16000,
"group-port-delta": 125,
"master-name": "master",
"master-abbr": "m",
"node-prefix": "node",
"slave-prefix": "slave",
"slave-abbr": "s",
"sandbox-prefix": "msb_",
"master-slave-prefix": "rsandbox_",
"group-prefix": "group_msb_",
"group-sp-prefix": "group_sp_msb_",
"multiple-prefix": "multi_msb_",
"fan-in-prefix": "fan_in_msb_",
"all-masters-prefix": "all_masters_msb_"
}

The values that we want to change are master-name, master-abbr, node-prefix, slave-prefix, and slave-abbr. We can export the defaults to a file, and import them after editing the values we want to change.

$ dbdeployer defaults export defaults.json
# Defaults exported to file defaults.json
$ vim defaults.json
$ dbdeployer defaults import defaults.json
Defaults imported from defaults.json into $HOME/.dbdeployer/config.json

Now dbdeployer is using the new defaults.


$ dbdeployer defaults show
# Configuration file: $HOME/.dbdeployer/config.json
{
"version": "0.2.1",
"sandbox-home": "/Users/gmax/sandboxes",
"sandbox-binary": "/Users/gmax/opt/mysql",
"master-slave-base-port": 11000,
"group-replication-base-port": 12000,
"group-replication-sp-base-port": 13000,
"fan-in-replication-base-port": 14000,
"all-masters-replication-base-port": 15000,
"multiple-base-port": 16000,
"group-port-delta": 125,
"master-name": "primary",
"master-abbr": "p",
"node-prefix": "branch",
"slave-prefix": "replica",
"slave-abbr": "r",
"sandbox-prefix": "msb_",
"master-slave-prefix": "rsandbox_",
"group-prefix": "group_msb_",
"group-sp-prefix": "group_sp_msb_",
"multiple-prefix": "multi_msb_",
"fan-in-prefix": "fan_in_msb_",
"all-masters-prefix": "all_masters_msb_"
}
We have now *primary* for *master*, *replica* for *slave*, *branch* for *node*, and the abbreviations for master and slave changed to *p* and *r* respectively.
Let's see how these defaults can play together when we run the same command as we did before for replication. We first remove the previous deployment.

$ dbdeployer delete rsandbox_8_0_4
List of deployed sandboxes:
$HOME/sandboxes/rsandbox_8_0_4
Running $HOME/sandboxes/rsandbox_8_0_4/stop_all
# executing "stop" on $HOME/sandboxes/rsandbox_8_0_4
executing "stop" on slave 1
executing "stop" on slave 2
executing "stop" on master
Running rm -rf $HOME/sandboxes/rsandbox_8_0_4
Sandbox $HOME/sandboxes/rsandbox_8_0_4 deleted

The deployment command is the same as before, but the output changes:

$ dbdeployer deploy replication 8.0.4
Installing and starting primary
Database installed in $HOME/sandboxes/rsandbox_8_0_4/primary
. sandbox server started
Installing and starting replica 1
Database installed in $HOME/sandboxes/rsandbox_8_0_4/branch1
. sandbox server started
Installing and starting replica 2
Database installed in $HOME/sandboxes/rsandbox_8_0_4/branch2
.. sandbox server started
$HOME/sandboxes/rsandbox_8_0_4/initialize_replicas
initializing replica 1
initializing replica 2
Replication directory installed in $HOME/sandboxes/rsandbox_8_0_4
run 'dbdeployer usage multiple' for basic instructions'

This looks already as if our defaults have been adopted. Let's see the sandbox itself:

$ ls -l ~/sandboxes/rsandbox_8_0_4/
total 152
drwxr-xr-x 23 user staff 782 Mar 5 06:45 branch1
drwxr-xr-x 23 user staff 782 Mar 5 06:45 branch2
-rwxr--r-- 1 user staff 1515 Mar 5 06:45 check_replicas
-rwxr--r-- 1 user staff 1170 Mar 5 06:45 clear_all
-rwxr--r-- 1 user staff 1629 Mar 5 06:45 initialize_replicas
-rwxr--r-- 1 user staff 807 Mar 5 06:45 n1
-rwxr--r-- 1 user staff 806 Mar 5 06:45 n2
-rwxr--r-- 1 user staff 806 Mar 5 06:45 n3
-rwxr--r-- 1 user staff 807 Mar 5 06:45 p
drwxr-xr-x 22 user staff 748 Mar 5 06:45 primary
-rwxr--r-- 1 user staff 806 Mar 5 06:45 r1
-rwxr--r-- 1 user staff 806 Mar 5 06:45 r2
-rwxr--r-- 1 user staff 855 Mar 5 06:45 restart_all
-rw-r--r-- 1 user staff 173 Mar 5 06:45 sbdescription.json
-rwxr--r-- 1 user staff 1137 Mar 5 06:45 send_kill_all
-rwxr--r-- 1 user staff 1308 Mar 5 06:45 start_all
-rwxr--r-- 1 user staff 1700 Mar 5 06:45 status_all
-rwxr--r-- 1 user staff 1097 Mar 5 06:45 stop_all
-rwxr--r-- 1 user staff 4613 Mar 5 06:45 test_replication
-rwxr--r-- 1 user staff 1325 Mar 5 06:45 test_sb_all
-rwxr--r-- 1 user staff 1106 Mar 5 06:45 use_all

We see that the new defaults were used and the script names have changed. But the differences are deeper than this. Also the internal values in the scripts were changed accordingly.

$ ~/sandboxes/rsandbox_8_0_4/test_replication
# primary log: mysql-bin.000001 - Position: 14073 - Rows: 20
# Testing replica #1
ok - replica #1 acknowledged reception of transactions from primary
ok - replica #1 IO thread is running
ok - replica #1 SQL thread is running
ok - Table t1 found on replica #1
ok - Table t1 has 20 rows on #1
# Testing replica #2
ok - replica #2 acknowledged reception of transactions from primary
ok - replica #2 IO thread is running
ok - replica #2 SQL thread is running
ok - Table t1 found on replica #2
ok - Table t1 has 20 rows on #2
# Tests : 10
# failed: 0 ( 0.0%)
# PASSED: 10 (100.0%)
# exit code: 0

The test script calls the components with the names that we defined in the new defaults. Let's have a look at what the shortcuts for the master and slaves (now primary and replicas) do:

$ ~/sandboxes/rsandbox_8_0_4/p
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 35
Server version: 8.0.4-rc-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

primary [localhost] {msandbox} ((none)) >

$ ~/sandboxes/rsandbox_8_0_4/r1
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 15
Server version: 8.0.4-rc-log MySQL Community Server (GPL)

Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

replica1 [localhost] {msandbox} ((none)) >

Also the internal prompt has been adapted to the new naming.

Should we want to revert to the old behavior, we can just reset the defaults:

$ dbdeployer defaults reset
#File $HOME/.dbdeployer/config.json removed

The current replication sandbox is left untouched, but the next one will use the default values.

If we don't want to change the defaults permanently, there is an alternative. The --defaults flag allows us to change defaults on-the-fly just for the command we're running. For example, we could have achieved the same result, without editing the configuration file, using this command:

    dbdeployer deploy replication 8.0.4 \
--defaults=master-name:primary \
--defaults=master-abbr:p \
--defaults=slave-prefix:replica \
--defaults=slave-abbr:r \
--defaults=node-prefix:branch

The syntax for --defaults requires the name of the variable and the new value, separated by a colon. The flag can be used as many times as needed.

关注dbDao.com的新浪微博

扫码加入微信Oracle小密圈,了解Oracle最新技术下载分享资源

TEL/電話+86 13764045638
Email service@parnassusdata.com
QQ 47079569