10. Greenplum高可用架构

10. Greenplum高可用架构与数据持久化论述

 

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

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

本文会介绍一下master的standby创建,切换;segment添加mirror,如何检测和修复。

目录

10. Greenplum高可用架构与数据持久化论述

1 概述

硬件级别RAID

数据存储总和校验

Segment镜像

Master镜像

双集群

备份和恢复

总结

2 Master mirror

创建一个standby master host

切换

激活master

3 segment mirror

启用 segment mirror 镜像(有条件我会再做测试实验)

检测segment 故障

恢复segment故障

segment mirror故障分析示例

segment 镜像 group vs spread

Group Mirroring 部署方案

Spread Mirroring 部署方案

Group + Spread Mirroring 部署方案


 

1 概述

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

 

硬件级别RAID

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

数据存储总和校验

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

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

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

 

 $ gpconfig -s data_checksums
 [gpadmin@mdw ~]$ gpconfig -s data_checksums
 Values on all segments are consistent
 GUC          : data_checksums
 Master  value: on
 Segment value: on
 [gpadmin@mdw ~]$ 
 ​
 强烈建议不要关闭此参数

 

Segment镜像

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

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

 

Master镜像

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

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

详细的切换步骤请我之前写的blog:

Greenplum实战--standby master的模拟故障与修复

https://blog.csdn.net/murkey/article/details/105625972

master节点故障切换到standby master上

https://blog.csdn.net/murkey/article/details/105648866

 

双集群

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

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

 

备份和恢复

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

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

具体的备份和恢复我这边会单独设一个专栏来专门测试

 

总结

 

 

  • Server HA 主机的高可用

    • 每个服务都要有RAID

    • 其他硬件部件都要冗余部件

    • Raid5 data bebuilt

  • Greenplum数据库Segment mirror

  • Master server和standby master server

    • 自动failover

    • 通过VIP

 

 

2 Master mirror

 

 

创建一个standby master host

详细的操作步骤请见blog:

https://blog.csdn.net/murkey/article/details/105625481

这里就不详细描述了,只简单把整体的操作过程步骤大致说一下:

  1. 创建用户和安装目录

  2. /etc/hosts文件修改

  3. 上传软件和解压缩

  4. 在master上执行gpinitstandby -s smdw

  5. 检查状态gpstate -f,master的状态是active,standby master的状态是passive

 

 

切换

详细的切换步骤请我之前写的blog:

Greenplum实战--standby master的模拟故障与修复

https://blog.csdn.net/murkey/article/details/105625972

master节点故障切换到standby master上

https://blog.csdn.net/murkey/article/details/105648866

 

激活master

 

  1. 在standby master主机上运行gpactivatestandby工具来激活它。

    例如: $ gpactivatestandby -d /data/master/gpseg-1

此处-d选项指定正在激活的master主机的数据目录。

激活standby后,状态变为active或primary master

  1. 上面工具执行完成后,运行gpstate带有-b 选项来显示系统汇总信息: $ gpstate -b

master实例状态应该为Active。如果没有配置standby master,该命令会显示standby master的状态为 No master standby configured。如果配置了standby master,它的状态为 Passive。

  1. 在切换到最新的活动Master主机后,在其上运行 ANALYZE 例如:$ psql dbname -c 'ANALYZE;'

  2. 可选:如果激活之前的standby master时没有配置一个新的standby master。可以运行 gpinitstandby工具来配置激活一个新的standby master。

 

3 segment mirror

 

启用 segment mirror 镜像(有条件我会再做测试实验)

这里有一篇添加mirror的blog写的不错:http://www.dbdream.com.cn/2016/03/greenplum%e6%95%b0%e6%8d%ae%e5%ba%93%e4%b8%basegment%e5%a2%9e%e5%8a%a0mirror%e8%8a%82%e7%82%b9/

镜像Segment允许数据库查询在主Segment不可用时故障转移到备用Segment。默认情况下,镜像会被配置在主Segment所在的主机阵列上。也可以为镜像Segment选择一组完全不同的主机,这样它们就不会分享任何主Segment的机器。

重要: 在在线数据复制处理期间,Greenplum数据库应该处于一种静止状态,不应运行负载和其他查询。

要增加Segment镜像到一个现有系统(和主Segment相同的主机)

  1. 在所有的Segment主机上为镜像数据分配数据存储区域。数据存储区域必须与主Segment的文件系统位置不同。

  2. 使用gpssh-exkeys确保Segment主机能通过SSH和SCP免密码连接到彼此。

  3. 运行

    gpaddmirrors

    工具在Greenplum数据库系统中启用镜像。例如,在主Segment端口号基础上加10000来计算得到镜像Segment的端口号:

     $ gpaddmirrors -p 10000

    其中-p指定要加在主Segment端口号上的数字。使用默认的组镜像配置来增加镜像。

要增加Segment镜像到一个现有系统(和主Segment不同的主机)

  1. 确保在所有主机上都安装有Greenplum数据库软件。详细的安装指导请见Greenplum数据库安装指南

  2. 在所有的Segment主机上为镜像数据分配数据存储区域。

  3. 使用gpssh-exkeys确保Segment主机能通过SSH和SCP免密码连接到彼此。

  4. 创建一个配置文件,其中列出要在其上创建镜像的主机名称、端口号和数据目录。要创建一个示例配置文件作为起点,可运行:

     $ gpaddmirrors -o filename          

    镜像配置文件的格式为:

     filespaceOrder=[filespace1_fsname[:filespace2_fsname:...] 
     mirror[content]=content:address:port:mir_replication_port:
     pri_replication_port:fselocation[:fselocation:...]

    例如这是一个配置文件,其中有两个Segment主机,每个主机上有两个Segment,并且除了默认的pg_system文件空间之外不配置额外的文件空间:

     filespaceOrder=
     mirror0=0:sdw1-1:52001:53001:54001:/gpdata/mir1/gp0
     mirror1=1:sdw1-2:52002:53002:54002:/gpdata/mir1/gp1
     mirror2=2:sdw2-1:52001:53001:54001:/gpdata/mir1/gp2
     mirror3=3:sdw2-2:52002:53002:54002:/gpdata/mir1/gp3
  5. 运行

    gpaddmirrors

    工具在Greenplum数据库系统中启用镜像:

     $ gpaddmirrors -i mirror_config_file
                    

    其中-i提到所创建的镜像配置文件。

 

 

检测segment 故障

通过命令检测segment

  1. 在Master上,用-e选项运行gpstate]

    工具显示有错误情况的Segment:

     $ gpstate -e
  2. 可以检查 gp_segment_configuration系统表

 psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"
 ​
 [gpadmin@mdw ~]$ psql postgres -c "SELECT * FROM gp_segment_configuration WHERE status='d';"
  dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port 
 ------+---------+------+----------------+------+--------+------+----------+---------+------------------
 (0 rows)
 ​
 [gpadmin@mdw ~]$ 
  1. 针对那些故障的segment实例,注意主机、端口号、原来角色和数据目录。这些信息会帮助您在问题定位时 提供有用的决策信息。

  2. 要展示镜像segment实例的信息,运行:

 $ gpstate -m

通过日志文件进行检测

  1. 对于WARNING、ERROR、FATAL或 PANIC日志级别的消息,使用gplogfilter检查Master的日志文件:

     $ gplogfilter -t
  2. 对于每个Segment实例上的WARNING、ERROR、 FATAL或PANIC日志级别的消息,使用gpssh检查。例如:

     $ gpssh -f seg_hosts_file -e 'source 
     /usr/local/greenplum-db/greenplum_path.sh ; gplogfilter -t 
     /data1/primary/*/pg_log/gpdb*.log' > seglog.out

 

恢复segment故障

如果一台主机是不可操作的(例如由于硬件失效导致),就需要把那些Segment恢复到备用的硬件资源上。如果启用了镜像,可以使用gprecoverseg工具从segment的镜像把它恢复到另一台主机上。例如: $ gprecoverseg -i recover_config_file

其中recover_config_file的格式是: <failed_host>:<port>:<data_dir>[ <recovery_host>:<port>:<recovery_data_dir>]

例如,要恢复到不同于失效主机的另一主机上且该没有额外的文件空间配置, (除默认的pg_system文件空间外): sdw1-1:50001:/data1/mirror/gpseg16 sdw4-1:50001:/data1/recover1/gpseg16

 

spread mirror说明

 

  • spread把mirror分散到所有的其他host上

  • 需要配置中有足够的host

  • hosts数量要大于每个主机上的segment instance的数量

 

segment mirror故障分析示例

 

 

1 ftsprobe 进程(master)发现P5宕机,把它标识为invalid

 

 

2 验证了之前的M5是同步的,这是把M5变更为主用的P5

 

3 修复了M5故障,可以把M5 ONLINE起来,变成了P5的mirror

 

4 利用gprecoverseg 命令把之前的P5,现在的M5启动起来

 

5 当前的集群的配置是不均衡的,主机2上有2P4M,主机是4P2M

 

6 利用gprecoverseg -r 重新平衡集群

 

segment 镜像 group vs spread

 

 

Group Mirroring 部署方案

 

按照以下4台机器Group Mirroring的部署方案总结

缺点: 一台机器down掉后,会把流量全部放在下一个节点,下一个节点的流量会变成2倍的流量

优点: down掉一台机器后,集群能正常的提供服务,如果再down掉第二台集群就不可用

Spread Mirroring 部署方案

按照以下4台机器Spread Mirroring的部署方案总结

缺点: 一台机器down掉后,会把流量全部放在下两个节点

优点: down掉一台机器后,集群能正常的提供服务,如果再down掉第二台集群就不可用

Group + Spread Mirroring 部署方案

如果集群比较大建议使用Group + Spread Mirroring部署方案,如果集群由down流量会分流道其他的机器上,集群不可用的几率比较小。

 

 

 

 

 

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值