《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. 设置监控以在系统监控应用程序中发送通知,或在主系统失败时通过电子邮件发送通知
目录
相关文章
|
6月前
|
存储 SQL 关系型数据库
TiDB的优势:为何选择TiDB作为您的数据库解决方案
【2月更文挑战第25天】随着数据规模的不断增长和业务需求的日益复杂化,现代企业对数据库系统的扩展性、高可用以及分布式处理能力提出了更高的要求。TiDB作为一个新型的开源分布式数据库,以其独特的设计理念与卓越的技术特性,在众多数据库解决方案中脱颖而出。本文将深入剖析TiDB的核心优势,探讨其如何帮助企业从容应对海量数据挑战、实现无缝水平扩展、保障服务高可用性,并提供灵活一致的事务支持。
|
3月前
|
存储 容灾 关系型数据库
OceanBase 高可用性架构解析
【8月更文第31天】在大数据和云计算蓬勃发展的今天,数据库作为数据存储的核心组件,其稳定性和可靠性直接影响到整个系统的性能。OceanBase 是由阿里巴巴集团自主研发的一款分布式关系型数据库系统,旨在为大规模在线交易处理(OLTP)场景提供高性能、高可用性的解决方案。本文将深入探讨 OceanBase 是如何通过其独特的架构设计来确保数据的高可用性和容灾能力。
215 0
|
2月前
|
监控 容灾 关系型数据库
Hologres 的高可用性与容灾解决方案
【9月更文第1天】随着企业对实时数据分析的需求不断增加,数据仓库不仅要具备高性能的查询能力,还需要具备高可用性和灾难恢复的能力。Hologres 作为一款基于 PostgreSQL 的实时数仓服务,不仅提供了强大的在线分析处理(OLAP)功能,还内置了一系列高可用性和容灾机制。本文将详细介绍 Hologres 的高可用架构,并提供实现容灾备份的具体方案。
77 7
|
3月前
|
SQL 关系型数据库 MySQL
使用OceanBase进行大规模数据迁移的最佳实践
【8月更文第31天】随着业务的不断扩展,数据迁移成为了企业日常运营中不可避免的任务之一。对于那些正在从传统的数据库系统向分布式数据库系统过渡的企业来说,数据迁移尤为重要。OceanBase 是一个由阿里巴巴集团开发的高性能分布式关系数据库,它以其高可用性、水平扩展能力和成本效益而闻名。本文将探讨如何使用 OceanBase 进行大规模数据迁移,并提供相关的最佳实践和代码示例。
276 1
|
Oracle 关系型数据库 MySQL
OceanBase实践入门:高可用原理和容灾方案
OceanBase的多副本(奇数)设计,以及使用Paxos协议同步事务日志,是OceanBase高可用能做到自动切换(RTO约20s)和不丢数据(RPO=0)的关键。OceanBase在这个设计上还衍生出很多特性:如负载均衡和异地多活等。
5505 0
|
6月前
|
关系型数据库 MySQL 数据库
测试部署PolarDB-X 分布式与集中式
在本文中,作者详述了在CentOS 7.9上部署测试PolarDB-X分布式与集中式数据库的过程。PolarDB-X作为阿里云优化的分布式数据库,提供高稳定性和与MySQL的兼容性,是应对单体数据库扩展性和性能瓶颈的解决方案,同时也符合国产化需求。文章介绍了部署环境准备,包括关闭防火墙和SELinux,设置系统参数,安装Python3和Docker,以及配置MySQL客户端。接着,通过PXD工具部署了PolarDB-X的集中式和分布式版,遇到的问题包括阿里云镜像源异常导致的部署失败以及指定版本安装的困扰。最后,作者进行了初步的压力测试,并对文档完善、生态工具建设以及提供更多使用案例提出了建议。
47950 10
测试部署PolarDB-X 分布式与集中式
|
6月前
|
存储 关系型数据库 分布式数据库
【PolarDB开源】PolarDB高可用架构解析:确保业务连续性的关键设计
【5月更文挑战第22天】阿里云PolarDB是一款高可用、高性能的云原生数据库,采用分布式共享存储架构实现计算与存储分离。通过主从复制保证数据实时同步,当主节点故障时,从节点能快速接管。此外,PolarDB提供自动故障转移和数据备份恢复功能,确保业务连续性和数据安全性。一个简单的Python SDK使用示例展示了查询数据的过程。总之,PolarDB通过多种机制保障了企业在异常情况下的服务稳定和数据完整性。
262 5
|
容灾 测试技术 数据库
第四章:OceanBase集群技术架构(数据可靠及高可用)
第四章:OceanBase集群技术架构(数据可靠及高可用)
360 0
|
SQL 存储 关系型数据库
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?
566 0
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?
|
存储 缓存 容灾
HBase可用性分析与高可用实践
HBase可用性分析与高可用实践
329 0
HBase可用性分析与高可用实践