Teledbx数据库结构说明

Teledbx分布式数据库由GTM/CN/DN三类节点构成

• GTM: 全局事务管理器，用于保证全局事务一致性，通过GTS全局时间戳维护全局事务。
• CN: 协调节点，用于生成执行计划转发业务请求，并维护数据库统计信息。
• DN: 数据节点，保存业务数据。
  

产品备份总体流程

Center用于总体把控分布式数据库所有节点备份状态，Agent用于单个节点的备份任务处理，Storage用于存储备份数据。总体的备份逻辑如下步骤：

1. Center开启备份，收集分布式数据库各个节点的信息，并将任务下发给节点绑定的Agent上。
2. 各个Agent处理节点的全量物理备份任务，详细步骤参考图2
3. Agent处理完成备份任务后，将任务状态上报给Center，并将备份数据上传到备份村粗Storage中。
4. Center收集所有节点的备份状态信息，并记录整个数据库集群的备份状态。

需要注意的是，整体备份流程需要以下异常处理机制：

1. Center在备份过程中异常重启后，需要感知分布式数据库上次未完成的备份任务，重新接管整体的备份任务状态。
2. Agenet在备份过程中异常重启后，需要重新感知所绑定节点的备份状态，如果处于可继续执行的步骤，应尝试继续执行，否则需要及时通知Center上报任务状态，防止center无法及时感知，导致集群备份状态异常。

节点备份流程

1. 备份开始前需要进行一些预检测，包括以下内容

(1) 需要备份的节点状态，节点需要处于运行中

(2) 备份存储的状态，比如对象存储的状态，备份机的网络连接状态等

(3) 备份目录的状态，检测备份目录是否可用

2. 保证节点wal日志归档命令正常，否则无法正常完成备份
3. 执行pg_start_backup, pg_start_backup在集簇目录中创建一个关于备份信息的 备份标签文件，也被称为backup_label， 其中包括了开始时间和标签字符串
4. 使用文件系统备份工具执行备份，例如tar 或cpio，需要注意的是如果被拷贝的文件在拷贝过程中发生变化，某些文件系统备份工具会发出警告或错误。在建立一个活动数据库的基础备份时，这种情况是正常的，并非一个错误。
5. 执行pg_stop_backup，这个函数将终止备份模式，并且执行一个自动切换到下一个WAL段。
6. 等待wal日志备份同步。具体步骤详见图3。对于单机数据库来说，通常到第5步时备份就可以结束了，但是对于分布式数据库来说，单个节点的备份结束并不能保证整个集群的备份可以正常用于恢复，因为通常来说，每个节点由于数据量的差别，并不能保证在停止备份的时候的数据是一致的，因此我们在分布式数据库备份场景下，增加了等待wal日志同步的步骤，保证在备份结束后，整个集群能使用该次备份进行全量恢复。
7. 上传备份文件。所有节点等待wal日志备份达到一致后，agent便可将节点的全量备份上传到指定的备份存储上。
8. 通知Center节点备份状态。

等待wal日志同步流程

对于单机数据库来说，通常到第5步时备份就可以结束了，但是对于分布式数据库来说，单个节点的备份结束并不能保证整个集群的备份可以正常用于恢复，因为通常来说，每个节点由于数据量的差别，并不能保证在停止备份的时候的数据是一致的，因此我们在分布式数据库备份场景下，增加了等待wal日志同步的步骤，保证在备份结束后，整个集群能使用该次备份进行全量恢复。

节点间的交互预通信借助了ETCD来完成。

1. 由于CN/DN的基础备份存在一个最小的的wal（后续使用stop_wal表示）日志位置，该内容记录在每次备份产生的backup文件中，因此需要持续监控CN/DN的stop_wal是否被上传，并在ETCD记录CN/DN节点的stop_wal对应的GTS。
2. 由于整个实例的一致性是通过GTM中的GTS维护保证的，因此需要保证GTM备份结束的GTS需要大于DN/CN节点的stop_wal对应的GTS，才能保证该次备份的GTS能够正常恢复DN/CN。GTM需要持续监听ETCD，保证所有CN/DN节点wal日志归档达到了stop_wal的位置，且GTM当前的归档GTS需要大于所有CD/DN节点stop_wal对应的GTS。如果GTM满足上述要求，则表示GTM的wal日志已经达到了可恢复的最低要求，此时向ETCD上记录GTM此时wal日志的的GTS（以下使用recovery_gts表示），随后GTM节点可完成备份，将带有wal日志的基础备份上传到备份存储空间中。
3. 对于CN/DN节点，可以通过配置恢复到指定GTS，对于全量备份而言，即可以恢复到第二步说明的recovery_gts。因此CN、DN节点在等待wal日志同步期间，不仅要持续向ECTD中记录自身归档的wal日志信息，同时也需要检测GTM是否在ETCD上记录了此次备份的recveroy_gts，如果监测到存在，则CN/DN只需要等到wal日志达到此GTS便可结束备份，并将基础备份和等待wal日志期间的wal日志文件一起上传到备份存储空间中。

上述的步骤是等待wal日志备份同步期间的逻辑流程，但是实际操作中需要考虑到以下多种场景进行快速失败，防止节点备份一直处于等待状态：

1. GTM/CN/DN节点归档命令由于某种原因一直失败，这样无法产生新的wal日志，这样就无法更新ETCD上的wal日志备份信息，从而导致备份一直无法结束。
2. ETCD异常，导致节点wal日志信息无法正常上报时。
3. 集群中某个节点已经备份失败时，其他节点需要感知到并快速失败，防止无意义的等待。