首先，您可以使用gpstate工具检查集群中所有节点的状态。执行gpstate -e可以查看是否有segment节点处于down状态，如果有，这将帮助您确定是否有节点因为宕机而导致数据库无法正常运作。

接下来，您需要分析日志文件来确定宕机的原因。Greenplum的日志文件通常位于$MASTER_DATA_DIRECTORY/pg_log目录下，您可以通过查看这里的日志来获取错误信息和警告。此外，您还可以使用gpssh工具登录到所有服务器检查postgres进程数，确认是否还有进程在运行。

如果发现有大量进程卡在pg_stat_activity中，您可以直接通过ps命令结合grep查找相关进程，并使用kill命令配合进程ID（PID）来结束这些进程。不过，请确保这样做不会影响到数据库的正常恢复流程。

如果节点宕机是由于硬件故障，您可能需要重启服务器，并使用gprecoverseg工具来恢复失败的segment实例。在执行gprecoverseg之前，请确保已经收集了足够的日志信息，这些信息将帮助您在恢复过程中诊断和解决问题。

记得在进行任何操作之前备份重要数据，以防恢复过程中出现意外导致数据丢失。

问题已解决，根据pid查找后台进程，是在等待已经恢复的mirror的seg，停掉mirror后，死锁进程自动释放。然后恢复primary,最后再恢复mirror就可以了。