OushuDB入门（三）——高可用篇

    OushuDB作为一个传统数据仓库在Hadoop上的替代品，其高可用性至关重要。通常硬件容错、OushuDB HA、HDFS HA是保持系统高可用时需要考虑并实施的三个层次。另外实时监控和定期维护，也是保证集群所有组件健康的必不可少的工作。

    总的来说，OushuDB容错高可用的实现方式包括：

    硬件组件的正常磨损或意外情况最终会导致损坏，因此有必要提供备用的冗余硬件，当一个组件发生损坏时，不中断服务。某些情况下，冗余的成本高于用户所能容忍的服务中断。此时，目标是保证所有服务能够在一个预期的时间范围内被还原。

    虽然Hadoop集群本身是硬件容错的，但OushuDB有其特殊性。OushuDB master的数据是存储在主机本地硬盘上的，是一个单故障点。作为最佳实践，OushuDB建议在部署时，master节点应该使用RAID，而segment节点应该使用JBOD。这些硬件级别的系统为单一磁盘损坏提供高性能冗余，而不必进入到数据库级别的容错。RAID和JBOD在磁盘级别提供了低层次的冗余。

    高可用集群中的master节点有两个，一个主一个从（备用）。和master节点与segment节点分开部署类似，master的主和从也应该部署到不同的主机，以容忍单一主机失效。客户端连接到主master节点并且查询只能在主master节点上执行。从master节点保持与主master节点的实时同步，这是通过将预写日志从主复制到从实现的。

    可以通过部署两套OushuDB集群，存储相同的数据，从而增加另一级别的冗余。有两个主要方法用于保持双集群的数据同步，分别是双ETL和备份/还原。

    双ETL提供一个与主集群数据完全相同的备用集群。ETL（抽取、装换与装载）指的是一个数据清洗、转换、验证和装载进数据仓库的过程。通过双ETL，将此过程并行执行两次，每次在一个集群中执行。应该在两个集群上都进行验证，以确保双ETL执行成功。这种做法是最彻底的冗余，需要部署两套OushuDB集群与ETL程序。该方法带来的一个附加好处是应用利用双集群，能够同时在两个集群上查询数据，将查询吞吐量增加一倍。

    用备份/还原方法维护一个双集群，需要创建一个主集群的备份，并在备用集群上还原。这种方法与双ETL策略相比，备用节点数据同步的时间要长的多，但优点是只需要开发更少的应用逻辑。如果数据修改和ETL执行的频率是每天或更低的频率，同时备份/还原时间又在可接受的范围内，那么用备份生成数据是比较理想的方式。注意，备份/还原方法不适用于要求数据实时同步的情况。

    OushuDB集群上可以配置两个master节点：主节点（master）和备用主节点（standby master）。客户端连接到主节点，查询只能在主节点上执行。可以在单独的机器上部署备用主节点，使群集能够更好得容忍单点故障。如果主节点无法运行，备用主节点将升级为主节点以支持集群正常运行。

    OushuDB正常提供服务的同时, 会将主节点上的事务性快照（transactional snapshot）以及基于快照的更新同步到备用主节点上，使得备用主节点与主节点保持同步。由于主节点不负责存储用户数据，主节点和备用主节点之间只同步系统元数据表。当这些表在主节点上发生更改后（如DDL所引起），将自动同步到备用主节点，使其保持最新状态。如果主节点发生故障，管理员可以激活备用主节点。OushuDB 利用同步的日志信息将集群重建为最后一成功提交事务时的状态。激活的备用主节点将作为OushuDB新的主节点，为集群提供服务。

    OushuDB中的master节点镜像架构如图1所示。

    如果主节点故障，管理员可使用命令行工具激活备用主节点。如果在集群启动时已经打开了自动切换功能，备用主节点将在主节点故障时自动升级为主节点。原故障主节点将从集群中删除，由管理员自行处理。注意，无论是自动切换还是手动切换后，集群中已经没有备用主节点，须由管理员手工添加。最好配置一个新的从master节点，继续保持master的高可用性。

    提示:

    可以在 OushuDB的安装过程中配置备用主节点，也可以向现有集群中添加。如果使用Ambari进行安装，缺省已经了配置备用主节点。参见“[OushuDB入门（一）——安装篇](https://blog.csdn.net/wzy0623/article/details/79898507)”。可以通过以下方式检查配置了备用主节点的集群状态。后面的“故障切换”中将看到手工配置备用主节点的操作步骤。

    配置好备用主节点后， 可以使用下面的方法检查备用主节点的状态。

    例如，执行下面的命令检查OushuDB集群的状态，结果如图2所示。主master状态应该是Active，备用主节点状态是Passive。

[gpadmin@hdp3~]$hawq state

    查询gp\_segment\_configuration表验证segment已经注册到主master节点，查询结果如图3所示，可以看到hdp2与hdp3的角色分别是‘s’和‘m’。

[gpadmin@hdp3~]$psql -c 'select * from gp_segment_configuration;'

    查询gp\_master\_mirroring系统视图检查主节点镜像的状态。该视图提供了关于master节点的WAL Send进程的使用信息。查询结果如图4所示，可以看到主、从master数据已经同步。

[gpadmin@hdp3~]$psql -c 'select * from gp_master_mirroring;'

    如果主节点发生故障，日志同步将停止。此时必须激活备用主节点。激活备用主节点后，OushuDB将重建最后一成功提交的事务时的状态。

    当主master不可用时，需要手工执行切换，将备用主节点激活为主master。

[gpadmin@hdp2~]$hawq activate standby

    该命令执行后，hdp2成为主master，而备用主节点的状态变为：No Standby master defined。

    登录hdp3，清空master数据目录。

[root@hdp3~]#rm -rf /data/hawq/master/*

    登录hdp2，初始化备用主节点

[gpadmin@hdp2 ~]$ . /usr/local/hawq/greenplum_path.sh  
[gpadmin@hdp2 ~]$ hawq init standby -s hdp3

    该命令执行后，hdp3成为备用主节点。

[gpadmin@hdp2~]$hawq init standby -n

    该命令停止并重启主master节点，然后同步备用主节点。

    最新的OushuDB支持备用主节点的自动激活，可以按如下步骤打开此功能。

<property>
  <name>enable_master_auto_ha</name>
  <value>on</value>
</property>
<property>
  <name>ha_zookeeper_quorum</name>
  <value>hdp1:2181,hdp2:2181,hdp3:2181</value>
</property>

    属性含义如下表：

    强烈建议将 zookeeper 集群所有服务端的地址添加到ha\_zookeeper\_quorum中，而非使用默认值。这是为了保证OushuDB主节点与备用主节点使用相同的 zookeeper 服务，以避免本地 zookeeper 服务无法使用而导致 OushuDB 无法自动切换或者发生错误切换。（注：如果第一个属性值为 on，则要求用户手动将第二个属性值添加到 hawq-site.xml，以确保 zookeeper 服务被能正常访问，否则 OushuDB将不会启动。）

[gpadmin@hdp2~]$hawq config -s enable_master_auto_ha
GUC		: enable_master_auto_ha
Value		: on
[gpadmin@hdp2~]$hawq config -s ha_zookeeper_quorum
GUC		: ha_zookeeper_quorum
Value		: hdp1:2181,hdp2:2181,hdp3:2181
[gpadmin@hdp2~]$

hawq config -c enable_master_auto_ha -v on
hawq config -c ha_zookeeper_quorum -v hdp1:2181,hdp2:2181,hdp3:2181
hawq restart cluster

hawq stop master

psql -c 'select * from gp_segment_configuration;'
psql -c 'select * from gp_master_mirroring;'

    查看OushuDB集群状态，结果如图6所示。

    如果在初始化OushuDB时没有启用HDFS的高可用性，可以使用下面的过程启用它。

    HDFS中的NameNode非常重要，其中保存了DataNode上数据块存储位置的相关关系。它主要维护两个映射，一个是文件到块的对应关系，一个是块到节点的对应关系。如果NameNode停止工作，就无法知道数据所在的位置，整个HDFS将陷入瘫痪，因此保证NameNode的高可用性是非常重要的。

    在Hadoop 1时代，只有一个NameNode。如果该NameNode数据丢失或者不能工作，那么整个集群就不能恢复了。这是hadoop 1中的单点故障问题，也是hadoop 1不可靠的表现。图7是hadoop 1的架构图。

    为了解决hadoop 1中的单点问题，hadoop 2中支持两个NameNode，每一个都有相同的职能。一个是active状态的，一个是standby状态的。当集群运行时，只有active状态的NameNode是正常工作的，standby状态的NameNode处于待命状态，时刻同步active状态NameNode的数据。一旦active状态的NameNode不能工作，通过手工或者自动切换，将standby状态的NameNode转变为active状态，就可以继续工作了。

    Hadoop 2中，两个NameNode的数据是实时共享的。新HDFS采用了一种共享机制，通过Quorum Journal Node（JournalNode）集群或者Network File System（NFS）进行共享。NFS是操作系统层面的，JournalNode是hadoop层面的（主流做法）。图8为JournalNode的架构图。

    两个NameNode为了数据同步，会通过一组称作JournalNodes的独立进程进行相互通信。当active状态的NameNode的命名空间有任何修改时，会告知JournalNodes进程。standby状态的NameNode有能力读取JNs中的变更信息，并且一直监控edit log的变化，把变化应用于自己的命名空间。standby可以确保在集群出错时，命名空间状态已经完全同步。

    对于HA集群而言，确保同一时刻只有一个NameNode处于active状态是至关重要的。否则，两个NameNode的数据状态就可能产生分歧，或造成数据丢失，或产生错误的结果。为了保证这点，需要利用ZooKeeper。首先HDFS集群中的两个NameNode都在ZooKeeper中注册，当active状态的NameNode出故障时，ZooKeeper能检测到这种情况，然后它就会自动把standby状态的NameNode切换为active状态。

    至此已经配置好HDP HDFS的高可用性。从NameNode UI可以看到，hdp1和hdp2分别显示为active和standby。如图17、18所示。

    此时在hdp1上执行如下命令关闭hdp1上的NameNode：

[hdfs@hdp1 ~]$ /usr/hdp/2.5.3.0-37/hadoop/sbin/hadoop-daemon.sh stop namenode  
stopping namenode  
[hdfs@hdp1 ~]$  

    再次查看hdp2上的NameNode，发现已自动切换为active，如图19所示。

    此时在hdp1上执行如下命令启动hdp1上的NameNode：

[hdfs@hdp1 ~]$ /usr/hdp/2.5.3.0-37/hadoop/sbin/hadoop-daemon.sh start namenode   
starting namenode, logging to /var/log/hadoop/hdfs/hadoop-hdfs-namenode-hdp1.out 
[hdfs@hdp1 ~]$  

    再次查看hdp1上的NameNode，发现已自动切换为standby，如图20所示。

    缺省的文件空间名为dfs\_system，存在于pg\_filespace目录，其参数pg\_filespace\_entry包含每个文件空间的细节信息。为了将文件空间位置迁移到HDFS HA的位置，必须将数据迁移到集群中新的HDFS HA路径。

    使用下面的SQL查询收集关于HDFS上的文件空间位置信息。

SELECT  
    fsname, fsedbid, fselocation  
FROM  
    pg_filespace AS sp, pg_filespace_entry AS entry, pg_filesystem AS fs  
WHERE  
    sp.fsfsys = fs.oid AND fs.fsysname = 'hdfs' AND sp.oid = entry.fsefsoid  
ORDER BY  
    entry.fsedbid; 

    输出包含信息中包含HDFS路径共享相同的前缀，以及当前文件空间的位置，如图21所示。

    为了在OushuDB中使用HDFS HA，需要文件空间名和HDFS路径的通用前缀信息。文件空间位置的格式类似一个URL。如果无HA的文件空间位置是‘hdfs://test5:9000/hawq/hawq-1459499690’，并且HDFS HA的通用前缀是‘hdfs://hdfs-cluster’，那么新的文件空间位置应该是‘hdfs://hdfs-cluster/hawq/hawq-1459499690’。

    注意：Ambari用户必须手工执行这个步骤。

    在OushuDB中启用 HDFS HA时会修改OushuDB的目录和永久表。因此迁移文件空间位置前，先要备份目录，以确保不会因为硬件失效或在一个操作期间（如杀掉OushuDB进程）丢失数据。

export PGPORT=8020

hawq config -s hawq_master_directory
export MDATA_DIR=/data/hawq/master  

[gpadmin@hdp3 ~]$ psql -c "select pg_terminate_backend(procpid) from pg_catalog.pg_stat_activity where procpid != pg_backend_pid()" 

[gpadmin@hdp3 ~]$ psql -c "CHECKPOINT"

[gpadmin@hdp3 ~]$ hawq stop cluster -a -M fast

$ mkdir -p ~/backup
$ cp -r ${MDATA_DIR} ~/backup

    主节点数据目录包含子目录，一定要备份此目录。

    注意：Ambari用户必须手工执行这个步骤。OushuDB提供了命令行工具hawq filespace，迁移文件空间的位置。

export PGPORT=9000

[gpadmin@hdp3 master]$ hawq filespace --movefilespace default --location=hdfs://mycluster/hawq_data

    迁移文件空间时可能出现的以下潜在错误：

    如果使用命令行应用安装和管理OushuDB集群，参考[http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/admin/HAWQFilespacesandHighAvailabilityEnabledHDFS.html#configuregphomeetchdfsclientxml](http://hawq.incubator.apache.org/docs/userguide/2.1.0.0-incubating/admin/HAWQFilespacesandHighAvailabilityEnabledHDFS.html#configuregphomeetchdfsclientxml)，修改OushuDB配置以使用NameNode HA服务。

    如果使用Ambari管理HDFS和OushuDB，不需要执行这些步骤，因为Ambari在启用了NameNode HA后会自动做这些修改。

[gpadmin@hdp3 master]$ hawq start cluster -a 

[gpadmin@hdp3 master]$ hawq init standby -n -M fast

    至此已经在OushuDB的文件空间中使用了HDFS HA，再次查询文件空间的信息，输出结果如图22所示。

    OushuDB的容错服务（fault tolerance service，FTS）使得OushuDB可以在segment节点失效时持续操作。容错服务自动运行，并且不需要额外的配置。

    每个segment运行一个资源管理进程，定期（缺省每30秒）向主节点的资源管理进程发送segment状态。这个时间间隔由hawq\_rm\_segment\_heartbeat\_interval服务器配置参数所控制。当一个segment碰到严重错误，例如，由于硬件问题，segment上的一个临时目录损坏，segment通过心跳报告向master节点报告有一个临时目录损坏。master节点接收到报告后，在gp\_segment\_configuration表中将该segment标记为DOWN。所有segment状态的变化都被记录到gp\_configuration\_history目录表，包括segment被标记为DOWN的原因。当这个segment被置为DOWN，master节点不会在该segment上运行查询执行器。失效的segment与集群剩下的节点相隔离。

    包括磁盘故障的其它原因会导致一个segment被标记为DOWN。举例来说，OushuDB运行在YARN模式中，每个segment应该有一个运行的NodeManager（Hadoop的YARN服务），因此segment可以被看做OushuDB的一个资源。但如果segment上的NodeManager不能正常操作，那么该segment会在gp\_segment\_configuration表中被标记为DOWN。失效对应的原因被记录进gp\_configuration\_history。

    注意：如果一个特定段上的磁盘故障，可能造成HDFS错误或OushuDB中的临时目录错误。HDFS的错误由Hadoop HDFS服务所处理。

    为了查看当前segment的状态，查询gp\_segment\_configuration表。如果segment的状态是DOWN，“description”列显示原因。原因可能包括下面的任何原因，可能是单一原因，也可能是以分号（“;”）分割的几个原因。

    原因：heartbeat timeout

    主节点没有接收到来自段的心跳。如果看到这个原因，确认该segment上的OushuDB是否运行。如果segment在以后的时间报告心跳，segment被自动标记为UP。

    原因：failed probing segment

    master节点探测segment以验证它是否能被正常操作，段的响应为NO。在一个OushuDB实例运行时，查询分发器发现某些segment上的查询执行器不能正常工作。master节点上的资源管理器进程向这个segment发送一个消息。当segment的资源管理器接收到来自master节点的消息，它检查其PostgreSQL的postmaster进程是否工作正常，并且向master节点发送一个响应消息。当master节点收到的响应消息表示该segment的postmaster进程没有正常工作，那么master节点标记段为DOWN，原因记为“failed probing segment.”。检查失败segment的日志并且尝试重启OushuDB实例。

    原因：communication error

    master节点不能连接到segment。检查master节点和segment之间的网络连接。

    原因: resource manager process was reset

    如果segment资源管理器进程的时间戳与先前的时间戳不匹配，意味着segment上的资源管理器进程被重启过。在这种情况下，OushuDB master节点需要回收该segment上的资源并将其标记为DOWN。如果master节点从该segment接收到一个新的心跳，它会自动标记为UP。

    原因：no global node report

    OushuDB使用YARN管理资源，但没有为该segment接收到集群报告。检查该segment上的NodeManager是否可以正常操作。如果不能，尝试启动该segment上的NodeManager。在NodeManager启动后，运行yarn node --list查看该节点是否在列表中。如过存在，该段被自动置为UP。