常见问题处理

    • 在连接上数据库，通过“show log_hostname”语句，检查数据库中是否开启了log_hostname参数。

      如果开启了相关参数，那么数据库内核会通过DNS反查客户端所在机器的主机名。这时如果数据库配置了不正确的/不可达的DNS服务器，那么会导致数据库建立连接过程较慢。此参数的更多信息，详见《数据库参考》中“GUC参数说明 > 错误报告和日志 > 记录日志的内容”章节中关于“log_hostname”的描述。

    • 数据库内核执行初始化语句较慢导致的性能问题。

      此种情况定位较难，可以尝试使用Linux的跟踪命令：strace。

      此时便会在屏幕上打印出数据库的连接过程。比如较长时间停留在下面的操作上：

      sendto(3, "Q\0\0\0\25SELECT VERSION()\0", 22, MSG_NOSIGNAL, NULL, 0) = 22 poll([{fd=3, events=POLLIN|POLLERR}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])

      此时便可以确定是数据库执行”SELECT VERSION()“语句较慢。

      在连接上数据库后，便可以通过执行“explain performance select version()”语句来确定初始化语句执行较慢的原因。更多信息，详见《性能调优指南》中“SQL调优指南 > SQL执行计划介绍”章节。

      另外还有一种场景不太常见：由于DN所在机器的磁盘满或故障，此时所查询等受影响，无法进行用户认证，导致连接过程挂起，表现为假死。解决此问题清理DN的数据盘空间便可。

    • TCP连接创建较慢问题。

      此问题可以参考上面的初始化语句较慢排查的做法，通过strace跟踪，如果长时间停留在：

      connect(3, {sa_family=AF_FILE, path="/home/test/tmp/gaussdb_llt1/.s.PGSQL.61052"}, 110) = 0

      或者

      connect(3, {sa_family=AF_INET, sin_port=htons(61052), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)

      那么说明客户端与数据库端建立物理连接过慢，此时应当检查网络是否存在不稳定、网络吞吐量太大的问题。

    • gsql: could not connect to server: No route to host

      此问题一般是指定了不可达的地址或者端口导致的。请检查-h参数与-p参数是否添加正确。

    • gsql: FATAL: Forbid remote connection with trust method!

      数据库由于安全问题，禁止远程登录时使用trust模式。这时需要修改pg_hba.conf里的连接认证信息。具体的设置信息请参见：《数据库管理指南》中“管理数据库安全 > 客户端接入认证 > 配置文件参考”章节。

    • 在DN连接数据库，添加“-h 127.0.0.1”可以连接，去掉后无法连接问题。

      通过执行SQL语句“show unix_socket_directory”检查DN使用的Unix套接字目录，是否与shell中的环境变量$PGHOST一致。

      如果检查结果不一致，那么修改PGHOST环境变量到GUC参数unix_socket_directory指向的目录便可。

      关于unix_socket_directory的更多信息，详见《数据库参考》中“GUC参数说明 > 连接和认证 > 连接设置”章节中的说明。

    • 此问题是由于环境中使用的libpq.so的版本与gsql的版本不匹配导致的，请通过“ldd gsql”命令确认当前加载的libpq.so的版本，并通过修改LD_LIBRARY_PATH环境变量来加载正确的libpq.so。

    • gsql: symbol lookup error: xxx/gsql: undefined symbol: libpqVersionString

      此问题是由于环境中使用的libpq.so的版本与gsql的版本不匹配导致的（也有可能是环境中存在PostgreSQL的libpq.so），请通过“ldd gsql”命令确认当前加载的libpq.so的版本，并通过修改LD_LIBRARY_PATH环境变量来加载正确的libpq.so。

    • gsql: connect to server failed: Connection timed out

      Is the server running on host “xx.xxx.xxx.xxx” and accepting TCP/IP connections on port xxxx?

      此问题是由于网络连接故障造成。请检查客户端与数据库服务器间的网络连接。如果发现从客户端无法PING到数据库服务器端，则说明网络连接出现故障。请联系网络管理人员排查解决。

    • gsql: FATAL: permission denied for database “postgres”

      DETAIL: User does not have CONNECT privilege.

      此问题是由于用户不具备访问该数据库的权限，可以使用如下方法解决。

      1. 使用管理员用户dbadmin连接数据库。

        gsql -d postgres -U dbadmin -p 8000

    • gsql: FATAL: sorry, too many clients already，active/non-active: 197/3.

      此问题是由于系统连接数量超过了最大连接数量。请联系数据库DBA进行会话连接数管理，释放无用会话。

      关于查看用户会话连接数的方法如表1。

      会话状态可以在视图PG_STAT_ACTIVITY中查看。无用会话可以使用函数pg_terminate_backend进行释放。

      select datid,pid,state from pg_stat_activity;

      其中pid的值即为该会话的线程ID。根据线程ID结束会话。

      SELECT PG_TERMINATE_BACKEND(139834759993104);

      显示类似如下信息，表示结束会话成功。

      PG_TERMINATE_BACKEND ---------------------- t (1 row)

      表 1 查看会话连接数

    • gsql: wait xxx.xxx.xxx.xxx:xxxx timeout expired

      gsql在向数据库发起连接的时候，会有5分钟超时机制，如果在这个超时时间内，数据库未能正常的对客户端请求进行校验和身份认证，那么gsql会退出当前会话的连接过程，并报出如上错误。

      一般来说，此问题是由于连接时使用的-h参数及-p参数指定的连接主机及端口有误（即错误信息中的xxx部分），导致通信故障；极少数情况是网络故障导致。要排除此问题，请检查数据库的主机名及端口是否正确。

    • gsql: could not receive data from server: Connection reset by peer.

      同时，检查DN日志中出现类似如下日志“ FATAL: cipher file “/data/coordinator/server.key.cipher” has group or world access”，一般是由于数据目录或部分关键文件的权限被误操作篡改导致。请参照其他正常实例下的相关文件权限，修改回来便可。

    • gsql: FATAL: GSS authentication method is not allowed because XXXX user password is not disabled.

      目标DN的pg_hba.conf里配置了当前客户端IP使用”gss”方式来做认证，该认证算法不支持用作客户端的身份认证，请修改到”sha256”后再试。配置方法见《数据库管理指南》中“管理数据库安全 > 客户端接入认证 > 配置文件参考”章节 。

      说明：

      • 请不要修改pg_hba.conf中数据库主机的相关设置，否则可能导致数据库功能故障。
      • 建议业务应用部署在数据库之外，而非数据库内部。