PostgreSQL Replication之第八章 与pgbouncer一起工作（3）

8.3 配置您的第一个pgbouncer设置

一旦我们已经完成了pbouncer的编译与安装，我们可以容易地启动它。要做到这一点，我们已经在一个本地实例(p0和p1) 建立了两个数据库。在本例中，执行设置的想法是使用pgbouncer作为代理。

8.3.1 写一个简单的配置文件并启动pgbouncer

为了使pgbouncer工作，我们可以写一个简单的配置文件，它可以被添加到pgboucner：

[databases]

p0 = host=localhost dbname=p0

p1 = host=localhost dbname=p1

[pgbouncer]

logfile = /var/log/pgbouncer.log

pidfile = /var/log/pgbouncer.pid

listen_addr = 127.0.0.1

listen_port = 6432

auth_type = trust

auth_file = /etc/pgbouncer/userlist.txt

pool_mode = session

server_reset_query = DISCARD ALL

max_client_conn = 100

default_pool_size = 20

此处不需要使用相同的数据库名。您可以把任何数据库名映射到任何连接字符串。我们已经发现了使用相同的名字的很有用。

一旦我们写完了这个配置文件，我们可以放心地启动pgbouncer看看会发生什么：

hs@iMac:/etc$ pgbouncer bouncer.ini

2013-04-25 17:57:15.992 22550 LOG File descriptor limit: 1024 (H:4096),

max_client_conn: 100, max fds possible: 150

2013-04-25 17:57:15.994 22550 LOG listening on 127.0.0.1:6432

2013-04-25 17:57:15.994 22550 LOG listening on unix:/tmp/.s.PGSQL.6432

2013-04-25 17:57:15.995 22550 LOG process up: pgbouncer 1.5.4, libevent

2.0.16-stable (epoll), adns: evdns2

在生产环境中，您会先配置身份验证，但是，让我们一步一步地做。

调度请求

当处理pgbouncer时，我们首先要配置的是我们要连接的数据库服务器的配置。在我们的例子中，我们简单地创建了p0和p1的连接。我们把连接字符串放到数据库服务器的配置中，该连接字符串告诉pgbouncer连接到哪里。由于pgbouncer本质上是某种代理的端口，我们也可以映射连接来使事情变得更加灵活。在这个种情况下，映射意味着保持数据的数据库不一定要和通过pgbouncer展示的虚拟数据库具有相同的名字。

下面的连接参数是允许的：dbname, host, port, user, password,client_encoding, datestyle, timezone, pool_size, and connect_query。所有的密码是在任何PostgreSQL连接串中您将会用到的。 其余的用来调整pgbouncer以适应您的需要。这里最重要的设置是池的大小，它定义了到这个特殊的pbouncer虚拟数据库所允许的连接的最大数目。

注意，池的大小和连接的PostgreSQL的连接数是不相关的。可以有不止一个挂起的到pgbouncer的连接等待到PostgreSQL的连接。

这里重要的事情是，您可以使用pgbouncer转发到许多不同的主机上的不同的数据库—没有必要所有的数据库都在相同的主机上，所以pgbouncer也可以帮助您集中化您的网络配置。

请注意，我们使用不同的密码连接到pgbouncer—因为所有的连接都在连接池里，我们不对PostgreSQL本身进行身份验证。

最后，我们可以配置一个connect_query选项。使用此设置我们可以定义个查询，只要连接被传递到应用程序该查询必须被执行。这有什么好处？您可能需要设置您的数据库中的一些变量，清除或者直接简单地改变一些运行时参数。有时，您不需要列出所有的数据库连接。尤其是有好多数据库，则可以派上用场。这个想法是直接列出所有之前没有被列出的请求到后备服务器：

* = host=fallbackserver

到p0和p1的连接将如前被处理—其它一切连接都会连接到后备连接字符串。

更基本的设置

在我们的例子中，pgbouncer将会监听6432端口。我们设置listen_addr 为127.0.0.1，所以现在，只允许本地连接。基本上listen_addr的作用就像postgresql.conf中的listen_addresses的作用一样。我们可以定义监听什么IP地址。

[在大多数情况下，您可能想给listen_addr使用*，因为您可能想把所有的网卡考虑在内。]

在我们的设置中，pgbouncer将会产生相当数量的日志条目。为了把这些日志写入到一个日志文件中，我们已经使用了我们配置文件中日志文件指令。强烈建议写日志文件，以确保您可以监测您的bouncer中的所有相关事情。

身份验证

一旦我们已经配置了我们的数据库和其它的基本设置，我们可以把我们的注意力转到身份验证了。正如您已经看到的，这个地方的配置连到(显示)您设置的数据库。所有的应用程序将指向pgbouncer，因此所有的身份验证相关的东西实际上将门卫处理。它是如何工作的呢？pgbouncer接受PostgreSQL支持的相同的身份验证方法，例如mmd5(auth_file可能包含md5加密文件)，crypt(auth_file中的普通的文本密码)，plain(清晰的文本密码)，trust(没有身份验证)和any(和trust很像，但是忽略用户名)。

auth_file文件本身有一个简单的格式：

"hs" "15359fe57eb03432bf5ab838e5a7c24f"

"zb" "15359fe57eb03432bf5ab838e5a7c24f"

第一列包含用户名，然后是一个tab，最后是一个普通的文本字符串或者一个md5加密的密码。

8.3.2 pgbouncer的连接

一旦我们写完了这个基本的配置并启动系统，我们可以安全地连接到列出的数据库中的一个数据库：

hs@iMac:~$ psql -p 6432 p1 -U hs

psql (9.2.4)

Type "help" for help.

p1=#

在我们的例子当中，我们正连接到我们自己的名为p1的数据库。我们可以看到，shell已经正常地打开了，我们可以继续，并发出我们想要的SQL，就好像我们是连接到一个正常的数据库。

日志文件也将反应我们连接到数据库的工作和状态：

2013-04-25 18:10:34.830 22598 LOG C-0xbca010: p1/hs@unix:6432 login

attempt: db=p1 user=hs

2013-04-25 18:10:34.830 22598 LOG S-0xbe79c0: p1/hs@127.0.0.1:5432 new

connection to server

对于每一个连接，我们得到各种日志条目，以便系统管理员可以很容易地坚持正在发生什么事情。

Java问题

如果您碰巧使用Java作为前端，有几点必须要考虑。Java往往把一些参数传递给服务器作为连接字符串。其中一个参数是extra_float_digits。这个postgresql.conf的参数管理PostgreSQL的浮点行为，它通过Java设置以确保事情更加确定。

问题是，pgbouncer将只会接受在前小节列出来的参数—否则将会报错。

为了解决这个问题，您可以添加一个指令到您的bouncer 配置文件(pgbouncer文件部分):

ignore_startup_parameters = extra_float_digits

这将忽略JDBC设置，并允许pgbouncer正常地处理连接。如果您想使用Java，我们建议直接把这些参数放到postgresql.conf中以确保在生产环境中不会弹出讨厌的问题。

8.3.3 池模式

在配置文件中，您一定也看到了一个叫名字为pool_mode的配置变量，它还没有被描述过。其原因是，池模式是如此的重要，以至于我们准备了一整节来描述它。

一般来说，有三种不同的池模式可供选择：

• 会话

• 事务

• 语句

会话模式是pgbouncer的默认模式。只要应用程序从 bouncer 断开连接，连接就会返回到池中。在许多情况下，这是所期望的模式，因为我们只想节省连接开销—仅此而已。然而，在某些情况下，快速地把会话返回到池中可能是非常有用的。如果不同的事务之间存在滞后，这是尤其重要的。在事务模式下，当事务结束时(而不是当连接结束时)，pgbouncer将会立即把一个连接返回到池中。这样做的优点是，我们仍然可以使用事务的好处，但是，连接被返回的更迅速了，因此，我们可以更加有效地使用那些打开的连接。对于大多数web应用程序来说，这可能是一个很大的优势，因为一个会话的生命是非常短的。

第三池模式，在语句结束时，语句允许我们立即返回一个连接。这是一个非常积极的设置，它基本上，被设置用来提供高并发的设置，其中的事务一点都不相关。为了确保在这个设置中任何事情都不出错，跨越一条语句以上的长事务是不允许的。

大多数人在这里会坚持默认的模式，但是，您必须记住，其它的模式也存在。

8.3.4 清理问题

在PostgreSQL调用fork()之后，一个干净，而且新生的连接的一个优势是，事实上，那个连接不包含任何不完善的设置，任何打开的游标，或者无论任何其它的遗留。这使得一个新的连接使用起来安全，并且避免其它连接的负面影响。

正如您已经在本章学习的，pgbouncer将会重新使用连接来避免这些fork()调用。现在问题是，“ 我们如何确保一些连接不会遭受由其它一些连接引起的副作用呢？”

这个问题的答案是 server_reset_query ：无论什么时候一个连接返回到池中，pgbouncer能够运行一个查询或者设计的一组查询来清理您的数据库连接。这可以是任何基本的查询。实际上，设置它已经证明调用DISCARD ALL是明智的。DISCARD ALL是PostgreSQL的一个指令，它被设计通过关闭所有的游标，重置参数等等，来清理一个已经存在的连接。DISCARD ALL之后，连接和调用fork()之后一样新，并且可以安全地被一个未来的请求重新使用。

请记住，在一个连接返回到池之前或它被从池中获取之后，没有必要运行一个明确的ROLLBACK。pgbouncer已经自动做了事务回滚，因此，您可以完全肯定一个连接绝不会在一个事务内部。