跳转到主要内容
开始新对话

未解决

此帖子已超过 5 年

Fenglin1

2 Intern

 • 

2.1K 消息

1301

2015年12月16日 19:00

专家问答“Pivotal BDS开源大数据套件及解决方案”精华整理

专家问答“Pivotal BDS开源大数据套件及解决方案”精华整理

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese publish_button_16.ico

介绍

     【专家问答-Pivotal特别版】Pivotal BDS开源大数据套件及解决方案，讨论和分享有关Pivotal BDS开源大数据套件及解决方案的话题。本文整理这期专家问答中的精华问题。

更多信息

Q1：能不能先给大家介绍一下Pivotal BDS开源大数据套件中有哪些产品？这些产品的主要功能是什么？

A1：Pivotal BDS包括Greenplum Database、HAWQ、Gemfire、Pivotal Hadoop。其中：

1)    Greenplum database：一个分布式数据库。

2)    HAWQ：运行在Hadoop上的数据库，可以直接执行标准SQL。

3)    Gemfire: 内存数据库（12306火车票系统是国内的一个客户）。

4)    Pivotal Hadoop：外包Hortonworks的Hadoop产品，包括开源社区的Hadoop组件和HAWQ数据库。

Q2：Greenplum和HAWQ在结构上的区别是什么？

A2：Greenplum数据库和HAWQ的结构基本上是一样的，Greenplum数据库在PostgreSQL基础上二次开发而成，HAWQ由Greenplum数据库二次开发而来。Greenplum 数据库和HAWQ都是一个分布式的数据库，由若干个子数据库组成，子数据库相互协作处理数据。Greenplum数据库运行在Linux上，访问常规的文件系统，HAWQ运行在Hadoop上，访问HDFS文件系统。GPDB应用在传统环境，访问传统的文件系统，HAWQ应用在Hadoop环境中，访问HDFS文件系统。如果当前应用已经部署在Hadoop上，建议选择HAWQ。

BDS_1.png

     HAWQ和GPDB功能上基本上没区别，只是存储的文件系统不一样。HDFS文件本身自带容错功能，默认同时存3份保留在磁盘上，任何一份出错了都可以访问另外两份好的，即冗余性比普通文件系统好。不过一般来说，服务器的磁盘在硬件上都普遍使用raid技术，一定程度上也保障了数据安全。

Q3：有没有官方说明大数据套件各个产品的服务支持时间？

A3：有的，请点击 http://d1fto35gcfffzn.cloudfront.net/support/PivotalLifecycleMatrix.pdf

Q4：Greenplum相比其他关系型数据库有哪些优势？适合用作OLTP系统吗？

A4：Greenplum数据库是一个数据仓库，擅长于大批量数据的低并发处理，不适合做OLTP。而Gemfire是一个分布式的scalable的高性能非常适合实时OLTP的内存数据库。

Q5：能不能简单介绍一下Gemfire？

A5：Pivotal Gemfire的数据的存储方式有多个选择：

1)    运行计算，并把数据存储于内存

2)    存储倒文件系统或则外部storage（share nothing的架构）

3)    存储倒外部的database比如Oracle，MySQL，Postgres等等。

4)    存储到HDFS文件系统。Pivotal Gemfire9.0以后支持HDFS Persistence功能。

另外，Pivotal GemfireXD1.x 已经支持HDFS Persistence功能，并且支持HAWQ直接读取GemfireXD数据。

1)    Gemfire／Geode现在加大和其他系统的之间的Integration，

2)    比如Gemfire-GreenPlum Connector（已经Implemented）,

3)    Gemfire-Spark Connector（已经Implemented）, Gemfire integrate with lucene, Nagios（正在Implementing）,

4)    Gemfire runs on Pivotal Cloud foundary（已经Implemented）, Gemfire-HDFS（正在进行中）


关于这些Integration的相关信息，可以参考下面link：https://cwiki.apache.org/confluence/display/GEODE/Roadmap

     Gemfire本身是一个支持Transaction，ACID的高性能的分布式内存数据，现在的版本使用OQL支持SQL。但和传统的关系型数据库有一些观念上的差异。比如RDBMS是使用表的单元，Gemfire是使用Region的概念。

     Pivotal SQLFire（Derby＋Gemfire）/ GemfireXD（Derby＋Gemfire＋HDFS）产品是支持标准的SQL95，支持distributed transaction的分布式内存数据库。也就是可以直接把RDBMS的表直接移植到SQLFire／GemfireXD。参考：http://gemfirexd.docs.pivotal.io/docs-gemfirexd/about_gemfirexd/topics/c_what_is_elasticsql.html

BDS_2.png

Q6：传统的数据库系统都会把内存作为缓存，查询的时候把数据加载到内存里面，同样的查询第二次访问比第一次要快很多，利用例如FBR、LRFU、ALRFU这类的算法来优化内存利用率。那么Gemfire同样把数据存在内存里面与传统的缓存在数据结构和算法上有什么优势吗？

A6：和传统的RDBMS的内存缓冲技术或则某些改善算法相比，Gemfire等内存数据库有本质的区别。Gemfire首先是share nothing的分布式的Key-Value(Object)的架构，再加上所有的数据都分布在内存上，读写数据，还有不同节点之间的数据同期交换速度都比RDBMS的速度上有质的飞越。基本上是随着node数量的增加Thoughput的性能是线性增长的。传统的RDBMS的内存缓冲技术只是在旧框架上的修修补补，没法达到分布式Key Value数据库的线性增长。

Q7：使用Greenplum时候遇到的一个内存问题报错如下：

VM protect failed to allocate 8388608 bytes from system, VM Protect 3398 MB available

SQL function "to_timestamp" statement 1

     报错就是因为系统内存不够产生吗？如果，GPDB如果在某个query运行的时候用完了所有的内存（存临时数据），GPDB引擎会有什么机制释放内存，存到磁盘上某个类似tempdb里面吗？如果配置的内存比实际内存多，就是GPDB以为有xx，系统实际上没有那么多内存可以用。那么你说的bug，在最新的版本中修复了吗？至少找4.4.2里面还有没有？那么4.3.3.1里面的bug是修复了吗？

A7：【gpdb】常见问题--out of memory

     Out of memory有两种，第一种是达到数据库gp_vmem_protect_limit；第二种是达到Linux内存限制，系统内存已耗尽。第一种情况在pg_log里会找到类似如下的消息  "VM Protect failed to allocate n bytes ..." 第二种情况在pg_log里会找到类似如下的消息   "VM Protect: failed to allocate memory from system" 你说的问题是第二种，包含“from system"的是第二种。通常这种情况不是系统内存不够，而是系统配置的问题，即配置的比实际的多，需要调整系统配置。gpdb会利用磁盘存放临时数据，如果是第一种类型的out of memory则是一个bug。Bug基本上是碰到一个修复一个，所以建议你及时更新数据库，保持最新状态，而且我们的更新是免费的。

第二种情况，这基本上是系统配置的问题，系统配置内存的比实际的内存要多。建议你配置的内存和实际物理内存一样大，然后给gpdb的内存为配置内存的80%。可以打开这个网页，里面有所有的gpdb 4.3.x 所有的Readme. http://gpdb.docs.pivotal.io/gpdb-436.html

Q8：有问题如何找售后？

A8：电话：877 477 4269，或者通过以下两种在线的方式开Case:

1)    发邮件到customer-service@pivotal.io

2)    到网站https://support.emc.com/servicecenter/createSR/，通过自助的方式开Case。

Q9：GPDB中的哪些表需要“VACUUM ANALYZE”

A9：有些系统view可以显示那些表需要"VACUUM ANALYZE"，这些view通过比较“实际的表的大小”和“经过计算的应该大小”，如果两个差别较大，则应该对其"VACUUM ANALYZE"。

gp_bloat_diag

  View "gp_toolkit.gp_bloat_diag"

   Column    |  Type   | Modifiers

-------------+---------+-----------

bdirelid    | oid     |              - OID

bdinspname  | name    |              - Schema name

bdirelname  | name    |              - Table name

bdirelpages | integer |              - Number of table pages

bdiexppages | numeric |              - Number of expected pages

bdidiag     | text    |              - Diagnostic: "no bloat"/"moderate bloat"/"significant bloat"

Example:

lpetrov=# select * from gp_toolkit.gp_bloat_diag;

bdirelid | bdinspname | bdirelname | bdirelpages | bdiexppages |                bdidiag             

----------+------------+------------+-------------+-------------+---------------------------------------

   353016 | public     | t1         |         978 |           1 | significant amount of bloat suspected

(1 row)

gp_bloat_expected_pages

lpetrov=# \d gp_toolkit.gp_bloat_expected_pages

View "gp_toolkit.gp_bloat_expected_pages"

   Column    |  Type   | Modifiers

-------------+---------+-----------

btdrelid    | oid     |             - OID

btdrelpages | integer |             - Number of table pages

btdexppages | numeric |             - Number of expected pages

Example:

lpetrov=# select * from gp_toolkit.gp_bloat_expected_pages where btdrelid = 't1'::regclass;

btdrelid | btdrelpages | btdexppages

----------+-------------+-------------

   353016 |         978 |           1

(1 row)

Q10：我想问一下，既然是开源的产品，那有没有官方教程可以参考下教大家自己搭一套测试环境的呀？比如我设想的过程是这样：搭环境 > 导数据 > 出结果 > 验证。类似OpenStack的DevStack一键安装的样子或者以Virtual Appliance的形式来提供就更好了。谢谢！

A10：您可以从这里下载PHD2.0的Single Node VM，PHD3.0的还没有正式发布：https://network.pivotal.io/products/pivotal-hd#/releases/148

     Gemfire的开源产品是Apache Geode，下面是官方的geode的document。至于virtual appliance，gemfire我们内部有提供预装的virtual appliance（基于gemfire8.1），里面包含了服务器自动配置，一键启动，简单就可以验证结果的。Apache Geode暂时还没有相关的virtual appliance提供。

http://geode-docs.cfapps.io/docs/getting_started/installation/install_standalone.html

https://cwiki.apache.org/confluence/display/GEODE/Building+and+Running+Geode+from+Source

Q11：能稍微详细介绍下HAWQ吗？比如他能实现什么功能，跟Hive/Hbase 有和区别？

A11：功能方面，hawq简单来说也是用于做数据分析的，这个和hive以及hbase比较相似。差异是他们的来源不同，hawq的基本框架是基于gpdb设计的，底层使用了hdfs做持久化存储。性能方面，hawq因为gpdb的原因，速度肯定比hive要快很多。gpdb是一个MPP架构的分布式关系数据库，在单个节点上还是使用传统的postgres数据库的模块。hbase和分布式关系数据库的使用范畴差异较大。

Q12：Pivotal BDS 这个可以理解为EMC自己的数据库呢？

A12：Pivotal BDS是EMC自己的数据库。Greenplum 数据库是EMC收购的，HAWQ数据库是EMC自己在Greenplum的基础上开发出来的，运行在HDFS文件系统上。

Q13：Hadoop集群中的Authentication和Authorization的区别是什么：

A13：企业级的应用里面，关于用户权限的认证和用户权限的管理是相当重要的两个方面。在基于hadoop的企业集群里面，解决方法相对简单并且不够灵活。Pivotal的hadoop套件里面使用了来自hortonworks的Knox和Ranger，同时配合Ambari界面，方便灵活的实现了权限的认证和管理。

1)    传统的Authentication 和Authorization方法

2)    基于Knox的Authentication 的架构

3)    基于Ranger的Authorization的架构


1）传统的Authentication 和Authorization方法

     其中传统的Authentication 和Authorization方法，在hadoop企业集群里面，传统的Authentication的方法是围绕Kerberos实现的，同时也继承了Unix用户管理的一些概念和功能。

BDS_3.png

     Kerberos 是基于ticket或者说token的一种用户认证方式，简单来说就是用户只需要输入一次密码，就能通过缓存在本地的ticket或者token来和认证服务器之间进行权限认证。这样的认证是纵向嵌入在hadoop对应模块（hdfs，yarn，hive等）的code里面的，所以一旦这样的rpc调用被触发，对应的认证过程就会被触发。Kerberos的使用会基于Unix的用户和组概念。以hawq master为例，我们先需要用kinit工具申请一个keytab文件，输入的参数还包括用户和域信息。

BDS_4.png

     Keytab文件创建完成以后，可以用klist工具列出当前机器cache中的Kerberos ticket文件。

BDS_5.png

     然后把对应的keytab文件配置到hadoop的配置文件或者hawq的配置文件里面并重启集群，这样就可以完成kerberos的配置工作。在集群需要认证工作的时候，就可以通过配置文件找到keytab，然后完成和Kerberos服务器KDC的认证功能。

BDS_6.png

     关于Authorization, hadoop的原生实现比较简单。基本就是使用Unix 里面关于用户，组，权限相关的概念。


2）基于Knox的Authentication 的架构

     Apache Knox 为企业级用户提供并扩展安全认证功能的网关。Knox简化了来自客户端的认证的管理，为多客户端多集群多认证方式提供了统一的解决方案。下图是一个Knox使用场景的简要模块图。

BDS_7.png

     和传统的认证方式比较，Knox的解决方案相当灵活。不仅可以覆盖传统的hadoop集群的用户认证方式，也能融合企业自己的或者远程的认证和管理方式。同时，面向不同类型的客户请求和不同类型的集群之间进行了解耦。目前Apache Knox集中在扩展Hadoop YARN 的API的支持，并且为开发者提供更友好的Knox API 供开发者二次开发。

BDS_8.png

Q14：既然有有GPDB,再發展HAWQ又是去模擬GPDB的原因是 ?是成本較低嗎? 若是在Data Warehouse用途  ,請問放 GPDB 或 HAWQ  其優缺點是 ? 那個較快?

A14：应用场景不同。GPDB应用在传统环境，访问传统的文件系统，HAWQ应用在Hadoop环境中，访问HDFS文件系统。如果当前应用已经部署在Hadoop上，建议选择HAWQ。

Q15：HAWQ放HDFS看起來容錯好了些，但空間使用多了些，,另外多了一層效能是否差了些? 這樣解讀對嗎 ? HAWQ access HDFS有透過mpp or map reduce方式在連嗎 (它其實有三份)? HAWQ可access 原本放在HDFS上的其它檔案嗎? 是否也是要用external table 方式access?

A15：HAWQ在读写文件时，确实会比GPDB要慢，因为需要访问HDFS。HAWQ使用一个叫做libhdfs的模块在读写HDFS，这个模块也是开源版本的一部分。HAWQ的数据只是使用HDFS来存储，如果要读取HDFS上面的数据，还是需要通过外表的方式来访问。

Q16：专家您好，Greenplum开源免费使用，这是不是意味着所有服务都是免费的，没有需要购买的产品？

A16：开源版本的license是免费的，不过技术支持的服务是要收费的。开源版本不需要付license的费用，不需要技术支持也不需要付费，源代码也是公开的。如果需要技术支持，需要付相应的服务费用。

Q17：GPDB中如何检查catalog?

A17：检查catalog的工具叫做gpcheckcat，运行起来很简单，例如：

  nohup $GPHOME/bin/lib/gpcheckcat -p 5432 -A > catalog.log &

"-p 5432"指的是数据库的端口号，根据需要更改成实际的值。

"-A“表示对所有数据库执行catalog检查，也可以用数据库名字代替"-A"来对某一个数据库检查。例如 ”nohup

$GPHOME/bin/lib/gpcheckcat -p 5432 postgres > catalog.log &“

则只检查postgres数据库。完整的语法如下：

Usage: gpcheckcat [] [dbname]

    -?

    -B parallel: number of worker threads

    -g dir     : generate SQL to rectify catalog corruption, put it in dir

    -p port    : DB port number

    -P passwd  : DB password

    -U uname   : DB User Name

    -v         : verbose

    -A         : all databases

    -S option  : shared table options (none, only)

    -O         : Online

    -l         : list all tests

    -R test    : run this particular test

    -C catname : run cross consistency, FK and ACL tests for this catalog table

     检查完成后，会产生两个report，一个是summary report，名字为catalog.log（由上述命令重定向产生），另一个是detailed report， 名字为/home/gpadmin/gpAdminLogs/gpcheckcat_YYYYMMDD.log。如果发现catalog有问题，请及时与gpdb技术支持联系，明确影响范围及确立解决方案。

Q18：GPDB中数据误删了怎么办？

A18：有时候误操作，数据被删掉了， 又没有备份，怎么办？

别着急，如果当前数据没有被覆盖，既没有vacuum也没有插入新的数据，这时候是有办法“读”出被误删的数据的。

下面有个例子：

initdb=# create table t1(c1 int);

NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'c1' as the Greenplum Database data distribution key for this table.

HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.

CREATE TABLE

Time: 543.777 ms

initdb=# insert into t1 values(1);

INSERT 0 1

Time: 631.421 ms

initdb=# delete from t1;

DELETE 1

Time: 19.859 ms

initdb=# select * from t1;

c1

----

(0 rows)

Time: 9.411 ms

initdb=# set gp_select_invisible=true;

SET

Time: 12.513 ms

initdb=# select * from t1;

c1

----

  1

(1 row)

Time: 10.739 ms

Q19：请问数据库的性能一般怎么检查呢？谢谢

A19：请问你想了解GPDB MPP数据库的性能检查还是其他的HAWQ或则Gemfire/GemfireXD的性能检查？如果是Gemfire/GemfireXD内存数据库的，我们有很多指标来确认当前整个Gemfire/GemfireXD的性能状况。客户可以通过VSD工具确认一些stats来判断一些性能状况。比如对客户端的响应速度getResponses，putResponses，WAN的queue的非同期速度batchesDistributed等等。我们还可以通过stats知道当前的CPU使用率，Memory的使用率，GC情况，是不是有Node掉线了，Node间的响应数据replyWaitTime等等。当然，我们也有Pulse在线监控GUI，它是通过收集Cluster的MBean的相关stats数据实时显示当前Cluster状况。希望这些信息对你有所帮助。


不同的性能问题有不同的检查方法还包括：

  • particular HW resource maxed out - this can be discovered using vmstat/iostat, dstat/netblast/gpcheckperf and sar.
  • resource utilization analysis
    • high CPU - check "vmstat", "top", pinpoint the processes that consume most cpu and then analyze the processes (pstack/strace) and database session these processes belong to
    • is some server swapping - verify via vmstat, free -m, sar, then find the processes using most memory (ps aux, etc.) and analyze processes/sessions
    • disk IO - read or write, check iostat -dx and whether IO is saturated for /data1 and /data2 (utilization 90-100%), find which process is doing high IO (strace: read()/write() and iomon utility)
    • network saturation - check dstat to see network load (dstat) and network errors (netstat -i), look for processes doing motions and analyze accordingly. Check also if firewall is running (iptables).
  • analyze problematic processes and check what are they doing
    • ps aux - look at ps output and see the proceses, memory allocated, etc.
    • pstack - look for clues in the process stack that will show what the process is doing at the moment, cross check with the statement running in the database session
    • strace - look for resource related system calls (read()/write(), send()/recv())
    • gdb - deeper process analysis
    • gcore - if necessary to get a "snapshot" of a process for further analysis by Dev. team
  • catalog issues
    • check whether catalog statistics are good
    • check for catalog bloat
  • user tables
    • check whether statistics are good
    • one reason for missing/disappearing statistics can be autovacuum running in the background (versions before 4.2.5) - grep master log file for "autovac" and verify age(datfrozenxid) in pg_database
    • check for bloat (heap tables only)
    • check for table skew
    • check whether there are multiple AOCO partitioned tables - this may lead to too many files in the database directory, in which case the FS operations are very slow on FS level
    • check for improper object usage - example: huge insert in a table that has index(es) defined - will be slow because of the index maintenance that happens for every row inserted. In this case it is better to do the insert without indexes and create them after the load.  
  • query plan issues
    • understand objects involved (tables, indexes, etc.)
    • analyze explain output
    • analyze explain analyze output (if possible to get one)
    • verify statistics - bad statistics can lead to a bad plan
    • verify bloat - bloat can lead to slow table scans
    • verify whether spilling is happening - look for pgsql_tmp/ directories under /base/ and their contents
    • look for processing skew
    • look for other issues in the plan
    • if necessary to collect information for in-house plan analysis, make sure to collect: cluster information, database version, gpsd output, exact query text, explain/explain analyze, sample data (if possible)
  • OS/HW issues
    • I/O - controller has disabled cache (Cache has Writethrough policy) because of battery issues - use provided storage tools
    • Applications - maintenance tasks ongoing (Patrol activity, etc.) - use provided storage tools to verify
    • Network - network controller issues, network configuration (ip addresses, hostnames, routing), firewall running (iptables), switch issues (switch log)
    • verify OS log file ("/var/log/messages")

Q20：Greenplum是否支持表级别的数据恢复。比如我想把一张表恢复到三小时前的状态，是否可行？

A20：Greenplum支持表级别的数据恢复。gpdbrestore -T table_name就可以实现。如果有这张表三个小时前的备份，是可以恢复的。

Q21：GPDB如何升级？

A21：数据库升级分两种情况，一种是小版本升级，另一种是大版本升级。

小版本升级比较简单，升级过程只是把binary换成新的就可以了，时间最多花1个小时。例如，greenplum database从4.3.0升级到4.3.5，就是小版本升级，直接把/usr/local/greenplum-db的软连接只相greenplum database 4.3.5 binary就可以了。

大版本升级比较复杂，时间久，过程多。例如，greenplum database从4.2.0升级到4.3.0，就是大版本升级。升级前需要做一系列的检查，例如catalog检查，mirror的状态等。检查完后，需要一个较长的时间窗口完成升级主过程，主要包括append only表转换，catalog表转换等

Q22：GPDB中的数据限制是怎么样的？

A22：下表列出了GPDB中的主要限制：

                                     

Dimension

Limit

Maximum size for a database?

unlimited

Maximum size for a table?

unlimited, 128 TB per   partition per segment

Maximum size for a row?

>1 GB (approximate)

Maximum size for a field?

1 GB

Maximum BLOB size

1 GB (Use BYTEA datatype, we   don't have BLOB)

Maximum number of rows in a   table?

2^48

Maximum number of columns in a   table?

1600

Maximum number of indexes on a   table?

unlimited

Maximum number of   databases/users

unlimited

Maximum number of tables per   database

4200 million

Maximum number of columns per   View

unlimited

Maximum length of   column/table/database name

63

Maximum number of columns per   index

unlimited

Maximum number of table level   constraints per table

unlimited

Maximum active concurrent   transactions

unlimited

Maximum data format descriptor   size

63 characters

Maximum database, user, base   table, view, index, trigger, stored procedure, UDF, UDT, constraint or column   name size.

63 characters

Maximum sessions per parsing   engine

No concept of parsing engine   other than masterDB node. No fixed limit, up to a few hundred.

Maximum columns per primary   and secondary index

32

Q23：GPDB节点不同步怎么办？

A23：如果是segment节点不同步，可以运行gprecoverseg来恢复宕机节点。

如果是standby master节点不同步，需要先删除standby master，然后再重新添加进来。删除的命令是“gpinitstandby -r”，重新添加的命令是"gpinitstandby -s standby_master_host_name"

检查segment节点的命令”gpstate -e“：

[gpadmin@mdw tmp]$ gpstate -e

20151106:12:47:55:088663 gpstate:mdw:gpadmin-[INFO]:-Starting gpstate with args: -e

20151106:12:47:55:088663 gpstate:mdw:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.6.1 build 2'

20151106:12:47:55:088663 gpstate:mdw:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.6.1 build 2) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Oct  1 2015 15:14:22'

20151106:12:47:55:088663 gpstate:mdw:gpadmin-[INFO]:-Obtaining Segment details from master...

20151106:12:47:55:088663 gpstate:mdw:gpadmin-[INFO]:-Gathering data from segments...

..

20151106:12:47:57:088663 gpstate:mdw:gpadmin-[INFO]:-----------------------------------------------------

20151106:12:47:57:088663 gpstate:mdw:gpadmin-[INFO]:-Segment Mirroring Status Report

20151106:12:47:57:088663 gpstate:mdw:gpadmin-[INFO]:-----------------------------------------------------

20151106:12:47:57:088663 gpstate:mdw:gpadmin-[INFO]:-All segments are running normally

检查standby master节点的命令式"gpstate -f"：

[gpadmin@mdw ~]$ gpstate -f

20151105:19:46:39:546399 gpstate:mdw:gpadmin-[INFO]:-Starting gpstate with args: -f

20151105:19:46:39:546399 gpstate:mdw:gpadmin-[INFO]:-local Greenplum Version: 'postgres (Greenplum Database) 4.3.6.1 build 2'

20151105:19:46:39:546399 gpstate:mdw:gpadmin-[INFO]:-master Greenplum Version: 'PostgreSQL 8.2.15 (Greenplum Database 4.3.6.1 build 2) on x86_64-unknown-linux-gnu, compiled by GCC gcc (GCC) 4.4.2 compiled on Oct  1 2015 15:14:22'

20151105:19:46:39:546399 gpstate:mdw:gpadmin-[INFO]:-Obtaining Segment details from master...

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-Standby master details

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-----------------------

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-   Standby address          = smdw

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-   Standby data directory   = /data/master/gpseg-1

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-   Standby port             = 5432

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-   Standby PID              = 274061

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:-   Standby status           = Standby host passive

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--------------------------------------------------------------

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--pg_stat_replication

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--------------------------------------------------------------

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--WAL Sender State: streaming

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--Sync state: sync

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--Sent Location: 0/591FFA78

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--Flush Location: 0/591FFA78

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--Replay Location: 0/591FFA78

20151105:19:46:40:546399 gpstate:mdw:gpadmin-[INFO]:--------------------------------------------------------------


参考

Pivotal Greenplum产品下载：https://network.pivotal.io/products/pivotal-gpdb

Pivotal Greenplum产品文档：http://gpdb.docs.pivotal.io/gpdb-436.html

Pivotal试用产品下载：https://network.pivotal.io/

Greenplum源代码：https://github.com/greenplum-db/gpdb

Pivotal BDS产品服务支持时间：http://d1fto35gcfffzn.cloudfront.net/support/PivotalLifecycleMatrix.pdf

应用于

Pivotal BDS

             

没有回复！

查看更多

查看全部

找不到事件！

Top