openGauss主备流程与参数的详细介绍

一、openGauss主备

介绍openGauss的主备架构、如何修改事务提交方式（同步、异步）、解释了主备日志复制的相关GUC参数、以及对openGauss3.0新添加的CM工具进行了介绍。

注意点：

opengauss 是支持单机和一主多备部署方式。(不支持集群）
gaussdb支持集群。是分布式数据库。

1. 主备架构

openGauss的主备HA架构图如下。

ParallelRecov：支持备机并行日志恢复

两地三中心的部署架构，如下图。

2. 术语解释

官方文档：https://opengauss.org/zh/docs/3.0.0/docs/Glossary/Glossary.html

AZ：Available Zone，通常指一个机房。
HA：高可用性（HighAvailability），通过尽量缩短因日常维护操作（计划）和突发的系统崩溃（非计划）所导致的停机时间，以提高系统和应用的可用性。

CM： Cluster Manager，数据库管理模块。管理和监控系统中各个功能单元和物理资源的运行情况，确保整个系统的稳定运行。
OM: Operations Management，运维管理模块。提供数据库日常运维、配置管理的管理接口、工具。
core文件： 当程序出现内存越界、断言失败或者访问非法内存时，操作系统会中止进程，并将当前内存状态导出到core文件中，以便进一步分析。（欧拉22.03自带的数据库，进行多节点部署的时候就遇到过，只支持集群部署）
core文件包含内存转储，支持全二进制和指定端口格式。core文件名称由字符串core以及操作系统进程ID组成。
core文件不依赖于任何平台。

检查点：将数据库内存中某一时刻的数据存到磁盘的机制。openGauss定期将已提交的事务数据和未提交的事务数据存到磁盘，这些数据用来和Redo日志一起在数据库重启和崩溃时恢复数据库。
节点： 将构成openGauss数据库环境的各台服务器（物理机或虚拟机）称为数据库节点，简称节点。
基于时间点恢复: PITR（Point-In-TIme Recovery），基于时间点恢复是openGauss备份恢复的一个特性，是指在备份数据和WAL日志正常的情况下，数据可以恢复到指定时间点。

逻辑复制: 数据库主备或两个数据库间的数据同步方式。区别于通过物理日志回放方式的物理复制，逻辑复制在两个数据库间传输逻辑日志或通过逻辑日志对应的SQL语句实现数据同步。
逻辑日志::数据库修改的日志记录，可直接对应为SQL语句，一般为行级记录。区别于物理日志，物理日志是记录物理页面修改的日志。
逻辑解码: 逻辑解码是一种通过对xlog日志的反解实现将数据库表的所有持久更改抽取到一种清晰、易于理解的格式的处理过程。
逻辑复制槽: 在逻辑复制的环境下，逻辑复制槽用以防止Xlog被系统或Vaccum回收。openGauss中用于记录逻辑解码位置的对象，提供创建、删除、读取、推进等多个SQL接口函数。
逻辑节点: 一个物理节点上可以安装多个逻辑节点。一个逻辑节点是一个数据库实例。

强一致性: 任何查询不会瞬时的看到一个事务的中间状态。
全量同步: openGauss双机方案中的一种数据同步机制，是指把主机中的所有数据同步给备机。
增量备份： 基于上次有效备份之后对文件修改的备份。
增量同步： openGauss双机方案中的一种数据同步机制，是指把主机中数据增量同步给备机，即只同步主备间有差异的数据。
数据库实例: 一个数据库实例是一个openGauss进程以及它控制的数据库文件。openGauss在一个物理节点上安装多个数据库实例。一个数据库实例也被称为一个逻辑节点。

数据库双机： openGauss提供的高可靠性双机方案。在此方案中，每个openGauss逻辑节点标识为主机或备机。在同一时间内，只有一个openGauss被标识为主机。双机初次建立时，主机会对每个备机数据做全量同步，然后做增量同步。双机建立之后的运行过程中，主机能接受数据读和写的操作请求，备机只做日志同步。
主机： openGauss数据库双机系统中接受数据读写操作的节点，和所有备机一起协同工作。在同一时间内，双机系统中只有一个节点被标识为主机。

物理节点： 一个物理机器称为一个物理节点。
系统表： 存储数据库元信息的表，元信息包括数据库中的用户表、索引、列、函数和数据类型等。
脏页面： 已经被修改且未写入持久性设备的页面。
最小恢复点：最小恢复点是openGauss提供的数据一致性保障手段之一。最小恢复点特性可以在openGauss启动时检查出WAL日志和持久化到磁盘的数据的不一致性，并提示用户进行处理。

Failover：指当某个节点出现故障时，自动切换到备节点上的过程。反之，从备节点上切换回来的过程称为Failback。
REDO日志: 记录对数据库进行操作的日志，这些日志包含重新执行这些操作所需要的信息。当数据库故障时，可以利用REDO日志将数据库恢复到故障前的状态。
Postmaster：数据库服务启动时启动的一个线程。用于侦听来自数据库其它节点或客户端的连接请求。主机上侦听到备机连接请求，并接受后，就会创建一个WAL Sender线程，用于处理与备机的交互。

WAL：Write-Ahead Logging，也称为 XLog，预写日志系统。实现事务日志的标准方法，是指对数据文件（表和索引的载体）持久化修改之前必须先持久化相应的日志。

WAL Receiver：数据库复制时备机创建的一个线程的名称。此线程用于从主机接收数据、命令，并反馈确认信息至主机。一个备机只有一个WALReceiver线程。

WAL Sender：数据库复制过程中，主机接受到备机的连接请求后创建的一个线程的名称。此线程用于发送命令、数据到备机，并从备机接收信息。一个主机可能会有多个WAL Sender线程，每一个WAL Sender线程对应一个备机的一个连接请求。
WAL Writer： 数据库启动时创建的一个写Redo日志的线程，用于将内存中的日志写入到持久性设备（如：磁盘）。
Xlog： 表示事务日志，一个逻辑节点中只有一个，不允许创建多个Xlog文件。

核心流程：

目前一主多备方式架构，主机通过walsender线程向备机同步日志，备机通过walreceiver线程接受日志，并刷到本地盘，备机读取redo日志，完成主备之间的数据同步。主备机之间walsender与walreceiver一一对应。

3. 事务提交方式(主备日志同步方式)

通常情况下，一个事务产生的日志的同步顺序如下：

1. 主机将日志内容写入本地内存。
2. 主机将本地内存中的日志写入本地文件系统。
3. 主机将本地文件系统中的日志内容刷盘。
4. 主机将日志内容发送给备机。
5. 备机接受到日志内容，存入备机内存。
6. 备机将备机内存中的日志写入备机文件系统。
7. 备机将备机文件系统中的日志内容刷盘。
8. 备机回放日志，完成对数据文件的增量更新。

事务提交方式由参数synchronous_commit决定，共有6种提交方式，如下：

- on：表示主机事务提交需要等待备机将对应日志刷新到磁盘。
- off：表示主机事务提交无需等待主机自身将对应日志刷新到磁盘，通常也称为异步提交。
- local：表示主机事务提交需要等待主机自身将对应日志刷新到磁盘，通常也称为本地提交。
- remote_write：表示主机事务提交需要等待备机将对应日志写到文件系统（无需刷新到磁盘）
- remote_receive：表示主机事务提交需要等待备机接收到对应日志数据（无需写入文件系统）
- remote_apply：表示主机事务提交需要等待备机完成对应日志的回放操作。
默认值：on

上述6种提交方式中，off和local属于非同步提交，其他均为同步提交。

下面给出on和local两种方式的事务提交时序图。
1、synchronous_commit = on（默认值）

该方式有性能损耗，可靠性高。
2、synchronous_commit = local

该方式性能高，可靠性差。

4. 主备日志复制的相关GUC参数

GUC: Grand Unified Configuration，数据库运行参数。配置这些参数可以影响数据库系统的行为。
更多GUC参数可查看：GUC参数说明
修改GUC参数的方法：