Greenplum数据库高可用性概述
Greenplum数据库高可用性概述
Greenplum数据库系统的高可用可以通过提供容错硬件平台实现,可以通过启用Greenplum数据库高可用特性实现, 也可以通过执行定期监控和运维作业来确保整个系统所有组件保持健康来实现。
硬件平台的最终故障,可能因为常见的持久运行故障或非预期的运行环境。异常断电会导致组件临时不可用。系统可以 通过为可能故障的节点配置冗余备份节点来保证异常出现时仍能够不间断提供服务。在一些情况下,系统冗余的成本高于 用户的服务终端容忍度。此时,高可用的目标可以改为确保服务能在预期的时间内恢复。
硬件级别RAID
Greenplum数据库部署最佳时间是采用硬件级别的RAID为单盘失败的情况提供高性能的磁盘冗余,避免只采用 数据库级别的容错机制。该方式可以在磁盘级别提供低级别的冗余保护。
数据存储总和校验
Greenplum数据库采用总和校验机制在文件系统上验证从磁盘加载到内存的数据没有被破坏。
Greenplum数据库有两种存储用户数据的方式:堆表和追加优化表。两种存储模型均采用总和校验机制 验证从文件系统读取的数据,默认配置下,二者采用总和校验机制验证错误的方式基本类似。
Greenplum数据库master和segment实例在他们所管理的自有内存中更新页上的数据。当内存页被更新 并刷新到磁盘时,会执行总和校验并保存起来。当下次该页数据从磁盘读取时,先进行总和校验,只有成功 通过验证的数据才能进入管理内存。如果总和校验失败,就意味着文件系统有损坏等情况发生,此时Greenplum 数据库会生成错误并中断该事务。
默认的总和校验设置能提供最好的保护,可以防止未检测到的磁盘损坏影响到数据库实例及其镜像Segment节点。
堆表的总和校验机制在Greenplum数据库采用gpinitsystem初始化时默认启用。我们可以通过设置 gpinitsystem配置文件中的HEAP_CHECKSUM参数为off来禁用堆表的总和校验 功能,但是我们强烈不推荐这么做,详见gpinitsystem。
一旦集群初始化完成,就不能改变堆表总和校验机制在该集群上的状态,除非重新初始化系统并重载数据库。
可以通过查看只读服务器配置参数 data_checksums 来查看 堆表的总和校验是否开启。
$ gpconfig -s 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实例都由一对 primary和mirror组成。镜像segment采用基于预写日志(WAL)流复制的方式保持与主segment 的数据一致。详情请见Segment镜像概述。
镜像实例通常采用gpinitsystem或gpexpand工具进行初始化。 作为最佳实践,为了保证单机失败镜像通常运行在与主segment不同的主机上。将镜像分配到不同的主机上也有不同 的策略。当搭配镜像和主segment的放置位置时,要充分考虑单机失败发生时处理倾斜最小化的场景。
Master镜像
在一个高可用集群中,有两种master实例,primary和standby。像segment一样,master和standby 应该部署在不同的主机上,以保证集群不出现单节点故障问题。客户端只能连接到primary master并在上面执行查询。 standby master采用基于预写日志(WAL)流复制的方式保持与primary master的数据一致。详情请见Master镜像概述.
如果master故障了,管理员可以通过运行gpactivatestandby工具切换standby master成为 新的primary master。可以通过在master和standby上配置一个虚拟IP地址来保证当发生切换后,客户端不需要在 不同的网址之间切换。如果master主机故障,虚拟IP可以漂移到新的活动master节点上继续提供服务。
双集群
可以通过维护两套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并行备份。