《Greenplum5.0 最佳实践》 高可用性<1>

简介: master的备份, 磁盘的选择

高可用性

Greenplum 数据库集群支持高可用,容错性数据服务。为了保证所需要的服务级别,每个组件都必须有一个备用的服务器,
避免发生故障没有有效的准备。

磁盘存储

Greenplum 数据库是 "Shared-nothing" MPP 架构,主节点和段节点都有其各自专有的内存和磁盘存储空间,每一个主接节点或者
段实例都有其自己独立的数据文件。为了更高的可靠性和性能表象。 Pivotal 建议使用8到24个硬盘的RAID存储解决方案。使用RAID
5(或6)时,大量磁盘可提高吞吐性能,因为增加了并行的磁盘I/O。RAID控制器可以持续使用故障磁盘中的数据,因为它可以保存每个
磁盘上的奇偶校验数据,从而可以重新构建磁盘阵列中的任何实盘的成员上的数据。如果配置了热备份(或者操作员使用新的备份替换
故障磁盘),则控制器奖后自动构建故障磁盘。
RAID 1 是完全镜像磁盘,所以一个磁盘挂掉,可以立即获得一个跟磁盘挂掉之前性能一样的替代品。使用RAID5时,必须根据剩余的
活动驱动器上的数据重新构建发生故障的阵列成员上的每一个 I/O 数据,知道更换新的磁盘重建,所以这里有一个临时的性能下降。如
Greenplum 的master和segment 都有镜像,你可以将在磁盘重建期间任何受到影响的实例切换到镜像,以保证可以接受的性能。

例如,如果整个RAID卷失效,一个 RAID 磁盘阵列可以有一个单点的故障。在硬件层面,你可以保护磁盘阵列失效通过设置阵列镜像
,使用其他的节点操作系统做镜像或者使用RAID控制器做镜像。

定期见识每一个每段主机上的可用磁盘空间是非常重要的。在 gptoolkit 模式下查询外部表 gp_disk_free 可以获得当前磁盘的使用情
况,其底层是 linux 的命令 df 实现的。确定去检查这里有足够的磁盘空间在执行一些耗费磁盘空间的操作时。(例如拷贝大表)

具体使用方法可以参看 中的gp_toolkit.gp_disk_free

最佳实践

  1. 使用RAID存储,每个节点实际使用8到24块磁盘
  2. 使用的RAID为 1 5 6 这样可以容错,推荐使用RAID6 (RAID 1 + RAID 5)
  3. 在磁盘阵列中配置热备份,以便在检测到磁盘故障时自动开始重建
  4. 通过对RAID卷进行镜像重建,防止整个磁盘阵列出现故障并性能降低
  5. 时刻监控磁盘的使用情况,当需要的时候可以增加磁盘的容量
  6. 监控各个段的数据倾斜情况,确保数据最终分布在每一个节点。避免木桶效应

Master 监控

Greenplum 的master节点是客户端的唯一能访问的单点。master 节点中存储这数据库系统的全局 catalog, 这些系统表存储这关于
数据库实例信息的元数据,但是这里不存放用户使用的数据。如果master节点挂掉,那么整个Greenplum 数据库集群就会挂掉。因为已经不能访问真个数据库集群了,所以最好配置standby节点。

Master 镜像使用的是两个进程,即活动主机上的发送者和镜像主机上的接收者,以使得镜像和主机同步。当更改应用于主系统目录
时,活动的主服务器的预写日志(WAL)传送到镜像,以便在主服务器上应用的每一个事务都应用到镜上。

standby 是一个热备,如果master出现故障,那么需要使用管理员用户权限去切换。使用的命令是 gpactivatestandby 在standby
主机上。这样所有在master的任务,全部要在standby上重新构建,连接,运行。

具体的内容可以参考手册 《Greenplum Database Administrator Guide for more information》

最佳实践

  1. master 节点设置一个 standby 节点, 避免 master 节点失效。
  2. standby 可以和 master 一个节点,也可以不是同一个物理节点。但是最好还是不是同一个物理节点
  3. 要做好规划如何在发生故障的时将客户端切换到新的主机实例上。例如可以通过更新DNS实现快速切换
  4. 设置监控以在系统监控应用程序中发送通知,或在主系统失败时通过电子邮件发送通知
目录
相关文章
|
3月前
|
存储 容灾 关系型数据库
OceanBase 高可用性架构解析
【8月更文第31天】在大数据和云计算蓬勃发展的今天,数据库作为数据存储的核心组件,其稳定性和可靠性直接影响到整个系统的性能。OceanBase 是由阿里巴巴集团自主研发的一款分布式关系型数据库系统,旨在为大规模在线交易处理(OLTP)场景提供高性能、高可用性的解决方案。本文将深入探讨 OceanBase 是如何通过其独特的架构设计来确保数据的高可用性和容灾能力。
243 0
|
15天前
|
存储 Prometheus 监控
构建高可用性ClickHouse集群:从理论到实践
【10月更文挑战第27天】在数据驱动的时代,构建一个稳定、高效的数据库系统对于企业的业务发展至关重要。作为一名数据工程师,我深知数据库系统的高可用性和可扩展性对于支撑企业应用的重要性。在这篇文章中,我将分享如何构建一个高可用性的ClickHouse集群,从分布式表的设计到数据复制与分片,再到故障恢复机制,确保系统在大规模数据处理中的稳定性和可靠性。
48 0
|
17天前
|
缓存 监控 大数据
构建高可用AnalyticDB集群:最佳实践
【10月更文挑战第25天】在大数据时代,数据仓库和分析平台的高可用性变得尤为重要。作为阿里巴巴推出的一款完全托管的PB级实时数据仓库服务,AnalyticDB(ADB)凭借其高性能、易扩展和高可用的特点,成为众多企业的首选。本文将从我个人的角度出发,分享如何构建和维护高可用性的AnalyticDB集群,确保系统在各种情况下都能稳定运行。
25 0
|
Oracle 关系型数据库 MySQL
OceanBase实践入门:高可用原理和容灾方案
OceanBase的多副本(奇数)设计,以及使用Paxos协议同步事务日志,是OceanBase高可用能做到自动切换(RTO约20s)和不丢数据(RPO=0)的关键。OceanBase在这个设计上还衍生出很多特性:如负载均衡和异地多活等。
5544 0
|
2月前
|
监控 容灾 关系型数据库
Hologres 的高可用性与容灾解决方案
【9月更文第1天】随着企业对实时数据分析的需求不断增加,数据仓库不仅要具备高性能的查询能力,还需要具备高可用性和灾难恢复的能力。Hologres 作为一款基于 PostgreSQL 的实时数仓服务,不仅提供了强大的在线分析处理(OLAP)功能,还内置了一系列高可用性和容灾机制。本文将详细介绍 Hologres 的高可用架构,并提供实现容灾备份的具体方案。
82 7
|
5月前
|
运维 关系型数据库 分布式数据库
技术选型思考:分库分表和分布式DB(TiDB/OceanBase) 的权衡与抉择
技术选型思考:分库分表和分布式DB(TiDB/OceanBase) 的权衡与抉择
|
6月前
|
canal 消息中间件 关系型数据库
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
266 0
|
容灾 测试技术 数据库
第四章:OceanBase集群技术架构(数据可靠及高可用)
第四章:OceanBase集群技术架构(数据可靠及高可用)
362 0
|
SQL 负载均衡 数据库
第四章:OceanBase集群技术架构
第四章:OceanBase集群技术架构
510 0
|
存储 SQL 负载均衡
【PostgreSQL架构】PostgreSQL的最佳群集高可用性方案
【PostgreSQL架构】PostgreSQL的最佳群集高可用性方案