GPDB43 Administrator Guide--第五章 高可用

第五章 高可用

一、高可用概述

GREENPLUM可以通过一系列方案保证系统的高可用。主要措施有：

1. 硬件RAID保护数据
2. segment镜像
3. master镜像
4. 双集群（dual cluster）

        可以通过维护两个Greenplum数据库集群存储相同数据来提供另一种冗余级别。两种方法保持双集群同步数据，即“双ETL”和“备份/恢复”。双ETL提供了完整的standby集群，与primary集群具有相同的数据。 ETL（提取，转换和加载）是指清洗，转化，验证并装载数据到数据仓库。具有双ETL，这个过程是并行执行两次，每个群集一次，并每次都验证。它也允许查询两个群集上的数据，查询吞吐量加倍。应用程序可以利用这两个集群的优势，也保证了ETL成功，并通过两个集群验证。用备份/恢复方法维持双群集，先创建主群集的备份，然后在辅助群集上恢复它们。这种方法比双ETL策略需要更长的时间同步数据，但需要开发较少的应用程序逻辑。填充第二集群，数据修改情况下备份是非常适合的，日常执行ETL。

      5.备份与恢复

        建议将备份文件转移到专门的存储空间中，防止segment主机空间不足。可选的地方有：data domain、Netbackup、NFS。

•      关于增量备份

        Greenplum的数据库允许在append-optimized分区表与column-oriented表进行增量备份。当您执行增量备份，只有自上次备份以来发生更改的append-optimized分区和column-oriented的表进行备份。 （堆表始终要备份）还原增量备份需要恢复以前的完全备份和后续增量备份。

        增量备份是有益的，只有当数据库中含有大量，分区表，其中所有，但一个或几个分区保持备份之间不变。增量备份只保存更改分区和堆表。通过不备份不变分区，备份大小和时间可显著减少。

        如果一个大的事实表未分区，和一个单一的行被添加或改变时，整个表被备份，并且在备份大小或时间没有积蓄。因此，增量备份只建议在大型的，分区表和相对较小的维表的数据库。

        如果你保持双集群和使用增量备份，你可以用增量备份填充第二集群。使用--noplan选项来实现这一点，从而允许更快地施加从主站点的备份。

 

（一）segment实例镜像

        如果primary segment故障，数据库查询故障转移到mirror segment；

        对于堆栈表，数据块是保存在内存缓冲区中的，直到为新的更新块腾挪空间才刷新到磁盘。

        Append-optimized表不使用内存缓存机制；

        如果primary segment发生故障，文件复制进程停止，mirror segment自动启动为活动段实例。现在的活动镜像的系统状态变成更改跟踪（change tracking ），这意味着维护mirror系统表和所有修改的数据块change-log更改日志。当故障的主段修复并准备重新联机，管理员启动恢复过程和系统进入重新同步状态。在恢复过程应用更改日志记录到需要修复的primary segment。当恢复过程完成后系统状态变为已同步（Synchronized）。

 

Figure 7: Segment Data Mirroring in Greenplum Database

 

（二）master实例镜像

        master mirror叫standby master，可以在同一主机或不同主机上。standby master通常为warm standby。

        primary master与standby master是保持同步的。主要是通过walsender和walreceiver两个进程实现，walsender在primary master上，walreceiver在standby master上；方法是通过wal 的streaming replication实现同步；

        如果primary master出现故障，在复制过程停止，并且管理员可以激活standby master。在激活standby master的，复制的日志重建在最后成功提交交易时的第一主机的状态。激活standby master作用是作为Greenplum的数据库primary master，当standby master被初始化后，则接受指定端口上的连接。

 

 

（三）故障检测与恢复

        ftsprobe进程负责各故障检测，它会周期性的连接和扫描所有segment和数据库进程；这个周期性也是可以配置的；如果ftsprobe不能连接则标记segment为down状态，这个segment就不能操作直到管理员恢复；如果有镜像则会故障迁移启用mirror。要恢复segment可以使用gprecoverseg工具。如果没有mirror，则整个greenplum数据库会shutdown，直到管理员手动恢复；

 

二、GREENPLUM数据库镜像

（一）配置segment镜像

1.增加segment mirror，与primary在同一主机

        a.分配存储空间

        b.gpssh-exkeys，保证所有segment hosts 等效性

        c.gpaddmirrors工具执行，-p选项指导端口

2.增加segment mirror，与primary在不同主机

        a.所有节点安装软件greenplum

        b.分配存储空间

        c.gpssh-exkeys，保证等效性

        d.创建配置文件，gpaddmirrors工具执行， -o选项指导配置文件filename

            $ gpaddmirrors -o filename

配置文件格式：

filespaceOrder=[filespace1_fsname[:filespace2_fsname:...]

mirror[content]=content:address:port:mir_replication_port:

pri_replication_port:fselocation[:fselocation:...]

例子:

filespaceOrder=

mirror0=0:sdw1:sdw1-1:52001:53001:54001:/gpdata/mir1/gp0

mirror1=1:sdw1:sdw1-2:52002:53002:54002:/gpdata/mir1/gp1

mirror2=2:sdw2:sdw2-1:52001:53001:54001:/gpdata/mir1/gp2

mirror3=3:sdw2:sdw2-2:52002:53002:54002:/gpdata/mir1/gp3

        e.创建mirror，gpaddmirrors -i mirror_config_file

（二）配置master镜像

        master mirror 即standby master；两种方法创建standby master：一是创建新的greenplum数据库时，通过工具gpinitsystem；二是在已有系统上，通过工具gpinitstandby。

        切换primary与standby，参考Recovering a Failed Master章节；

        检查standby master进程状态：$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'

三、segment故障检测

        ERROR: All segment databases are unavailable ，以上错误说明数据库不可用，查询访问不到所有数据。postgres的postmaster进程会fork一个ftsprobe进程，即FTS，Fault Tolerance Server进程，通过这个进程检查所有的segment状态；gp_segment_configuration中有所有segment的状态，角色等信息

dbid	content	role	preferred_role	mode	status	port	hostname	address	replication_port	san_mounts
1	-1	p	p	s	u	5432	gp1	mdw
6	-1	m	m	s	u	6432	smdw	smdw
3	1	p	p	s	u	40000	gp3	sdw2	41000
5	1	m	m	s	u	50000	gp2	sdw1	51000
2	0	p	p	s	u	40000	gp2	sdw1	41000
4	0	m	m	s	u	50000	gp3	sdw2	51000

FTS的相关参数：

gp_fts_probe_threadcount：默认值16

gp_fts_probe_interval：默认60s

gp_fts_probe_timeout：默认20秒，检查master与segment超时时间；

gp_fts_probe_retries：默认5次

gp_log_fts：FTS日志级别："off"、"terse"、 "verbose"、"debug"，默认terse。

gp_segment_connect_timeout：默认180秒，指mirror反应超时时间；

 

（一）警告与通知

        接收系统事件通知,比如段失败,启用电子邮件或SNMP警报。参考第九章监控greenplum系统。

（二）检测故障segment主机

gpstate -e：show 错误信息

psql -c "SELECT * FROM gp_segment_configuration WHERE status='d';"

关于mirror segment实例信息：gpstate -m 

（三）检查故障segment主机的日志文件

gplogfilter检查日志信息：WARNING, ERROR, FATAL，PANIC

使用gpssh检查所有segment的日志信息：

$ 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故障恢复

（一）恢复mirror segment

        1.ping failed_seg_host_address

        2.gprecoverseg，恢复完成后，mirror进入Resynchronizing，后台操作；

        3.gpstate -m，检查状态

（二）恢复segment到preferred role

        当primary segment故障后，mirror segment会启用充当primary。由于数据或负载的问题导致不均衡，当原来的primary修复后需要使其恢复到原来的role；

        1.先检查状态，gpstate -m，确保所有mirror都是Synchronized.状态；

        2.如果有mirror是Resynchronizing，则等待同步完成

        3.gprecoverseg -r恢复其到preferred role

        4.gpstate -e,确认结果

（三）双误情况下的恢复

        当primary与mirror segment都出现故障后的恢复过程如下：

        1.重启数据库：gpstop -r

        2.重启后，gprecoverseg

        3.恢复完成后检查状态：gpstate -m

        4.如果仍然有segment处于Change Tracking状态，则：gprecoverseg -F 即full copy recovery

（四）无mirror情况下的恢复

        检查master到segment的网络连通情况，手动恢复segment主机，然后重启greenplum数据库；

        $ ping failed_seg_host_address

        $ gpstop -r

        $ gpstate

（五）segment主机不可恢复情况下greenplum恢复

        如果意外导致segment主机硬件等毁灭性原因不可恢复，则可以通过其他mirror在备用主机上恢复；

 

$gprecoverseg -i recover_config_file

         recover_config_file格式如下:

filespaceOrder=[filespace1_name[:filespace2_name:...]failed_host_address:port:fselocation [recovery_host_address:port:replication_port:fselocation[:fselocation:...]]

        例子：

filespaceOrder=sdw5-2:50002:/gpdata/gpseg2 sdw9-2:50002:53002:/gpdata/gpseg2

 

=# SELECT dbid, content, hostname, address, port,

replication_port, fselocation as datadir

FROM gp_segment_configuration, pg_filespace_entry

WHERE dbid=fsedbid

ORDER BY dbid;

 

五、master故障恢复

        $ gpactivatestandby -d /data/master/gpseg-1

        $ gpstate -f

        $ psql dbname -c 'ANALYZE;'

        $ gpinitstandby -s new_standby_master_hostname

• 恢复master到preferred role

        1.确认primary master已经完全恢复正常

        2.primary master主机上，移除data_master_directory

$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1

        3. primary master主机上初始化standby

$ gpinitstandby -s mdw

        4.检查状态：$ gpstate -f

        5.停止现在的primary master 数据库：$ gpstop -m

        6. primary master主机上，激活standby 到master：$ gpactivatestandby -d $MASTER_DATA_DIRECTORY

        7.检查状态：$ gpstate -f

        8.standby master 主机上，移除$MASTER_DATA_DIRECTORY

$ mv /data/master/gpseg-1 /data/master/backup_gpseg-1

        9.standby master 主机上初始化standby

$ gpinitstandby -s smdw

• 检查master mirroring进程状态

$ psql dbname -c 'SELECT procpid, state FROM pg_stat_replication;'

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/16976507/viewspace-1796172/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/16976507/viewspace-1796172/