达梦数据库系列—22. DPC集群原理

DPC原理

1、系统原理

2、元数据服务

3、数据存储

4、执行计划的生成

5、计算与存储分离

6、动态增删节点

7、分布式事务一致性

第一阶段预提交

第二阶段提交

8、RAFT 归档

9、自动故障处理

DPC原理

计划生成节点（SP）：对外响应数据库请求，生成并调度计划。

数据存储节点（BP）：存储实际的数据，接收并执行发来的子计划。

元数据节点（MP）：提供元数据服务。

1、系统原理

RAFT组

bp11 bp12 bp13 raft1 tbs1

bp21 bp22 bp23 raft2 tbs2

1.每个表空间只能指定一个raft组，创建的时候指定。

例：CREATE TABLESPACE TS_1 DATAFILE 'TS_1.DBF' SIZE 128 STORAGE( ON RAFT_1);

创建好后的raft组节点可以更改吗？

可以通过增加删除的方式更改，但要注意数据的手动迁移：

增加：

SP_CREATE_DPC_INSTANCE('RAFT_1', 'BP11', 'BP', 6002, 5238, '192.168.64.133', '192.168.64.133','STANDBY', 0, 'BP instance');

删除：

SP_DROP_DPC_INSTANCE('BP_1');

表空间可以整体从raft1迁移到raft2吗？

是可以的：alter tablespace ts_01 move to raft_2;

2.创建表，以及每个分区，可以STORAGE语句指定不同的表空间

表的迁移？

表有很多个分区，每个分区在一个表空间上

那么表的某个分区可以从一个表空间（raft1）迁移到另一个表空间(raft2)上吗？

可以的：alter table test22 move partition PAR5 to TS_1;

整个表的迁移，需要一个一个分区进行迁移。

查询

客户端发送请求给 SP；
SP 生成执行计划，同时 SP 向 MP 申请获取字典信息；
MP 返回字典信息给 SP；
SP 将生成的执行计划中的一个或多个子计划发送给此次查询相关的 BP；
相关 BP 接收并执行子计划。根据实际需要，不同 BP 间、同一 BP 不同线程间可能存在数据交换；
相关 BP 在子计划执行完成时将成功与否信息和/或请求调度信息返回 SP；
SP 向客户端返回最终查询结果。

插入/更新

SP 端的插入操作符计算出待插入数据所属的 BP 站点，然后以站点为单位逐一发送插入操作符和待插入/更新数据给 BP。BP 端负责插入/更新。

2、元数据服务

在 DMDPC 中，为了简化 DDL 的处理，使用专门的元数据服务器 MP 负责管理所有的字典对象元数据信息。所有 SP 和 BP 都是通过网络请求从 MP 获取字典对象的。

SP 获取字典对象的步骤如下：

SP 在自己的字典缓存中查找是否有该对象的缓存，如果有则直接使用该对象，否则执行步骤 2；
SP 向 MP 发出请求，获取某个特定 ID 的字典对象；
MP 接收请求后从系统表中加载对应的字典对象，然后返回 SP；
SP 解包 MP 返回的字典对象并添加到自己的缓存中。

3、数据存储

DMDPC 的数据存储在各个 BP 中。

表空间的元数据信息由 MP 进行管理。所有本地表空间元信息都记录在 MP 的控制文件中。

4、执行计划的生成

DMDPC 的执行计划是在单机数据库执行计划的基础上插入了数据交换操作符 ESEND/ERECV 后形成的。数据交换操作符的插入只发生在特定的操作符中。例如：连接、分组、排序等。

5、计算与存储分离

将数据获取相关的子计划放在 BP 上，中间层计算相关的子任务放在一个或多个 SP 上执行。当连接和分组、去重等操作需要用到多个计算节点时，优化器会从 DMDPC 集群选择多个 SP 节点。

XMAL 系统

XMAL 系统是基于 TCP/IP 协议实现的一种内部通信机制，具有可靠、灵活、高效的特性。XMAL 专门用于 DMDPC 分布式架构中。DM 通过 XMAL 系统实现 REDO 日志传输，以及其他一些实例间的消息通信。

DMDPC 使用 XMAL 系统管理各部件节点网络信息，建立节点间的通信机制。用户只需要将 SP 和 BP 节点的 IP 地址和端口等信息注册到 MP 上即可，使得增删节点的部署能够做到快速且便捷。

6、动态增删节点

横向增删：

支持删除 SP 组、BP 组、RAFT 组、BP 节点或 SP 节点：

只有正常退出的 SP 节点才能删除；
没有数据的 RAFT 组内节点才能删除。如果想删除包含数据的 BP 节点，必须先将此节点上的数据迁移到其他分区，具体见“数据迁移”；
删除 RAFT 组必须先删除组内包含的所有节点；

纵向增删：

7、分布式事务一致性

DMDPC 通过两阶段提交技术来保证多个 BP 之间的分布式事务一致性。

SP 作为全局事务的协调者，统一处理全局事务。BP 作为参与者，是被 SP 调度并执行事务的节点。

第一阶段预提交

客户端向 SP 发起事务提交请求。
SP 向所有参与者 BP 广播预提交命令。询问是否可以进行事务 COMMIT，并等待 BP 的响应。
BP 接收到预提交命令之后，将相关操作生成回滚日志写入回滚段并响应 SP。
如果 SP 收到所有参与者 BP 的预提交成功的消息，则进入第二阶段进行提交。否则，当存在 BP 没有响应导致 SP 无法确定该 BP 是否执行了预提交时，SP 先尝试通知存活 BP 执行回滚。若有 BP 回滚成功，SP 就可以直接响应“事务提交失败”给客户端；

第二阶段提交

SP 向所有参与者 BP 广播 COMMIT 命令。
BP 接收到提交命令之后，执行二阶段的提交任务，释放事务资源，并将 COMMIT 成功结果反馈给 SP。
SP 收到所有参与者 BP 的 COMMIT 成功消息之后，直接响应客户端事务提交成功。二阶段提交时若遇到 BP 与 SP 通信中断，SP 会将提交任务交由异步任务进行处理并立即响应客户端事务提交成功。

全局时钟（GTS）值由 MP 节点统一管理。BP 节点执行事务内的每条语句、执行预提交、提交操作时均会向 MP 申请当前的全局时钟值。

事务对数据进行操作时，BP 都会向 MP 申请当前的全局时钟值 cur_seq。只要是当前事务操作时钟值 cur_seq 之前的已提交事务修改的数据，对当前事务都是可见的。

当事务对数据进行修改时，日志记录中会登记修改该数据的事务号 TID。
当事务执行一阶段预提交时，CA 中会登记 TID、预提交状态和预提交时的时钟值。
当事务二阶段提交时，MCA 会登记 TID 和提交时的时钟值，CA 会将第 2 步中登记的信息更新为最终的提交状态和提交时的时钟值。

8、RAFT 归档

多副本系统中的主库通过 RAFT 归档方式向备库同步数据。RAFT 归档将主库产生的 Redo 日志通过 XMAL 模块传递到备库。

RAFT 归档的执行流程是主库在 Redo 日志（RLOG_PKG）写入联机日志文件前，将 Redo 日志发送到备库，并且不需要等待备库的响应消息，主库继续往下正常执行。备库收到 Redo 日志（RLOG_PKG）后，将日志包加入日志重演任务系统，在日志包写入本地日志文件后，发送日志刷盘消息给主库，主库根据此消息确定是否需要推进 C_SEQNO 和 C_LSN。

C_SEQNO 是已经提交的日志包序号，C_LSN 是已经提交的 C_SEQNO 日志包中的最大 LSN。