MPP并行数据库实例级副本均衡方法与流程

mpp并行数据库实例级副本均衡方法
技术领域
1.本发明属于数据库技术领域，尤其是一种mpp并行数据库实例级副本均衡方法。


背景技术：

2.mpp并行数据库采取无共享(share-nothing)的体系结构，是面向数据仓库以及商业智能的高性能分布式并行数据库产品。mpp并行数据库由一个管理协调节点和多个完全对称的计算存储节点构成，通过将复杂查询拆分到复数个子节点并行执行，可以快速完成数据仓库或者智能商业的统计分析查询。
3.分布式系统的故障率同节点规模成正比。为了提升数据的可靠性和系统的持续可用性，mpp并行数据库需要提供冗余容错能力，即副本技术。对副本技术的研究主要有复制方式、分布方式、服务能力几个方面。具体包括：表级副本和实例级副本、独立专用服务器和交叉共用服务器、热备模式和读写分离模式。mpp并行数据库通常采用实例级副本、交叉共用服务器和热备模式的副本技术。将存储原始数据的实例称为主实例，存储冗余副本的实例称为从实例，主从实例部署如图1所示。例如，greenplum以及神通mpp并行数据库5.0都采用了这种副本技术实现方式。
4.mpp并行数据库实例级副本的具体工作原理为：首先，按照某种策略将从实例部署到集群内对应主实例之外的服务器，最简单的策略是顺序选择下一编号的服务器。然后，主实例在完全模式下运行，可以对外提供查询计算，从实例在恢复模式下运行，接收从主实例传送来的wal日志并回放，并不对外提供服务。待主实例故障掉线后，mpp并行数据库识别并通知从实例由恢复模式转变为完全模式，并对外提供查询计算，称为从实例提升为主实例，同样，需要的时候也可以将主实例降级为从实例。
5.mpp并行数据库通常用于对大数据集合的复杂统计分析查询，具有周期性批量装载数据、一次写入多次查询的特点。另外，不同于注重高吞吐的事务型数据库系统，mpp并行数据库注重对单一任务的并行计算能力，因此，在执行任务时服务器的各类资源，包括处理器、物理内存和存储io，往往处于高负载甚至满载状态。副本技术可以提升系统的可靠性和可用性，但不可避免会因为占用系统资源而对系统的服务能力产生影响。
6.另外，主实例故障掉线后从实例提升为主实例继续提供计算。虽然此时mpp并行数据库仍可以对外继续提供服务，但因为缺少了一个节点，导致mpp并行数据库的整体服务能力下降。假设mpp并行数据库有n个节点，损失一个节点，最理想情况下整体服务能力将下降1/n。而又因为某一个节点服务器需要承受自身以及新提升主的双重负载，成为性能瓶颈节点，使得mpp并行数据库的服务能力最大可下降50％。所以，mpp并行数据库需要具有回切原主实例的能力，同时尽量减少对应用程序的影响，使系统在修复和服务之间实现均衡。


技术实现要素：

7.本发明的目的在于克服现有技术的不足，提供一种mpp并行数据库实例级副本均衡方法，实现了在不妥协从实例的冗余能力的基础上最大化主实例计算服务能力的功能。
8.本发明解决现有的技术问题是采取以下技术方案实现的：
9.一种mpp并行数据库实例级副本均衡方法，包括存储io的均衡策略、物理内存的均衡策略、计算资源的均衡策略和回切原主实例策略；
10.所述存储io的均衡策略：为每个wal日志配置单独存储硬盘，为业务数据配置一个共享的大容量存储硬盘；
11.所述物理内存的均衡策略：采用动态的数据页面缓冲区分配方式；
12.所述计算资源的均衡策略：采用自适应工作方式，将从实例增加日志回放线程池、协调管理器以及一个rto阈值，从实例在初始阶段只启动一个日志回放线程，协调管理器负责实时计算wal日志回放进展，如果回放进展超过了设定的rto阈值，将唤醒更多的线程并行回放，直至全部回放完成，再释放并保留一个回放线程继续工作；
13.所述回切原主实例策略：包括平滑模式rebalance和速度模式rebalance以满足不同的场景需求。
14.进一步，所述wal日志配置的单独存储硬盘为sas硬盘组成的raid1，所示业务数据配置的大容量存储硬盘采用多块大容量的sata硬盘组成的raid5。
15.进一步，所述动态的数据页面缓冲区分配方式为：为数据页面缓冲区设置两个容量值：初始容量、正常容量，为存放页面的缓冲块设置两个缓冲块，当数据库实例从实例启动时，按照初始容量创建哈希映射数组和第一缓冲块，此时的缓冲区大小为初始容量，当从实例被提升为主实例时增大哈希映射数组并创建第二缓冲块，缓冲区增大到正常容量，当主实例降级为从实例时缩减哈希映射数组并删除第二缓冲块。
16.进一步，所述初始容量和正常容量的比例为1:4。
17.进一步，所述从实例提升为主实例的具体实现方法为：
18.⑴
增大哈希映射数组；
19.⑵
计算正常容量和初始容量差值，申请第二缓冲块并与第一缓冲块构成缓冲块组；
20.⑶
依照动态哈希算法，将部分页面由第一缓冲块迁移至第二缓冲块；
21.⑷
页面访问自动定位到新的存放位置。
22.进一步，所述主实例降级为从实例的具体实现方法为：
23.⑴
依照动态哈希算法，将第二缓冲块中数据页面迁移至第一缓冲块；
24.⑵
如果第一缓冲块中已经没有空闲空间，将剩余数据页面回刷至数据文件；
25.⑶
缩减哈希映射数组；
26.⑷
释放第二缓冲块的内存空间；
27.⑸
页面访问自动定位到新的存放位置。
28.进一步，所述计算资源的均衡策略中，协调管理器还根据修改rto阈值的指令要求，设置并行回放的线程数量，当修改rto阈值为0时，将立即触发从实例并行回放，所述从实例并行回放的具体实现方法为：
29.⑴
接收线程将接收到的wal日志回刷至日志文件；
30.⑵
接收线程通知协调管理器日志回刷进度；
31.⑶
回放线程顺序读取wal日志进行回放；
32.⑷
回放线程通知协调管理器日志回放进度；
33.⑸
协调管理器检查发现回刷进度和回放进度偏差超过了rto阈值，启动更多的线程并行回放；
34.⑹
协调管理器检查发现已全部回放完成，释放并保留一个回放线程继续工作。
35.进一步，所述平滑模式rebalance的具体实现方法为：
36.⑴
注册rebalance事件，并启动后台任务；
37.⑵
主实例对外继续提供完整的服务；
38.⑶
后台任务监听从实例的回放进度，直至完成；
39.⑷
后台任务触发rebalance，转换主从角色，主实例降级为从实例，从实例提升为主实例；
40.⑸
新的主实例开始对外提供查询计算。
41.进一步，所述速度模式rebalance的具体实现方法为：
42.⑴
执行rebalance语句，等待结束；
43.⑵
限制mpp并行数据库对外提供更新、删除等修改服务；
44.⑶
通知从实例启动多个线程并行回放；
45.⑷
待回放完成，转换主从角色，主实例降级为从实例，从实例提升为主实例；
46.⑸
rebalance语句执行结束，新的主实例开始对外提供查询计算。
47.本发明的优点和积极效果是：
48.本发明充分考虑mpp并行数据库中并行计算、批量装载数据以及一次写入多次查询的特点，分别从存储io、物理内存、计算资源和回切原主实例这四个方面进行实例级副本的均衡，最终实现了在不妥协从实例的冗余能力的基础上最大化主实例的计算服务能力。
附图说明
49.图1是现有主从实例部署示意图；
50.图2是本发明的主从实例存储均衡方法示意图；
51.图3是现有数据库实例数据页面缓冲区示意图；
52.图4是本发明的增大数据页面缓冲区(从实例提升为主实例)；
53.图5是本发明的缩减数据页面缓冲区(主实例降级为从实例)；
54.图6是本发明的从实例并行回放示意图；
55.图7是本发明的平滑模式rebalance示意图；
56.图8是本发明的速度模式rebalance示意图。
具体实施方式
57.以下结合附图对本发明实施案例做进一步详述。
58.一种mpp并行数据库实例级副本均衡方法，包括：
59.1、存储io的均衡策略
60.mpp并行数据库对存储的指标要求非常高，通常会从存储容量、io带宽两个维度进行考虑。同一服务器上的主从实例之间会存在io访问负载均衡问题，需要研究主从实例采用独立存储或是共享整个存储。
61.mpp并行数据库为保证副本数据的一致性，在对主实例提交事务时，要求从实例上
对应的wal日志必须同步成功写入存储。当mpp并行数据库周期性批量装载数据时，同一服务器上的主从实例之间会有非常大的io写冲突，很显然，在这种情况下独立存储可以最大限度保证装载性能。但是，独立存储会带来如下两个问题：
62.(1)存储容量：mpp并行数据库在处理大数据时可能因为物理内存不足将部分中间结果临时写入外存，从实例不提供查询不需要这部分存储开销。这会导致主实例会有大于从实例的存储空间开销，甚至出现主实例存储被耗尽但从实例仍有富余的情况。
63.(2)io带宽：mpp并行数据库在执行任务时对io带宽的要求非常高，如果采用独立存储的方式，主实例只能用到全部io带宽的50％，而按照mpp并行数据库一次写入多次查询的特点此时的从实例大多处于空闲状态，无法有效利用这一部分io带宽。
64.为了均衡对存储空间和io带宽的使用效率，本发明设计了如下存储io的均衡策略，如图2所示：
65.(1)为wal日志(wal日志环形队列缓冲区)配备单独存储，因为wal日志本身存储容量不大但对写入性能和可靠性要求非常高，所以选择性能更好的sas硬盘组成raid1。
66.(2)为业务数据(数据页面缓冲区)配备一个共享的大容量存储，采用多块更大容量的sata硬盘组成raid5，在保证存储空间利用率的同时提供更大的io带宽。
67.2、物理内存的均衡策略
68.对于基于硬盘存储的传统数据库管理系统，低速的硬盘是整个数据访问路径上最大的性能瓶颈。为缓解速率不匹配带来的性能影响，在数据库内部都会实现数据页面缓冲区，其工作原理同cpu的cache，预取并缓存热数据。数据页面缓冲区由一个哈希表构成，包括负责映射的哈希映射数组和负责存放数据的缓冲块，结构示意图详见图3。工作时以页面id为索引项，通过哈希映射定位到缓冲块中对应位置，再完成实际数据的读写。mpp并行数据库面向分析统计，往往需要访问大量的数据，数据页面缓冲区带来的性能提升更为明显。
69.数据页面缓冲区通常采用静态分配方式，即数据库实例在启动阶段即分配指定大小的缓冲区，在之后的运行期间保持容量大小不变。如果mpp并行数据库仍采用静态分配方式，为了保证主实例故障后从实例能够提供和原主实例相同的计算能力，需要为主从实例配置相同容量大小的数据页面缓冲区。
70.按照处理器业界对cpu的cache命中率的研究，当cache容量和工作集大小一致时会达到一个最优的命中率，如果cache容量过小会降低命中率，但再增大cache容量并不会提高命中率。同理，主实例在一个巨大的数据集合上进行计算，应该尽量提供足够大的数据页面缓冲区，而从实例只负责回放wal日志，过大的数据页面缓冲区并不能带来更高的性能提升。很显然，均等的静态分配方式并不适用主从实例共存的场景。
71.为均衡对物理内存的使用效率，本发明设计了一种动态的数据页面缓冲区分配方式。该分配方式为数据页面缓冲区设置两个容量值：初始容量、正常容量，用于存放页面的缓冲块也由一个更改为两个：缓冲块1、缓冲块2，称为缓冲块组。当数据库实例以从实例启动时，先按照初始容量创建哈希映射数组和缓冲块1，此时的缓冲区大小为初始容量。当从实例被提升为主实例时增大哈希映射数组并创建缓冲块2，缓冲区增大到正常容量，如图4所示，当主实例降级为从实例时缩减哈希映射数组并删除缓冲区2，如图5所示。另外，缓冲区采用动态哈希算法，可以减少重哈希时移动的页面数。
72.在本实施例中，初始容量和正常容量的比例为1:4。
73.如图4所示，增大数据页面缓冲区(从实例提升为主实例)的工作流程为：
74.401：增大哈希映射数组；
75.402：计算正常容量和初始容量差值申请缓冲块2，同缓冲块1构成缓冲块组；
76.403：依照动态哈希算法，将部分页面由缓冲块1迁移至缓冲块2；
77.404：页面访问自动定位到新的存放位置；
78.如图5所示，缩减数据页面缓冲区(主实例降级为从实例)的工作流程：
79.501：依照动态哈希算法，将缓冲块2中数据页面迁移至缓冲块1；
80.502：如果缓冲块1中已经没有空闲空间，将剩余数据页面回刷至数据文件；
81.503：缩减哈希映射数组；
82.504：释放缓冲块2的内存空间；
83.505：页面访问自动定位到新的存放位置；
84.3、计算资源的均衡策略
85.主实例负责执行查询计算，需要创建足够多的线程(或进程)，消耗大量计算资源。而从实例回放wal日志也需要一定的计算资源。mpp并行数据库优先保证主实例的计算能力，为了减少主从实例之间的计算资源争用，通常仅为从实例创建一个(或少量)工作线程，并采用异步方式进行日志回放。
86.不同于在线交易系统持续高负载的特点，mpp并行数据库的负载通常具有时段性，比如在线交易库和mpp并行数据库分析库混合部署的使用场景，在线交易库负责日常交易，每天通过etl工具将在线交易库的数据同步到mpp并行数据库分析库，再做结算或洞察。在这种场景下，mpp并行数据库分析库的加载和计算负载都有明显的周期性。从实例采用异步工作方式可以起到“削峰填谷”的作用。
87.rto(recoverytimeobjective)是衡量系统高可用能力的关键指标之一。即一旦主实例发生故障后，从实例需要多久可以接替主实例对外提供服务。从实例提升为主实例最主要的准备工作是回放完成所有的wal日志，过少的工作线程势必会影响回放进度，而且异步工作方式也会使得回放进度延迟不受控，最终导致过大的rto，放大mpp并行数据库不可用窗口。
88.为了均衡对计算资源的使用效率，本发明设计了一种自适应工作方式，兼顾主实例优先使用计算资源同时又满足合理的rto。该方式为从实例增加了日志回放线程池、协调管理器以及一个rto阈值。从实例在初始阶段只启动一个日志回放线程，尽量不同主实例激烈争用计算资源。协调管理器负责实时计算wal日志回放进展，如果回放进展超过了设定的rto阈值，将唤醒更多的线程并行回放，直至全部回放完成，再释放并保留一个回放线程继续工作。至此，相当于完成了一次主从实例之间的强同步，解决了异步的延迟不受控问题。
89.另外，为提升功能的灵活性，协调管理器可以接收指令要求，比如：修改rto阈值，设置并行回放的线程数。当修改rto阈值为0时将立即触发并行回放。
90.如图6所示，从实例并行回放的具体的工作流程：
91.601：接收线程将接收到的wal日志回刷至日志文件；
92.602：接收线程通知协调管理器日志回刷进度；
93.603：回放线程顺序读取wal日志进行回放；
94.604：回放线程通知协调管理器日志回放进度；
95.605：协调管理器检查发现回刷进度和回放进度偏差超过了rto阈值，启动更多的线程并行回放；
96.606：协调管理器检查发现已全部回放完成，释放并保留一个回放线程继续工作。
97.4、回切原主实例策略
98.主实例故障掉线后从实例提升为主实例继续提供计算，此时，mpp并行数据库的服务能力会有一定下降。虽然当前有一些研究通过将负载再进一步转移到多个节点来减轻服务能力下降的影响，但这种影响对应用程序仍然是可感知的。为恢复mpp并行数据库完全服务能力，需要尽快修复故障服务器重启原主实例。原主实例重启后可能存在数据不一致，需要先作为从实例运行，待同步完成后才可以重新提升为主，这个过程称为rebalance。
99.rebalance有两个关键的指标：平滑，速度。平滑是指mpp并行数据库需要能够对外持续提供完整的服务，但可以容忍更长时间的服务能力下降。速度是指mpp并行数据库需要能够尽快恢复完全服务能力，但可以容忍一定的服务限制。不同的业务场景会有不同的指标要求，本发明设计了“平滑”、“速度”两种rebalance模式，以满足不同的场景需要。
100.4.1平滑模式rebalance
101.注册rebalance事件，mpp并行数据库启动后台任务监听rebalance进展，直至同步完成再切回原主实例。在此期间mpp并行数据库处于最大可用状态，可以对外提供完整的服务，但rebalance持续时间比较长。
102.如图7所示，平滑模式rebalance的工作流程为：
103.⑴
注册rebalance事件，并启动后台任务；
104.⑵
主实例对外继续提供完整的服务；
105.⑶
后台任务监听从实例(原主实例)的回放进度，直至完成；
106.⑷
后台任务触发rebalance，转换主从角色，主实例降级为从实例，从实例提升为主实例；
107.⑸
新的主实例开始对外提供查询计算。
108.4.2速度模式rebalance
109.执行rebalance语句，在从实例内部启动多个线程并行回放，直至同步完成再切回原主实例。该模式下rebalance耗时短，但在此期间mpp并行数据库只能提供查询服务，不允许修改，并且查询性能也受一定影响。工作示意图详见图8。
110.如图8所示，速度模式rebalance的工作流程为：
111.⑴
执行rebalance语句，等待结束；
112.⑵
限制mpp并行数据库对外提供更新、删除等修改服务；
113.⑶
通知从实例(原主实例)启动多个线程并行回放；
114.⑷
待回放完成，转换主从角色，主实例降级为从实例，从实例提升为主实例；
115.⑸
rebalance语句执行结束，新的主实例开始对外提供查询计算。
116.本发明通过上述存储io、物理内存、计算资源和回切原主实例进行实例级副本的均衡，在不妥协从实例的冗余能力的基础上最大化主实例的计算服务能力。
117.需要强调的是，本发明所述的实施案例是说明性的，而不是限定性的，因此本发明包括并不限于具体实施方式中所述的实施案例，凡是由本领域技术人员根据本发明的技术方案得出的其他实施方式，同样属于本发明保护的范围。