《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. 设置监控以在系统监控应用程序中发送通知,或在主系统失败时通过电子邮件发送通知
目录
相关文章
|
1月前
|
存储 SQL 关系型数据库
TiDB的优势:为何选择TiDB作为您的数据库解决方案
【2月更文挑战第25天】随着数据规模的不断增长和业务需求的日益复杂化,现代企业对数据库系统的扩展性、高可用以及分布式处理能力提出了更高的要求。TiDB作为一个新型的开源分布式数据库,以其独特的设计理念与卓越的技术特性,在众多数据库解决方案中脱颖而出。本文将深入剖析TiDB的核心优势,探讨其如何帮助企业从容应对海量数据挑战、实现无缝水平扩展、保障服务高可用性,并提供灵活一致的事务支持。
|
19天前
|
canal 消息中间件 关系型数据库
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
【分布式技术专题】「分布式技术架构」MySQL数据同步到Elasticsearch之N种方案解析,实现高效数据同步
66 0
|
Oracle 关系型数据库 MySQL
OceanBase实践入门:高可用原理和容灾方案
OceanBase的多副本(奇数)设计,以及使用Paxos协议同步事务日志,是OceanBase高可用能做到自动切换(RTO约20s)和不丢数据(RPO=0)的关键。OceanBase在这个设计上还衍生出很多特性:如负载均衡和异地多活等。
5042 0
|
3月前
|
Cloud Native 关系型数据库 MySQL
PolarDB MySQL企业版:云原生架构,超高性能与可靠性的完美结合
在数字化时代,数据已成为企业的核心资产。对于现代企业来说,选择一款高性能、高可靠性、高性价比的数据库至关重要。阿里巴巴自研的云原生HTAP数据库——PolarDB MySQL企业版,正是这样一款满足企业需求的理想选择。
388 1
|
7月前
|
容灾 测试技术 数据库
第四章:OceanBase集群技术架构(数据可靠及高可用)
第四章:OceanBase集群技术架构(数据可靠及高可用)
223 0
|
7月前
|
SQL 负载均衡 数据库
第四章:OceanBase集群技术架构
第四章:OceanBase集群技术架构
371 0
|
9月前
|
存储 安全 Linux
分布式数据库Couchbase 集群迁移-2
在之前的文章中,我们介绍了基于 CBBACK 以及 CBRESTORE 等操作方式进行的分布式数据库 Couchbase 集群迁移方案,具体可参考链接:分布式数据库Couchbase 集群迁移。其实,在基于不同的业务场景以及架构方案,针对分布式数据库 Couchbase 集群迁移有多种不同的实现策略,只有能够达到高效、稳定及安全,才是最优选择。
115 0
|
9月前
|
存储 JSON 缓存
分布式数据库Couchbase 集群迁移
CouchBase是一款开源的、分布式的nosql数据库,主要用于分布式缓存和数据存储领域。能够通过manage cache提供快速的亚毫米级别的k-v存储操作,并且提供快速的查询和其功能强大的能够指定SQL-like查询的查询引擎。
135 0
|
11月前
|
存储 SQL 负载均衡
【PostgreSQL架构】PostgreSQL的最佳群集高可用性方案
【PostgreSQL架构】PostgreSQL的最佳群集高可用性方案
|
SQL 存储 关系型数据库
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?
491 0
OceanBase 4.0:当我们谈单机分布式一体化架构时,我们在说什么?