活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

# GBase 8s高可用类型简介

## SSC共享存储集群

SSC主备节点状态一致性通过LSN同步+逻辑日志重放实现。SSC主节点接收业务请求，写逻辑日志，并将逻辑日志中与操作一一对应的LSN号发给各个备节点，从主节点接收到LSN号，从磁盘读取相应逻辑日志到缓冲区进行重放，从而达到主备节点数据状态一致。

## HAC主备集群

HAC集群是基于数据库逻辑日志复制技术，实现主、备数据库复制，复制方式支持同步和异步两种模式。根据灾备距离支持同城和异地灾备技术，异地灾备支持多节点。

- 同步模式：该模式下备实例上的事务始终和主实例保持一致。适用于主备节点距离较近（同机房或跨机房）的同城容灾。
- 异步模式：该模式下，主实例在将逻辑日志刷新到磁盘之前不需要收到备实例的确认信息，可以提高日志的复制速度。适用于异地灾备。

## ER集群

GBase 8s Enterprise Replication（ER）是基于日志的异步工具，用于在 GBase 8s Server数据库服务器之间复制数据。源服务器节点上通过读取逻辑日志，存储事务并将每个事务作为复制数据可靠传输至目标服务器。在每一目标服务器节点接收复制数据，并将其中包含的每一事务应用到适当的数据库和表。

## 集群区别

ER集群与其他SSC/HAC等集群区别就是：ER的同步粒度是表级和列级，而其他集群的同步粒度是实例级。

原理上的差距如下图所示：

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/ryk1sZxCXEsob9XRZIae_/image.png)

- SSC集群：共用同一份存储，节点间仅同步LSN号
- HAC集群：双节点同步完整的逻辑日志
- ER集群：根据特定的复制规则，仅同步指定表或者列的事务数据

# ER复制原理

## 复制过程

复制过程分为三个阶段，如下图所示：
![image.png](https://g1.cdn.gbase.cn/CommunityUploads/3jO76w_0dMd2hWYq74lvJ/image.png)

- 数据捕获阶段：
  
  1. 客户端应用程序定义复制的数据库中执行事务
  2. 该事务被写入逻辑日志
  3. 日志捕捉组件读取逻辑日志并将逻辑日志记录传递到分组组件
  4. 分组组件计算需要复制的逻辑日志，并将他们分组到描述原始事务的操作的消息中
  5. 分组组件将消息添加到发送队列。在特定情况下，发送队列将消息临时存储到磁盘上。发送队列是一种内存的状态，当内存放满的时候，他会spool到磁盘上进行存储，后续再从磁盘上进行读取，向目标服务器进行同步
- 数据传输阶段：
  
  6. 发送队列通过ER网络将复制消息传输到目标服务器
- 应用的数据：
  
  7. 复制消息被添加到目标服务器的接收队列中
  8. 数据同步组件将该事务应用到目标数据库。在回放过程中如果有必要的话，数据同步组件还会执行冲突解决
  9. 在确认队列中放置一条表示消息已经成功应用的消息
  10. 将确认消息发送回源服务器

## 复制流程图及相关命令

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/NwyrkKW7ggQe_4238niw1/image.png)

- ddr_snoopy线程：进行数据挖掘，可以通过onstat -g ddr命令查看当前挖掘的LSN号和哪个事务，和回放的逻辑日志位置等
- 分组组件：涉及到CDRGfan线程，CDRGeval线程等，可以通过onstat -g grp命令查看分组器的状态
- 数据传输阶段：可以通过onstat -g rqm命令，查看发送队列和接收队列的偏差，了解当前的同步进程
- 回放过程：通过CDRD_n线程进行回放，onstat -g ddr可以查看当前回放的过程
- onstat -g cat可以打印ER全局目录信息，比如当前配置了多少个服务器、多少个复制规则、当前的服务器属于根服务器还是叶子服务器等

## 核心线程

onstat -g ath可显示所有线程。

| 线程数 | 线程名 | 线程描述 |
| --- | --- | --- |
| 1 | ddr_snoopy | 执行逻辑日志的物理I/O，验证可能的复制，并将适用的日志记录项发送到Enterprise Replication。|
| 1 | preDDR | 在队列恢复期间运行以监视日志并设置阻止方式(如果在复制恢复之前日志前进太远)。 |
| 1 | CDRGfan | 接收日志项并将这些项传递给评估程序线程。 |
| n | CDRGevaln | 评价日志条目以确定是否应该进行复制。n是CDR_EVALTHREADS配置参数指定评估程序线程数。此线程还会压缩已提交的事务并对完成的复制消息进行排队。 | 
| 每个大事务1个 | CDRPager | 对保存已分页的事务记录的临时智能大对象执行物理I/O。当一个事务大小是SHMVIRTSIZE或CDR_QUEUEMEM配置参数的10%时，或事务包含100,000条以上记录时，对该事物激活分组器页面调度。 | 
| 1 | CDRCparse | 解析复制定义的所有SQL语句。 |
| 每个连接1个 | CDRNsTnCDRNsAn | 站点的发送线程。 |
| 每个连接1个 | CDRNrn | 站点的接收线程。 |
| 2...n | CDRACK_n | 从站点接收应答。至少2个，至多为活动连接的最大数目。 | 
| # CPUs... | CDRD_n | 在目标系统上重放事务(数据同步线程)。最大线程数为4*(CPUVP数) |
| 1 | CDRSchedMgr | 调度内部的Enterprise Replication事件。 |
| 0或1 | CDRM_Monitor | 监视和调整数据同步性能以获得最佳性能(在目标上)。 | 
| 0或1 | CDRDTCleaner | 从删除的行影子表中删除(清除)行(当不再需要它们时) |

## 行映像压缩示例

上边提到CDRGeval线程可以进行行映像的压缩，以下是几种示例场景。

1. Replicate SQL=SELECT emp_id,salary FROM employee WHERE exempt = "N";

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/wjWkMDI9kZF1QozzRdd9_/image.png)

定义复制规则是只同步关于employee表的emp_id和salary字段，关于exempt字段为N的数据，从图中可以看到，首先插入了一条id是927的数据，后续操作又进行了删除，对于该示例的事务中，对两条执行语句进行合并压缩，最后没有复制数据需要发送到目标服务器。

2. Replicate SQL=SELECT emp_id,salary FROM employee WHERE exempt = "N";

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/7GGKWxAGvBe0559c8S2pF/image.png)

同示例1相同的复制规则，另一种事务场景，可知先插入了一条数据，然后更新了这条数据，该示例的事务中，对于两条执行语句进行合并压缩，最后仅需要将一条插入语句，复制数据发送到目标服务器。

3. Replicate SQL=SELECT emp_id,salary FROM employee WHERE exempt = "N";

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/IjjkkFQEKP2RxcYzQZLrb/image.png)

复制规则不变，如图所示，更新了一条数据，使数据和我们的复制规则产生了关系，对于我们目标服务器上是没有该条数据的，所以该事务中，转换为插入语句，复制数据需要发送到目标服务器。

# 数据复制方式

## Primary-Target

一对多：

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/Vk3Ud4LAgA-KXgApyEo0L/image.png)

多对一：

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/ZSelCuP29AT7HfgLLlPq_/image.png)

**示例1：**

将三个节点创建到一个复制域中 进行配置1节点为主节点、 2、 3节点为从节点

```
cdr define server -s erspace -A /data/chunk/cdrcheck -I group1 -s space --send=space

cdr define server -c group2 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group2

cdr define server -c group3 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group3
```

在三个节点中为同一张表创建两个复制规则，支持现场2、3节点不同步

```
cdr define replicate -C ignore -S trans -i -A -R repl_1 "P db_er@group1:gbasedbt.tab_1" "select * from tab_1" "R db_er@group2:gbasedbt.tab_1" "select * from tab_1"

cdr define replicate -C ignore -S trans -i -A -R repl_2 "P db_er@group1:gbasedbt.tab_1" "select * from tab_1" "R db_er@group3:gbasedbt.tab_1" "select * from tab_1"
```

两个复制规则可分别启动，可以查看cdr list repl rep_1中的REPLMODE字段验证。

- 1 节点对于复制规则是PRIMARY角色
- 2 3节点对于相关复制规则是READ-ONLY角色
- 对另外未包含规则是OTHER角色

此时1节点执行插入语句可以实现1->2和1->3的节点同步

**示例2：**

将三个节点创建到一个复制域中 进行配置1节点为主节点、 2、 3节点为从节点

```
cdr define server -s erspace -A /data/chunk/cdrcheck -I group1 -s space --send=space

cdr define server -c group2 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group2

cdr define server -c group3 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group3
```

也可以在三节点中为同一张表创建同一个复制规则

```
cdr define replicate -C ignore -S trans -i -A -R repl_1 "P db_er@group1:gbasedbt.tab_1" "select * from tab_1" "R db_er@group2:gbasedbt.tab_1" "select * from tab_1" "R
db_er@group3:gbasedbt.tab_1" "select * from tab_1"
```

可以查看cdr list repl rep_1中的REPLMODE字段验证。

- 1 节点对于复制规则是PRIMARY角色
- 2 3节点对于该复制规则是READ-ONLY角色

当前复制规则保证2、3节点与1节点数据同步。实现1->2 与3节点同步

## Update-Anywhere

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/XdokbBnhTsfi1nUEIg30e/image.png)

**示例：**

将三个节点创建到一个复制域中 进行配置1、 2、 3节点为全对等节点

```
cdr define server -s erspace -A /data/chunk/cdrcheck -I group1 -s space --send=space

cdr define server -c group2 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group2

cdr define server -c group3 -A /data/chunk/cdrcheck -R /data/chunk/cdrcheck -I -S group1 group3
```

在三个节点中为同一张表创建一个双向同步复制规则

```
cdr define replicate -C ignore -S trans -i -A -R repl_1 " db_er@group1:gbasedbt.tab_1" "select * from tab_1" " db_er@group2:gbasedbt.tab_1" "select * from tab_1" "
db_er@group3:gbasedbt.tab_1" "select * from tab_1"
```

当前复制规则保证1、2、3数据全同步，可以查看cdr list repl rep_1中的REPLMODE字段验证。

- 1 2 3节点对于该复制规则全部是PRIMARY角色

## 拓扑

基于以上复制方式，我们可以组成不同的拓扑结构。

- 完全连接拓扑

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/7zVQKyqa4gayQC-fkqSBc/image.png)

完全连接的复制拓扑指所有数据库服务器彼此连接，且 Enterprise Replication建立并管理这些连接。将复制消息直接从一数据库服务器发送至另一个。无需附加的路径来传送复制消息。在复制环境中，每一数据库服务器直接连接至每一其他数据库服务器。

- 分层级的路径拓扑

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/8AueJJUuhlvP0esfApD-u/image.png)

分层级的树由组织成树型拓扑的根服务器及一个或多个数据库服务器组成。

树仅包含一个没有父的根。树中的每一数据库服务器都引用其父。不是父的数据库服务器是叶子。

- 树木的森林型拓扑

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/ji9vJvA7j1fJMD6UPiUGG/image.png)

树木的森林由完全地连接其根数据库服务器的几个分层级的树组成。每一分层级的树始于根数据库服务器。为了交付至其子数据库服务器，根数据库服务器将复制消息转移至其他根服务器。

# 现场案例分析

## 测试描述

- 测试项目：单向同步压测
- 测试目的：验证数据库单向同步压测性能指标
- 预置条件：
  - 数据库服务运行正常
  - 磁盘空间充足
  - 单向同步搭建完成
  - 3张业务表创建完成
- 测试步骤：使用jmeter分别对3张业务表进行写入压测，时间为1小时，查看最高tps与同步所需要的时间

## 现场问题与定位

实际测试性能较差，采集现场执行过程中的内存曲线图与IO曲线图。

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/AA3ZHPZNjlYla2ewV8RO3/image.png)

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/Af9mzxL7cCn4QbBtrU4rW/image.png)

可以发现内存存在大量空闲，同时产生了大量的IO操作，分析为ER集群存在硬件资源利用不充分的问题，导致大量空闲内存没有被有效使用，产生了大量的IO操作，导致ER同步效率降低。

## 性能优化

- 优化措施

1. 核心调整： 调高ER发送队列的内存大小阈值，旨在将更多操作保留在内存中进行，充分利用服务器富裕的内存资源。
2. 优化目标： 通过此调整，显著降低操作spool（暂存）到磁盘的概率，从而减少磁盘IO，提升整体处理效率和集群同步性能。

- 初步效果与后续发现：
  
  - 调整后，spool操作的发生得到了有效抑制。但也发现一个新的现象：尽管阈值已提高，但仍有少量spool操作发生在很小的内存占用下。这提示我们，可能存在其他潜在的瓶颈或配置限制了内存的充分使用。
- 重新抓取数据后核心发现：
  
  - SPOOL机制的实际内存使用量，并非由发送队列内存大小单独决定，而是取逻辑日志大小与发送队列内存大小两者中的最小值。这是由于数据库必须优先保证数据同步的一致性，需要处理逻辑日志回绕问题。
- 洞见与修正方案：
  
  - 之前的优化思路存在盲区。单纯提高发送队列内存，在逻辑日志大小不变的情况下，无法突破性能瓶颈。
- 新的优化策略：
  
  - 必须将逻辑日志大小与发送队列内存大小作为一个整体进行协同配置。我们的新目标是：通过合理设置这两个参数，使系统在不触发SPOOL的前提下，最大化利用内存资源，从而达成集群同步性能的最优解。

# 集群方案

## SSC+ER集群方案

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/l5LPcgaqS3hL7jFQb1Xpq/image.png)

以目标端切换为例进行实验。

**测试步骤如下：**

1. 使用JDBC连接SSC集群1，并插入数据
2. 在插入过程中使SSC集群2中的主节点出现异常：杀进程
3. 当切换到SSC集群2中的备节点时，关闭JDBC业务，查看主备切换情况和数据同步情况（SSC集群1中的主备节点和SSC集群2中的备节点同步情况）
4. 查看到SSC集群2备节点升主后，同步复制全部接管，SSC1发送队列值减少，直至双方数据追平结束。

**效果：**

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/Hb_vLRM6PGcDDvR6eJUS1/image.png)


一致性能够保证：SSC的从节点切换后能接管全部复制规则继续同步。SSC升主后保证数据一致性。

ER节点均有写入功能，发生故障切换时仍可以进行写业务。

**限制：**

存在多个写节点，需要处理冲突问题。

## ER对等节点解决方案

![image.png](https://g1.cdn.gbase.cn/CommunityUploads/N93BBsBgWmdF0yfKv7uZt/image.png)

全部配置成对等节点

**效果：**

任何节点都可以宕机，不影响整个集群的使用。

可以随时加入新节点，进行业务同步。

**限制：**

不是强一致性的结果。存在业务量较大，在其他节点访问不到相关数据的情况。

# 参考视频

[【G 术时刻 14 期】GBase 8s ER 高可用介绍-P1 高可用介绍\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1sWPDzCEgE/?vd_source=601f4ee47a329751552e39cdfcfc0956)

[【G 术时刻 14 期】GBase 8s ER 高可用介绍-P2 ER 原理介绍\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV11WPDzCEcN?vd_source=601f4ee47a329751552e39cdfcfc0956&spm_id_from=333.788.videopod.sections)

[【G 术时刻 14 期】GBase 8s ER 高可用介绍-P3 数据复制方式\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1bjPDzEENo?vd_source=601f4ee47a329751552e39cdfcfc0956&spm_id_from=333.788.videopod.sections)

[【G 术时刻 14 期】GBase 8s ER 高可用介绍-P4 现场案例分析\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1bjPDzEEM8?vd_source=601f4ee47a329751552e39cdfcfc0956&spm_id_from=333.788.videopod.sections)

[【G 术时刻 14 期】GBase 8s ER 高可用介绍-P5 集群方案介绍\_哔哩哔哩\_bilibili](https://www.bilibili.com/video/BV1bjPDzEEhZ?vd_source=601f4ee47a329751552e39cdfcfc0956&spm_id_from=333.788.videopod.sections)

# 友情链接

本篇主要偏技术原理视角出发说明ER集群，偏向从业务场景出发可参考如下文章。
[GBase 8s 实时共享交换集群介绍 | GBASE 社区](https://www.gbase.cn/community/post/8111)



运维管理

GBase 8s ER集群高可用介绍

GBase 8s ER集群高可用介绍

评论

热门帖子