Currently, gausdb t supports one active multi standby deployment and one active multi standby multi-level joint standby deployment. The sum of the number of standby machines and cascade standby machines can support up to 9. This paper is an active and standby environment.
The Primary role in gausdb t is the Primary node in the Primary Standby relationship, that is, the direct processing node of business. It is responsible for communicating with the Standby machine and synchronizing logs with the Standby machine. The Standby role is the Standby node in the Primary Standby relationship, which is read-only. It is mainly used to receive the host log and play back the host business log. When the host is abnormal or exits abnormally, it can switch to the host to ensure the normal business.
1. Environment settings
If there is no special instruction, the following operations are performed on the primary and secondary nodes respectively.
1.1 host information
1.2 install software package
[root@hwd07 ~]# yum install -y zlib readline gcc python python-devel perl-ExtUtils-Embed readline-devel zlib-devel lsof expect mlocate
1.3 kernel parameters
Edit / etc/sysctl.conf and add the following:
[root@hwd07 ~]# vi /etc/sysctl.conf kernel.sem = 50100 128256000 50100 2560 net.core.netdev_max_backlog = 1000 net.ipv4.tcp_max_syn_backlog = 2048 kernel.core_pattern = /tmp/core.%p.%e kernel.core_uses_pid = 1 kernel.shmmni = 4096 net.ipv4.ip_local_port_range = 9000 65500 net.core.rmem_default = 262144 net.core.wmem_default = 262144 net.core.rmem_max = 4194304 net.core.wmem_max = 1048576 fs.aio-max-nr = 1048576 fs.file-max = 6815744 [root@hwd07 ~]# sysctl -p
Edit / etc/profile and add the following:
[root@hwd07 ~]# vi /etc/profile ulimit -c unlimited [root@hwd07 ~]# source /etc/profile
1.4 disable firewall and SElinux
[root@hwd07 ~]# systemctl disable firewalld Removed symlink /etc/systemd/system/multi-user.target.wants/firewalld.service. Removed symlink /etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service. [root@hwd07 ~]# sed -i -e 's,enforcing,disabled,' /etc/selinux/config
1.5 creating users
[root@hwd07 ~]# groupadd dbgrp [root@hwd07 ~]# useradd -g dbgrp -d /home/omm -m -s /bin/bash omm [root@hwd07 ~]# echo redhat|passwd --stdin omm Changing password for user omm. passwd: all authentication tokens updated successfully.
1.6 decompress the software package
[root@hwd07 ~]# mkdir -p /opt/software/gaussdb [root@hwd07 ~]# cd /opt/software/gaussdb/ [root@hwd07 gaussdb]# tar -xzf /tmp/GaussDB_T_1.0.2-DATABASE-REDHAT-64bit.tar.gz
After the above operations are completed, restart the server.
2. Installation configuration
2.1 main node installation configuration
On the primary node, execute the following command to install and create the database:
[root@hwd07 gaussdb]# cd GaussDB_T_1.0.2-DATABASE-REDHAT-64bit/ [root@hwd07 GaussDB_T_1.0.2-DATABASE-REDHAT-64bit]# python install.py -U omm:dbgrp -R /opt/gaussdb/app -D /opt/gaussdb/data -C LSNR_ADDR=127.0.0.1,192.168.120.28 -C LSNR_PORT=1888 -C REPL_PORT=1889 -C "ARCHIVE_DEST_2=SERVICE=192.168.120.29:1889 SYNC" -C SESSIONS=1500 Checking runner. Checking parameters. End check parameters. Checking user. End check user. Checking old install. End check old install. Checking kernel parameters. Checking directory. Checking integrality of run file... Decompressing run file. Setting user env. Checking data dir and config file Initialize db instance. Creating database. [2020-03-13 09:23:43] Instance start log output:starting instance(nomount) instance started . [2020-03-13 09:23:43] start instance successfully, pid = 8981 [2020-03-13 09:23:43] create zenith database ... [2020-03-13 09:36:29] Execute sql file /opt/gaussdb/app/admin/scripts/create_database.sample.sql output: connected. SQL> Succeed. SQL> [2020-03-13 09:36:29] Creating database succeed. [2020-03-13 09:36:29] Changing file permission due to security audit. [2020-03-13 09:36:29] Successfully install zenith instance. [2020-03-13 09:36:29] Install successfully, for more detail information see /home/omm/zengineinstall.log.
Parameter description is as follows:
During installation, you can use the optimized configuration of the default zengine.ini, or you can use - C to modify the parameters to replace the initial configuration. The general parameters that users pay attention to are shown in the following figure:
The following figure shows the parameters that need to be paid attention to during the configuration of the active and standby machines:
2.2 installation of standby node
Execute the following command on the standby machine, only install, do not build the database, and do not start.
[root@hwd08 gaussdb]# cd GaussDB_T_1.0.2-DATABASE-REDHAT-64bit/ [root@hwd08 GaussDB_T_1.0.2-DATABASE-REDHAT-64bit]# python install.py -U omm:dbgrp -R /opt/gaussdb/app -D /opt/gaussdb/data -C LSNR_ADDR=127.0.0.1,192.168.120.29 -C LSNR_PORT=1888 -C REPL_PORT=1889 -C "ARCHIVE_DEST_2=SERVICE=192.168.120.28:1889 SYNC" -O Checking runner. Checking parameters. End check parameters. Checking user. End check user. Checking old install. End check old install. Checking kernel parameters. Checking directory. Checking integrality of run file... Decompressing run file. Setting user env. Checking data dir and config file Initialize db instance. Changing file permission due to security audit. Install successfully, for more detail information see /home/omm/zengineinstall.log.
After the installation, execute the following command with the omm user to rebuild the standby database:
[root@hwd08 GaussDB_T_1.0.2-DATABASE-REDHAT-64bit]# su - omm Last login: Fri Mar 13 09:40:07 CST 2020 [omm@hwd08 ~]$ cd /opt/gaussdb/app/bin/ [omm@hwd08 bin]$ python zctl.py -t build Check if incremental build is available ... Begin to shutdown database ... Done Begin to clear data and log ... Done Begin to startup instance nomount ... Done Is incremental build: False Begin to build database ... Done Successfully build database
2.3 change sys password
It can be executed in the primary node, and the standby node will automatically synchronize.
SQL> ALTER USER SYS IDENTIFIED BY abcABC12 REPLACE Changeme_123;
2.4 query verification
Execute the following commands on the primary and secondary nodes to verify whether the creation is successful:
3. Active standby switching
The active standby switch includes switch over and failover.
3.1 status verification
To query the status on the standby node, allow switching:
SQL> SELECT DATABASE_ROLE, DATABASE_CONDITION, SWITCHOVER_STATUS FROM DV_DATABASE;
If the query result is standby and the status is normal, you can execute switchover on this node.
3.2 normal switching
Perform the switchover operation on the standby machine:
SQL> ALTER DATABASE SWITCHOVER;
Verify whether the switch is successful on the primary and secondary nodes:
Failover is applicable to the failure of the host, and it can not be recovered in a short time. In the case of a cascaded standby, if the host and all the standby machines have failed, the failover upgrade can be performed on the cascaded standby.
Now shut down the database of hwd08, simulate the failure of the primary node, and then perform the failover operation on hwd07.
Close the primary database on hwd08:
The database status on hwd07 is as follows:
The status is disconnected, indicating that it can fail directly, as follows:
Now hwd07 has become the master node. Simulate hwd08 host recovery and rebuild the standby database.
[omm@hwd08 bin]$ python zctl.py -t build -D /opt/gaussdb/data Check if incremental build is available ... Begin to shutdown database ... Done Begin to clear data and log ... Done Begin to startup instance nomount ... Done Is incremental build: False Begin to build database ... Done Successfully build database