Greenplum数据库高可用性概述

0    21    1

Tags:

👉 本文共约6611个字,系统预计阅读时间或需25分钟。

当Greenplum数据库 集群不允许数据丢失时,master和segment镜像功能必须启用。没有镜像就不能保证系统和数据的 高可用,此时Pivotal会尽最大的努力恢复故障集群。

Greenplum数据库系统的高可用可以通过提供容错硬件平台实现,可以通过启用Greenplum数据库高可用特性实现, 也可以通过执行定期监控和运维作业来确保整个系统所有组件保持健康来实现。

硬件平台的最终故障,可能因为常见的持久运行故障或非预期的运行环境。异常断电会导致组件临时不可用。系统可以 通过为可能故障的节点配置冗余备份节点来保证异常出现时仍能够不间断提供服务。在一些情况下,系统冗余的成本高于 用户的服务终端容忍度。此时,高可用的目标可以改为确保服务能在预期的时间内恢复。

Greenplum数据库的容错和高可用通过以下几种方式实现:

硬件级别RAID

Greenplum数据库部署最佳实践是采用硬件级别的RAID为单盘失败的情况提供高性能的磁盘冗余,避免只采用 数据库级别的容错机制。该方式可以在磁盘级别提供低级别的冗余保护。

数据存储总和校验

Greenplum数据库采用总和校验机制在文件系统上验证从磁盘加载到内存的数据没有被破坏。

Greenplum数据库有两种存储用户数据的方式:堆表和追加优化表。两种存储模型均采用总和校验机制 验证从文件系统读取的数据,默认配置下,二者采用总和校验机制验证错误的方式基本类似。

Greenplum数据库master和segment实例在他们所管理的自有内存中更新页上的数据。当内存页被更新 并刷新到磁盘时,会执行总和校验并保存起来。当下次该页数据从磁盘读取时,先进行总和校验,只有成功 通过验证的数据才能进入管理内存。如果总和校验失败,就意味着文件系统有损坏等情况发生,此时Greenplum 数据库会生成错误并中断该事务。

默认的总和校验设置能提供最好的保护,可以防止未检测到的磁盘损坏影响到数据库实例及其镜像Segment节点。

堆表的总和校验机制在Greenplum数据库采用gpinitsystem初始化时默认启用。我们可以通过设置 gpinitsystem配置文件中的HEAP_CHECKSUM参数为off来禁用堆表的总和校验 功能,但是我们强烈不推荐这么做,详见gpinitsystem

一旦集群初始化完成,就不能改变堆表总和校验机制在该集群上的状态,除非重新初始化系统并重载数据库。

可以通过查看只读服务器配置参数 data_checksums 来查看 堆表的总和校验是否开启。

当启动Greenplum数据库集群时,gpstart工具会检查堆表的总和校验机制在master和所有segment 上是启用了还是禁用了。如果有任何异常,集群会启动失败。详情请见gpstart

在一些情况下,为了保证数据及时恢复有必要忽略堆表总和校验产生的错误,设置ignore_checksum_failure系统配置参数为on会使在堆表总和校验失败时只生成一个警告信息,数据页仍然可以被夹在到管理内存中。 如果该页被更新并存到磁盘,损坏的数据会被复制到镜像segment节点。因为该操作会导致数据丢失,所以只有在启用数据 恢复时才允许设置ignore_checksum_failure参数为on。

追加优化存储表的总和校验可以在使用CREATE TABLE命令创建表时定义。默认的存储选项在 gp_default_storage_options服务器配置参数中定义。checksum 存储选项默认被启用并且强烈不建议禁用它。

如果想要禁用追加优化表上的总和校验机制,你可以

  • 在创建表时,修改gp_default_storage_options配置参数包含checksum=false 或
  • 增加checksum=false选项到CREATE TABLE语句的WITH storage_options语法部分。

注意CREATE TABLE允许为每一个单独的分区表设置包括checksums在内的存储选项。

查看CREATE TABLE命令参考和gp_default_storage_options配置文件参考语法和示例。

Segment镜像

Greenplum数据库将数据存储在多个segment实例中,每一个实例都是Greenplum数据库的一个PostgreSQL实例, 数据依据建表语句中定义的分布策略在segment节点中分布。启用segment镜像时,每个segment实例都由一对 primarymirror组成。镜像segment采用基于预写日志(WAL)流复制的方式保持与主segment 的数据一致。详情请见Segment镜像概述

镜像实例通常采用gpinitsystem或gpexpand工具进行初始化。 作为最佳实践,为了保证单机失败镜像通常运行在与主segment不同的主机上。将镜像分配到不同的主机上也有不同 的策略。当搭配镜像和主segment的放置位置时,要充分考虑单机失败发生时处理倾斜最小化的场景。

本人提供Oracle、MySQL、PG等数据库的培训和考证业务,私聊QQ646634621或微信db_bao,谢谢!

Segment镜像概述

当Greenplum数据库高可用性被启用时,有两种类型的Segment:primarySegment 和mirrorSegment。每个主Segment都有一个对应的镜像Segment。主Segment从 Master接收请求来对该Segment的数据库做更改并且接着把那些更改复制到对应的镜像。 如果主Segment变成不可用,镜像segment会切换为主segment,不可用的主segment会切换为 镜像segment。故障出现时正在进行的事务会回滚并且必须重启数据库。接下来管理员必须恢复镜像segment,并 允许镜像segment与当前主segment进行同步,最后需要交换主segment和镜像segment的角色,让他们处于自己 最佳的角色状态。

如果segment镜像未启用,当出现segment实例故障时,Greenplum数据库系统会关闭。管理员必须手工恢复所有 失败的segment实例然后才能重新启动数据库。

如果现有系统已经启用了segment镜像,当主segment实例正在生成一个快照时,主segment实例继续为用户提供服务。 当主segment快照完成并向镜像segment实例部署时,主segment的变化也会被记录。当快照完全部署到镜像segment 后,镜像segment会同步这些变化并采用WAL流复制的方式与主segment保持一致。Greenplum数据库的WAL复制使用 walsender和walreceiver复制进程。 walsender进程是主segment的进程。walreceiver进程是镜像segment 的进程。

当数据库变化出现时,日志捕获到该变化然后将变化流向镜像segment,以保证镜像与其对应的主segment一致。在WAL 复制期间,数据库变化在被应用之前先写入日志中,以确保任何正在处理的数据的完整性。

当Greenplum数据库检测到主segment故障时,WAL复制进程停止,镜像segment自动接管成为活动主segment。如果 主segment活动时,镜像segment故障或变得不可访问,主segment会追踪数据库变化并记录在日志中,当镜像恢复后 应用到镜像节点。有关segment故障检测和故障处理的详细信息,请见 检测故障的Segment

Greenplum数据库系统表包含镜像和复制的详细信息。

  • 系统表 gp_segment_configuration包含主segment、镜像segment、主master和standby master实例的当前配置和 状态信息。
  • 系统视图gp_stat_replication包含Greenplum数据库master和segment镜像功能使用的walsender 进程的复制状态统计信息。

关于Segment镜像配置

镜像segment实例可以根据配置的不同在集群主机中按不同的方式分布。作为最佳实践,主segment和它对应的镜像 放在不同的主机上。每台主机必须有相同的主和镜像segment。当你使用Greenplum工具gpinitsystemgpaddmirrors创建segment镜像时,可以设定segment镜像方式:以分组的方式镜像(默认)或 以打散的方式镜像。采用gpaddmirrors命令时,可以先创建gpaddmirrors 配置文件,然后将文件放在命令行读取执行。

以分组的方式镜像是默认的镜像方式。该方式每台主机的主segment对应的镜像都整体放在另一台主机上, 如果有一台主机故障,另外一台接管该主机服务的镜像所在的机器的活动segment数量便会翻倍。 图表 Figure 1 显示了以分组的方式配置segment镜像。

Figure 1. 以分组的方式在Greenplum数据库中分布镜像 Segment镜像概述 - 图1

以打散的方式镜像 将每一个主机的镜像分散到多台主机上,保证每一个机器上至多只有一个 镜像提升为主segment,这种方式可以防止单台主机故障后,另外的主机压力骤增。以打散方式镜像 分布要求集群主机数量多于每台主机上segment的数量。图表Figure 2显示了如何以打散的方式配置segment镜像。

Figure 2. 以打散的方式在Greenplum数据库中分布镜像 Segment镜像概述 - 图2

Master镜像

在一个高可用集群中,有两种master实例,primarystandby。像segment一样,master和standby 应该部署在不同的主机上,以保证集群不出现单节点故障问题。客户端只能连接到primary master并在上面执行查询。 standby master采用基于预写日志(WAL)流复制的方式保持与primary master的数据一致。详情请见Master镜像概述.

如果master故障了,管理员可以通过运行gpactivatestandby工具切换standby master成为 新的primary master。可以通过在master和standby上配置一个虚拟IP地址来保证当发生切换后,客户端不需要在 不同的网址之间切换。如果master主机故障,虚拟IP可以漂移到新的活动master节点上继续提供服务。

Master镜像概述

可以在单独的主机或者同一台主机上部署Master实例的一个备份或者镜像。当主Master变得无法使用时,备份 Master或者后备Master会作为一个温备提供服务。可在主Master在线时从中创建一个后备Master。

在取一个主Master实例的事务快照时,主Master会继续为用户提供服务。在取事务快照以及在后备Master上部署 事务快照时,对主Master的更改也会被记录。在该快照被部署在后备Master上之后,那些更新会被部署以同步后备 Master和主Master。当镜像Master快照部署完成后,变化会应用,二者之间会通过基于WAL日志的流复制的方式 保持同步。Greenplum WAL复制通过walsender和walreceiver 复制进程保持同步。walsender是主master的进程。walreceiver 是standby master的进程。

Figure 1. Greenplum数据库中的Master镜像
Master镜像概述 - 图1

由于Master不保存用户数据,只有系统目录表被在主Master和后备Master之间同步。当这些表被更新时,复制日志 会捕获变化并流向standby master以保持与其主master的同步。WAL复制期间,所有的数据库更改在应用之前都 会写入复制日志,以保证任何正在进行的操作的数据完整性。

以下是Greenplum数据库如何处理Master故障

  • 如果主master故障,Greenplum数据库系统关闭,master复制进程停止。管理员运行 gpactivatestandby命令将standby master提升为主master。 随着standby master提升为主,复制日志会重建主master最后成功提交的事务的相关日志。 活动standby master接下来会完全成为Greenplum数据库的master,以standby master初始化 时定义的端口号接受外部连接。详情请见恢复故障的Master
  • 如果在主master可用时,standby master故障或不可访问。主master会将数据库变化写入追踪日志, 然后等待standby master恢复后应用到其上面。

以下这些Greenplum系统表包含镜像和复制相关信息。

  • 系统表gp_segment_configuration包含主segment、镜像segment、主master和standby master实例的当前配置 及状态信息。
  • 系统视图gp_stat_replication包含Greenplum数据库master和segment镜像用到的walsender 进程的复制统计信息。

双集群

可以通过维护两套Greenplum数据库集群,都存储相同的数据来提供额外的冗余。

保持双集群数据同步有两种方法,分别叫做”双ETL”和”备份/恢复”。

双ETL提供一个与主集群数据一致的热备份集群。ETL(抽取,转换和加载)大致的过程为清理数据,转换数据,验证数据 和加载数据进入数据仓库。双ETL的方式,以上过程会被执行两次,每个集群一次,每次都需要被验证。这允许在两个集群 上进行查询数据操作,还可以提高查询的吞吐量为原来的两倍。应用可以有效的利用两套集群的优势,页可以确保ETL 成功进行并在两套集群上验证通过。

通过备份/恢复的方法来维护一个双集群,可以直接采用在主集群上创建备份,然后恢复到第二个集群上。该方法可能会比 双ETL的方式花费更多的时间来同步数据,但是对应用端特定业务逻辑开发的要求几乎没有。双ETL的优势是同步频率上更 快,时间间隔更小。

备份和恢复

建议经常备份数据库,可以保证一旦出现问题可以很容易的重新生成数据库集群。备份可以很好的保护 误操作、软件错误和硬件错误。

使用gpbackup工具备份Greenplum数据库。gpbackup在所有segment上执行并行备份, 所以备份能力随着硬件增加线性扩展。

当我们设计备份策略时,最主要的关注点是将数据存储在哪里。数据可以备份在每个segment各自的本地存储中, 但是存储在该位置会导致正常segment可用生产空间锐减,更重要的是,硬件失败可能会摧毁活动segment的 生产数据和备份数据。执行完备份后,备份文件应该从主集群移动到独立、安全的存储位置。另外,备份可以直接 存储在独立存储中。

采用gpbackup和gprestore工具,可以从一个远程位置或存储设备 发送/读取备份。目前该存储插件支持连接到Amazon S3存储服务和Dell EMC Data Domain存储设备。

采用备份/恢复存储扩展API,您可以创建gpbackup和gprestore 工具可用的定制化插件,用来集成您的存储系统到Greenplum数据库。

更多如何使用gpbackup和gprestore的信息,请见 使用gpbackup和gprestore并行备份

参考

https://www.bookstack.cn/read/greenplum-admin_guide-6.0-zh/e27c37abeae5aa55.md

标签:

头像

小麦苗

学习或考证,均可联系麦老师,请加微信db_bao或QQ646634621

您可能还喜欢...

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

12 − 2 =

 

嘿,我是小麦,需要帮助随时找我哦
  • 18509239930
  • 个人微信

  • 麦老师QQ聊天
  • 个人邮箱
  • 点击加入QQ群
  • 个人微店

  • 回到顶部
返回顶部