如何确保准备和执行之间的数据库（Postgres）连接仍然存在？

Question

我有一个在 while 循环中永远运行的守护程序脚本。我有一个准备好的语句，这个语句在每个循环中执行。

例子：

  my $dbh;
  sub get_dbh {
      return DBI->connect(...);
  }

  my $dbh = get_dbh();
  my $sth = $dbh->prepare("SELECT ....") or die $DBI::errstr;

  while (1) {
      // is connection still there??
      //if (!$dbh->ping) {
      //    $dbh = get_dbh();
      //}

      $sth->execute('param1');

      // do some other things ... sleep between 0 and 3600
  }

如果准备好的语句在几个小时前准备好，就会出现（或可能出现）问题。连接可能会死，我也会执行。在每次执行之前检查 $dbh->ping 看起来有点过头了。

MySQL 支持真正有效的 mysql_auto_reconnect。 DBD::Pg 没有这样的东西。我读过 DBI::Apache 但我看到它依赖于 mod_perl 等。它显然适用于 Web 应用程序。

是否有“最佳实践”方法来检查连接状态并在需要时重新连接？#

我可以在每个循环上准备语句，但这不是解决方案，而是解决问题的一种方法。

Answer 1

我不明白你为什么说每个execute 之前的ping 是多余的，但替代方法是显式处理execute 失败的情况，因为数据库句柄通过重新连接无效，准备声明，并再次发出execute。这会稍微快一点，但我认为没有理由避免使用ping 策略

Answer 2

是否有“最佳实践”方法来检查连接状态并在需要时重新连接？#

是的，至少在我看来，因为只有一种方法没有竞争条件，那就是在重试循环中执行查询，以便在出现错误时进行处理。

否则你还有：

1. PREPARE
2. SELECT 1; 或任何你的测试语句
3. 网络中断、后端崩溃、管理员重启服务器等
4. EXECUTE
5. splat.

正确的行为需要类似伪代码的东西：

while not succeeded:
    try:
        execute_statement()
        succeeded = True
    except some_database_exception:
        if transaction_is_valid():
            // a `SELECT 1` or `select 1 from pg_prepared_statements where name = 'blah'
            // succeeded in transaction_is_valid(), so the issue was probably
            // transient. Retry, possibly with a retry counter that resets the 
            // connection if more than a certain number of retries.
            // It can also be useful to examine the exception or error state to 
            // see if the error is recoverable so you don't do things like retry
            // repeatedly for a transaction that's in the error state.
        else if test_connection_usable_after_rollback():
            // Connection is OK but transaction is invalid. You might determine
            // this from the exception state or by seeing if sending a `ROLLBACK`
            // succeeds. In this case you don't have to re-prepare, just open
            // a new transaction. This case is not needed if you're using autocommit.
        else:
            // If you tried a SELECT 1; and a ROLLBACK and neither succeeded, or
            // the exception state suggests the connection is dead. Re-establish
            // it, re-prepare, and restart the last transaction from the beginning.
            reset_connection_and_re_prepare()

冗长而烦人？是的，但通常很容易包装在助手或库中。其他一切仍受制于种族。

最重要的是，如果您的应用程序在执行不止一件事的情况下发出事务，则它需要记住在事务提交之前所做的所有事情，并且能够在出现错误时重试整个事务。或者告诉用户“哎呀，我吃掉了你的数据，请重新输入并重试”。

如果您不介意比赛并且只想通过定期检查来处理任何明显失效的连接，只需将最后一次查询的时间存储在变量中即可。发出查询时，检查时间戳是否超过几分钟，如果是，发出SELECT 1; 或针对pg_prepared_statements 的查询以检查您准备好的语句。您要么需要准备好向用户吐出错误，要么将整个事情包装在适当的错误处理中......在这种情况下，根本没有必要进行时间检查和测试。

Answer 3

当您知道您可能会让连接闲置 一小时时，ping/测试连接是非常合理的。

更好的是，DBI 的 connect_cached 和 prepare_cached 使这相对容易：

while (1) {
    my $dbh = DBI->connect_cached(..., { RaiseError => 1 });  # This will ping() for you
    my $sth = $dbh->prepare_cached('SELECT ...');

    $sth->execute('param1');

    # Do work, sleep up to 1 hour
}

通过这种方式，您将在连接的整个生命周期内重复使用相同的准备好的语句。

（值得一提的是，现代 DBD::Pg ping 是通过高效的原生 PostgreSQL 调用实现的。）