南大通用GBase 8c 同步复制模式切换场景实践原文链接：https://www.gbase.cn/community

原文链接：www.gbase.cn/community/p…
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。

南大通用GBase 8c支持主备式、分布式等部署方式。本文以主备式场景为例，展示同步复制模式切换如何操作。

一、环境准备

可以使用 gs_om -t status --detail 命令来查看gbase主备详细状态信息，如下所示：

gs_om -t status --detail

#返回如下信息：
[  CMServer State   ]
node                   node_ip         instance                                 state
---------------------------------------------------------------------------------------
1  gbase8c-primary.com 192.x.x.121      1    /dbdata/gbase/database/cm/cm_server Primary
2  gbase8c-standby.com 192.x.x.122      2    /dbdata/gbase/database/cm/cm_server Standby
[   Cluster State   ]
cluster_state   : Normal
redistributing  : No
balanced        : Yes
current_az      : AZ_ALL
[  Datanode State   ]
node                   node_ip         instance                               state
-----------------------------------------------------------------------------------------------
1  gbase8c-primary.com 192.x.x.121 6001 /dbdata/gbase/database/data/dn1_1 P Primary Normal
2  gbase8c-standby.com 192.x.x.122 6002 /dbdata/gbase/database/data/dn1_2 S Standby Normal

CMServer和 Datanode 分别有自己的主备，两个都可以数量不一样，比如 node1、node2、node3 安装CMServer，node2和node3 安装 DB。当CMServer State和Cluster State的主备状态不对应的时候，说明之前这套主备环境曾做过主备切换。

1.1、CMServer State

CMServer是cm的服务端，负责收集CMA(Cluster Management Agent)【集群管理代理】上报的状态，并作为仲裁中心和全局配置中心，主备集群能否稳定运行以及在发生单点故障后，GBase 8c 备库能否正常切换为主库来保证集群的可用性，都与CMServer是否稳定有很紧密的关系。

CMServer状态可能是如下几种状态中的一种：

Normal（正常状态）：集群管理服务器正常运行，能够管理和监控整个数据库集群的各个节点。
Degraded（降级状态）：集群管理服务器可能出现了部分功能的问题或故障，导致其功能降低。
Fault（故障状态）：集群管理服务器可能发生了严重的故障，导致无法正常管理和监控数据库集群。
Pending（待命状态）：集群管理服务器正在进行状态切换，可能是从备用服务器切换为主服务器，或者从主服务器降级为备用服务器。
Unknown（未知状态）：集群管理服务器的状态无法确定，可能是由于网络故障或通信问题导致状态不明确。

1.2、Datanode State

Datanode State（数据节点状态）是指数据库集群中每个数据节点的运行状态。数据节点是分布式数据库集群中的基本组成单元，负责存储数据和处理数据库操作。每个数据节点都可以是主节点或备节点，用于实现高可用性和容灾保护。

Datanode State状态可能是以下几种状态的一种：

Primary（主节点）：数据节点被选举为主节点，负责处理客户端请求、执行事务以及维护数据的最新状态。
Standby（备节点）：数据节点作为备节点，实时复制主节点的数据，并可以在主节点故障时接管服务，保障数据库的持续可用性。
Pending（待命状态）：数据节点正在进行状态切换，可能是从备节点升级为主节点，或者从主节点降级为备节点。
Unknown（未知状态）：数据节点的状态无法确定，可能是由于网络故障或通信问题导致状态不明确。
Offline（离线状态）：数据节点不可用，可能是由于硬件故障、网络问题或其他原因导致节点无法正常运行。

二、复制模式切换

2.1 复制模式

gbase 部署了主备环境后，可以通过在主库查询 pg_stat_replication 视图来获取当前复制模式的信息，记住是只能在主库查询到相关信息，在备库是查询不到的，如下所示：

主库执行登录：

gsql -r -d postgres -p 15400

登录后查询：

select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

#例如返回如下信息：

      pid       |   state   |   client_addr   | sync_priority | sync_state
-----------------+-----------+-----------------+---------------+------------
140366556301056 | Streaming | 192.x.x.122 |             0 | Quorum
(1 row)

备库节点上执行登录：

gsql -r -d postgres -p 15400

登录后查询：

select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

#例如返回如下信息：

pid | state | client_addr | sync_priority | sync_state
-----+-------+-------------+---------------+------------
(0 rows)

使用OM部署的主备环境默认采用Quorum这种复制模式。

2.2 Quorum和Async差异

Quorum和Async是用于实现数据复制和高可用性的两种不同策略，它们在数据一致性、可用性和性能方面有所不同。

两者的差异主要体现在如下方面：

同步复制 (Quorum)

⭐Quorum 同步复制要求主服务器在提交事务之前，必须等待至少一定数量的备份服务器确认已成功写入相同的数据。
⭐这种方式确保了较高的数据一致性，因为事务只有在多个服务器都写入成功后才会提交。
⭐如果其中一个备份服务器发生故障，主服务器可能会等待其他备份服务器的确认，从而导致一些性能损失。
⭐由于需要等待确认，因此 Quorum 同步复制可能会对性能产生一定的影响，尤其是在网络延迟较大的情况下。

异步复制 (Async)：

⭐异步复制允许主服务器提交事务后立即继续处理下一个事务，而不需要等待备份服务器的确认。
⭐这种方式可以提供较高的性能，因为主服务器不会被阻塞等待备份服务器的响应。
⭐异步复制适用于那些对性能要求较高，但对数据一致性要求相对较低的场景。

总结：

Quorum 同步复制在数据一致性方面提供更高的保证，但可能会对性能产生影响。Async异步复制提供了更好的性能，但在某些情况下可能会导致数据丢失。

另外还需要注意的是，要实现 Quorum 同步复制，在PostGreSQL数据库中通常需要配置复制槽、设置同步级别等才够满足要求。

2.3 复制模式切换

2.3.1 查询复制模式

在GBase 8c数据库中，复制模式sync_state值是受到synchronous_standby_names参数配置的影响，使用OM方式部署的主备环境，synchronous_standby_names 默认是为ANY，可以通过如下两种方式查询当前数据库环境synchronous_standby_names 的值。

1）方式一

查看 postgresql.conf 配置文件

[gbase@gbase8c-primary ~]$ cat /dbdata/gbase/database/data/dn1_1/postgresql.conf | grep -i synchronous_standby_names
synchronous_standby_names = 'ANY 1(dn_6002)'  # standby servers that provide sync rep

2）方式二

主库数据库查询，备库是查询不到信息

[gbase@gbase8c-primary ~]$ gsql -r -d postgres -p 15400
……
SELECT current_setting('synchronous_standby_names') AS synchronous_standby_names;
synchronous_standby_names
---------------------------
      ANY 1(dn_6002)
(1 row)

synchronous_standby_names 值设置为 ‘ANY 1(dn_6002)’ ，any 意味着是潜在备库，保证后面有 Any N 个是同步模式，按照当前部署的一主一备这套主备环境，any 1 且只有一个备机，表示就是同步备。若通过OM安装生成，默认会设置 n / 2 个实例作为同步备。

2.3.1 切换复制模式

可以通过gs_guc命令进行复制模式的切换，gs_guc命令要在主库进行，无需重启主备数据库，若在备库执行，执行不会报错，但不会生效。synchronous_standby_names 设置为空，即将复制模式从Quorum 切换至Async模式。

gs_guc设置的命令为：gs_guc reload -D <datanode_dir> -c “synchronous_standby_names=' ' ”

在本文示例中，具体命令为：

[gbase@gbase8c-primary ~]$ gs_guc reload -D /dbdata/gbase/database/data/dn1_1 -c “synchronous_standby_names=''”

返回如下信息：

The gs_guc run with the following arguments: [gs_guc -D /dbdata/gbase/database/data/dn1_1 -c synchronous_standby_names='' reload ].
expected instance path: [/dbdata/gbase/database/data/dn1_1/postgresql.conf]
gs_guc reload: synchronous_standby_names='': [/dbdata/gbase/database/data/dn1_1/postgresql.conf]
server signaled
Total instances: 1. Failed instances: 0.
Success to perform gs_guc!

检查是否成功

SELECT current_setting('synchronous_standby_names') AS synchronous_standby_names;

synchronous_standby_names
---------------------------
(1 row)


select pid,state,client_addr,sync_priority,sync_state from pg_stat_replication;

      pid       |   state   |   client_addr   | sync_priority | sync_state
-----------------+-----------+-----------------+---------------+------------
140366556301056 | Streaming | 192.x.x.122 |             0 | Async
(1 row)

可以查看到sync_state 复制模式状态已经从Quorum 切换到了Async，同时synchronous_standby_names 已经为空值了，说明切换成功。

三、恢复模式

pg_is_in_recovery是一个内置函数，用来判断当前数据库实例是否处于恢复模式。

恢复模式是指数据库正在应用 WAL（Write-Ahead Log）日志以将备份的数据与主数据库同步。这通常发生在实施数据库恢复、故障切换或主备切换的过程中。在恢复模式下，数据库实例不能执行写操作，只能执行只读操作。

pg_is_in_recovery()函数返回一个布尔值，如果返回 true，则表示数据库当前处于恢复模式；如果返回 false，则表示数据库处于正常运行模式。

原文链接：www.gbase.cn/community/p…
更多精彩内容尽在南大通用GBase技术社区，南大通用致力于成为用户最信赖的数据库产品供应商。