Gauss db数据库高可用HA测试

GaussDB 100采用Shared-nothing架构的分布式系统，它是由众多拥有独立且互不共享CPU、内存、存储等系统资源的逻辑节点组成。在这样的系统架构中，业务数据被分散存储在多个主机上，数据访问任务被推送到数据所在位置就近执行，通过控制模块的协调，并行地完成大规模的数据处理工作，实现对数据处理的快速响应。

它提供多种不同的数据库CLI管理工具（例如gs_om、GaussRoach.py等），帮助用户更好地维护GaussDB 100。

Database Manager是一款基于Web的数据库监控工具，提供丰富的界面展示，可有效监控多个集群数据库。通过管理员用户和普通用户区分查看和操作权限，对集群数据库进行安全的监控和运维操作。Database Manager提供的主要功能：

导入并监控集群

集群、主机和实例运行监控

数据库运行监控

故障诊断分析和上报

告警分析和上报

Data Studio是一个集成开发环境，帮助数据库开发人员便捷地构建应用程序的一款工具，以图形化界面形式提供数据库关键特性。Data Studio主要为数据库开发人员提供以下功能：

浏览数据库对象。

创建和管理数据库对象（例如：数据库、user、表、索引）。

执行SQL语句和SQL脚本。

编辑和执行PL/SQL语句。

软件架构如图所示：

各个模块的详细介绍

名称	描述	说明
CM	集群管理模块（Cluster Manager）。管理和监控分布式系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。	CM由CM Agent、daemon和CM Server组成： CM Agent：负责监控所在主机上CN、主备DN的运行状态并将状态上报给CM Server。同时负责执行CM Server下发的仲裁指令。GaussDB 100集群的每台主机上均有CM Agent进程。 daemon ：看护CM Agent的定时任务。负责在CM Agent意外停止的情况下将CM Agent重启。 CM Server：根据CM Agent上报的实例状态判定当前是否需要修复，并下发指令给CM Agent执行。 GaussDB 100提供了CM Server的主备实例方案，以保证集群管理系统本身的高可用性。正常情况下，CM Agent连接主CM Server，在主CM Server发生故障的情况下，备CM Server会主动升为主CM Server，避免出现CM Server单点故障。
DN	数据节点（Datanode）。负责存储业务数据，执行数据查询任务以及向CN返回执行结果。	在集群中，DN有多个。每个DN支持设置多个存储备机。 DN主、备机1、备机2、备机3间的工作原理如下： 主机同时向备机1，备机2同步数据。 主、备机1间无法正常同步数据时，主DN会持续向备机2同步数据，不会阻塞。 主、备机1间数据同步恢复正常后，主DN会将异常期间的数据同步到备机1DN上。 备机1DN从主DN同步数据期间，如果主DN突然故障不可用。此时，备机2升主，备机3不会升主，只有手动切换或者同城所有DN故障备机3才会升主 。
ETCD	ETCD是一个高可用的分布式键值(key-value)数据库。	负责存储集群各个节点和实例集群状态，便于集群CM管理各个实例。 在集群中，ETCD部署3~7个，推荐部署奇数（3、5、7）个，奇数个节点和其配对的偶数个节点相比，容错能力相同，却可以少一个节点。角色分leader和follower。ETCD leader和ETCD follower间工作原理如下： ETCD leader同时向所有ETCD follower同步数据。 写入数据到ETCD leader时，会根据raft一致性协议，与ETCD follower达成大多数一致后才能写入成功。 当ETCD 没有leader时，所有ETCD follower会自发启动抢主流程，重新选举出新的ETCD leader。
Storage	服务器的本地存储资源，持久化存储数据。	-

目标

（1）主节点，主机名：node1,IP:192.168.100.11

（2）备节点，主机名: node2,IP:192.168.100.12

1.1 修改主机名：

Node2:

[root@gaussdb1 ~]# vi /etc/hosts

127.0.0.1   localhostlocalhost.localdomain localhost4 localhost4.localdomain4

::1         localhostlocalhost.localdomain localhost6 localhost6.localdomain6

192.168.100.12  node2  node2.db

[root@gaussdb1 ~]# cat /etc/hostname

node2

重启查看主机名

1.2 修改node2IP ADDRESS

[root@node2 network-scripts]# pwd

/etc/sysconfig/network-scripts

[root@node2 network-scripts]# vi ifcfg-ens33

1.3 修改数据库监听地址：

[omm@node2 cfg]$ cat zengine.ini

TEMP_BUFFER_SIZE = 1G

DATA_BUFFER_SIZE = 1G

SHARED_POOL_SIZE = 512m

LOG_BUFFER_SIZE = 64M

DBWR_PROCESSES = 8

LOG_BUFFER_COUNT = 8

SESSIONS = 1500

INSTANCE_NAME = zenith

LSNR_ADDR = 127.0.0.1,192.168.100.12

LSNR_PORT = 1611

ENABLE_SYSDBA_LOGIN = TRUE

CONTROL_FILES = (/opt/gaussdb/data/data/cntl1,/opt/gaussdb/data/data/cntl2, /opt/gaussdb/data/data/cntl3)

LONGSQL_TIMEOUT = 20 

1.4 启动Node2数据库

[omm@node2 cfg]$ zctl.py -t start

Successfully started instance.

[omm@node2 cfg]$ zsql / as sysdba -q

connected.

2、修改参数（两个节点都要做）

（1）node1主机点参数修改：

[omm@node1 cfg]$ pwd

/opt/gaussdb/data/cfg

[omm@node1 cfg]$ cat zengine.ini

TEMP_BUFFER_SIZE = 1G

DATA_BUFFER_SIZE = 1G

SHARED_POOL_SIZE = 512m

LOG_BUFFER_SIZE = 64M

DBWR_PROCESSES = 8

LOG_BUFFER_COUNT = 8

SESSIONS = 1500

INSTANCE_NAME = zenith

LSNR_ADDR = 127.0.0.1,192.168.100.11

LSNR_PORT = 1888

ENABLE_SYSDBA_LOGIN = TRUE

CONTROL_FILES = (/opt/gaussdb/data/data/cntl1,/opt/gaussdb/data/data/cntl2, /opt/gaussdb/data/data/cntl3)

LONGSQL_TIMEOUT = 20

REPL_PORT =1889

ARCHIVE_DEST_2=local_host=192.168.100.11 SERVICE=192.168.100.12:1889 SYNC PRIMARY_ROLE 

（2）node2备节点参数修改：

[omm@node2 cfg]$ cat zengine.ini

TEMP_BUFFER_SIZE = 1G

DATA_BUFFER_SIZE = 1G

SHARED_POOL_SIZE = 512m

LOG_BUFFER_SIZE = 64M

DBWR_PROCESSES = 8

LOG_BUFFER_COUNT = 8

SESSIONS = 1500

INSTANCE_NAME = zenith

LSNR_ADDR = 127.0.0.1,192.168.100.12

LSNR_PORT = 1888

ENABLE_SYSDBA_LOGIN = TRUE

CONTROL_FILES = (/opt/gaussdb/data/data/cntl1,/opt/gaussdb/data/data/cntl2, /opt/gaussdb/data/data/cntl3)

LONGSQL_TIMEOUT = 20

REPL_PORT =1889

ARCHIVE_DEST_2= local_host=192.168.100.12 SERVICE=192.168.100.11:1889 SYNC PRIMARY_ROLE

（3）登录备库，在备库重建数据库（在nomount下）

[omm@node2 ~]$ cd /opt/gaussdb/app/bin/

[omm@node2 bin]$ python zctl.py -t start -m nomount

Successfully started instance.

[omm@node2 bin]$ zsql / as sysdba -q

connected. 

SQL> build database;

GS-00855, build failed, Failed to create the file/opt/gaussdb/data/data/cntl1, the error code was 17 

【解决】删掉备机/opt/gaussdb/data/data/目录下的数据，重新执行 build database

SQL> build database;

Succeed. 

SQL> shutdown immediate;

Succeed.

SQL> exit 

[omm@node2 gaussdb]$ zctl.py -t start

Successfully started instance.

[omm@node2 gaussdb]$ zsql / as sysdba -q

connected.

3、验证数据库HA

（1）主节点状态：

[omm@node1 gaussdb]$ zsql / as sysdba -q

connected. 

SQL>select dbid,name,status,open_status,database_role,database_condition,switchover_status,failover_statusfrom v$database

   DBID  NAME   STATUS OPEN_STATUS   DATABASE_ROLE   DATABASE_CONDITIONSWITCHOVER_STATUS    FAILOVER_STATUS    

   ------------ ---------- --------------- ---------------------------------------- ------------------ -------------

   1848142806   GAUSS  OPEN   READ WRITE   PRIMARY     NORMAL    NOT ALLOWED      NOT ALLOWED         

1 rows fetched. 

（2）备库状态：

SQL>select dbid,name,status,open_status,database_role,database_condition,switchover_status,failover_status from v$database;

DBID   NAME   STATUS  OPEN_STATUS  DATABASE_ROLE   DATABASE_CONDITION   SWITCHOVER_STATUS    FAILOVER_STATUS    

------------ ------------ ------------ ----------------------------------------- ------------------ ------------------------------------

1848142806   GAUSS  OPEN  READ ONLY    PHYSICAL_STANDBY      NORMAL    TO PRIMARY   TO PRIMARY         

1 rows fetched.

4、HA相关测试

4.1 Switchover测试：

  （1）备机发起切换，切换前先查看备机状态：

SQL>select dbid,name,status,open_status,database_role,database_condition,switchover_status,failover_statusfrom v$database;

  （2）发起切换命令（备机现在转换成主机）：

SQL> alter database switchover;

Succeed.

  （3）在查看原主节点（已经变为备机）

4.2 Failover测试

经过4.1测试此时我的node1节点为备库，Node2为主库

（1）测试关闭主库Node2服务：

[omm@node2 bin]$ python zctl.py -t stop

Successfully stopped instance.

（2）此时查看Node1节点状态：

（3）在Node1备库执行failover命令，进行切换：

SQL>alter database failover;

（4）在启动原来停掉的库到mount状态。

[omm@node2 bin]$ python zctl.py -t start -m mount

Successfully started instance.

[omm@node2 bin]$ zsql / as sysdba -q

connected.

SQL> alter database convert to physical standby;

Succeed.

再次查看这个节点状态：

注意：

原主库一定要启动到nomount状态，如果启动到open状态会有双主脑裂，而且必须重建备库。

另外如果原主库异常宕机，备库A执行failover后原主库在mount状态下转换为standby也是不用执行重建的。

另外，在业务不断运行的情况下，如果主库宕机，在备库A执行failover，备库A上的业务也一直运行，然后此时备库B查看状态可能有短暂的disconnect，追平后就会变为normal，同时原主库启动到mount再转换为备库后也可能会有短暂的disconnect，追平后会变为normal。

5、数据同步测试

略

数据保护模式

数据保护模式，和oracle一样，有三种保护模式，保护模式只在主机上有用，但是生产环境建议主备都进行设置，防止主备切换后保护模式变化，保护模式不会自动同步。

最大保护模式

最大保护模式下：（主备均设置）

python $GSDB_HOME/bin/zctl.py -t start -m mount

SQL> alter database set standby database to maximize protection;

Succeed.

SQL> select PROTECTION_MODEfrom dv_database;

PROTECTION_MODE     

--------------------

MAXIMUM_PROTECTION

①LOG归档的备机地址ARCHIVE_DEST_n（n不等于1），至少有一个备机的Redo日志传输模式必须配置为同步模式SYNC，如果所有的备机都配置为异步模式ASYNC，数据库会启动失败。

②如果LOG归档的备机地址ARCHIVE_DEST_n（n不等于1）指定了SYNC和AFFIRM属性，那么事务日志写入所有指定AFFIRM的备库日志文件后，才会在主库上提交。

③如果LOG归档的备机地址ARCHIVE_DEST_n（n不等于1）指定了SYNC和NAFFIRM属性，那么无需等待备机写入，事务日志将直接写入主库。

最大可用模式

建议生产环境下使用该模式，最大可用模式下：（主备均设置）

SQL> alter database set standby database to maximize availability;

Succeed.

SQL> select PROTECTION_MODEfrom dv_database;

PROTECTION_MODE     

--------------------

MAXIMUM_AVAILABILITY

①如果LOG归档的备机地址ARCHIVE_DEST_n（n不等于1）指定了SYNC和AFFIRM属性，且指定了AFFIRM的备机和主机连接正常时，那么事务日志写入所有指定AFFIRM的备库日志文件后，才会在主库上提交。

②如果LOG归档的备机地址ARCHIVE_DEST_n（n不等于1）指定了SYNC和NAFFIRM属性，那么无需等待备机写入，事务日志将直接写入主库。

最大性能模式

这是默认的模式，不建议生产环境使用，最大性能模式下：（主备均设置）

SQL> alter database set standby database to maximize performance;

Succeed.

SQL> select PROTECTION_MODEfrom dv_database;

PROTECTION_MODE     

--------------------

MAXIMUM_PERFORMANCE 

主库可以使用LGWR SYNC/ASYNC复制到备库，该保护模式设置没有状态要求