我正在学习Greenplum并设置了一个小型集群进行测试（一个主节点，三个节段主机）。
我在没有镜像的情况下初始化了集群，后来又使用gpaddmirrors启用了它。但是，所有镜像在gpstate中显示为Down，并且在段主机上运行gp_primarymirror命令只是挂起（这是gprecoverseg运行的命令）
gpadmin 2695 1 0 06:21 ? 00:00:00 /usr/local/greenplum-db-4.3.8.1/bin/postgres -D /data/primary/gpseg2 -p 40002 -b 4 -z 9 --silent-mode=true -i -M quiescent -C 2
gpadmin 2698 2695 0 06:21 ? 00:00:00 postgres: port 40002, logger process
gpadmin 2706 2695 0 06:21 ? 00:00:00 postgres: port 40002, primary process
gpadmin 2709 2706 0 06:21 ? 00:00:00 postgres: port 40002, primary recovery process
gpadmin 2719 2695 0 06:21 ? 00:00:00 postgres: port 40002, stats collector process
gpadmin 2720 2695 0 06:21 ? 00:00:00 postgres: port 40002, writer process
gpadmin 2721 2695 0 06:21 ? 00:00:00 postgres: port 40002, checkpoint process
gpadmin 2722 2695 0 06:21 ? 00:00:00 postgres: port 40002, sweeper process
gpadmin 2901 2207 0 06:29 pts/0 00:00:00 grep --color=auto 40002
gpadmin@gpseg02:~> gp_primarymirror -h gpseg02 -p 40002
最后一个命令只是挂起而且永远不会结束。
知道我做错了什么吗？
更新＃1：
gprecoverseg -v输出（没有-v它只是打印“无法连接到数据库”）：
20160502:06:24:28:023062 gprecoverseg:gpmaster02:gpadmin-[DEBUG]:-[worker8] finished cmd: Get segment status cmdStr='ssh -o 'StrictHostKeyChecking no' gpseg03 ". /usr/local/greenplum-db/./greenplum_path.sh; $GPHOME/bin/gp_primarymirror -h gpseg03 -p 40002"' had result: cmd had rc=1 completed=True halted=False
stdout=''
stderr='Welcome to SUSE Linux Enterprise Server 12.
mode: PrimarySegment
segmentState: ChangeTrackingDisabled
dataState: InChangeTracking
faultType: NotInitialized
mode: PrimarySegment
segmentState: ChangeTrackingDisabled
dataState: InChangeTracking
faultType: NotInitialized
gp_segment_configuration输出：
testdb=# select * from gp_segment_configuration;
dbid | content | role | preferred_role | mode | status | port | hostname | address | replication_port | san_mounts
------+---------+------+----------------+------+--------+-------+----------------------------+----------------------------+------------------+------------
1 | -1 | p | p | s | u | 5432 | gpmaster02 | gpmaster02 | |
2 | 0 | p | p | c | u | 40000 | gpseg02 | gpseg02 | 43000 |
11 | 0 | m | m | r | d | 41000 | gpseg03 | gpseg03 | 42000 |
3 | 1 | p | p | c | u | 40001 | gpseg02 | gpseg02 | 43001 |
12 | 1 | m | m | r | d | 41001 | gpseg03 | gpseg03 | 42001 |
4 | 2 | p | p | c | u | 40002 | gpseg02 | gpseg02 | 43002 |
13 | 2 | m | m | r | d | 41002 | gpseg03 | gpseg03 | 42002 |
5 | 3 | p | p | c | u | 40000 | gpseg04 | gpseg04 | 43000 |
17 | 3 | m | m | r | d | 41000 | gpseg02 | gpseg02 | 42000 |
6 | 4 | p | p | c | u | 40001 | gpseg04 | gpseg04 | 43001 |
18 | 4 | m | m | r | d | 41001 | gpseg02 | gpseg02 | 42001 |
7 | 5 | p | p | c | u | 40002 | gpseg04 | gpseg04 | 43002 |
19 | 5 | m | m | r | d | 41002 | gpseg02 | gpseg02 | 42002 |
8 | 6 | p | p | c | u | 40000 | gpseg03 | gpseg03 | 43000 |
14 | 6 | m | m | r | d | 41000 | gpseg04 | gpseg04 | 42000 |
9 | 7 | p | p | c | u | 40001 | gpseg03 | gpseg03 | 43001 |
15 | 7 | m | m | r | d | 41001 | gpseg04 | gpseg04 | 42001 |
10 | 8 | p | p | c | u | 40002 | gpseg03 | gpseg03 | 43002 |
16 | 8 | m | m | r | d | 41002 | gpseg04 | gpseg04 | 42002 |
答案 0 :(得分：3)
这通常意味着更改跟踪日志存在问题。
尝试以下方法：
可能还有其他细分受损的日志记录。如果上述步骤不起作用，则停止数据库并删除所有段的pg_changetracking。
答案 1 :(得分：0)
我在过去遇到过同样的问题，我在以管理员模式登录数据库后尝试使用gprecoverseg，并且它可以工作 请尝试这一步