- Session pooling/會話連接池
最禮貌的方法。在客戶端連接的時候，在它的連接生命期內，會給它賦予一個服務器連接。在客戶端斷開的時候，服務器連接會放回到連接池中。 - Transaction pooling/事務連接池
服務器連接只有在一個事務裡的時候才賦予客戶端。在 PgBouncer 注意到事務結束的時候，服務器將會放回連接池中。這是一個 hack，因為它打破了應用對後段連接的看法。只有在應用配合這樣的使用模式，沒有使用會破壞這種使用模式的時候才能用這個連接方式。參閱下標獲取會破壞 這種模式的特性。 - Statement pooling/語句連接池
最激進的模式。這是事務連接池的一個扭曲的變種 - 不允許多語句的事務。這就意味著是在客戶端強制“autocomit”模式，主要是給 PL/Proxy 用的。
setting in Ubuntu 12.04
- 安裝：sudo apt-get install pgbouncer
- 設定檔：位於/etc/pgbouncer資料夾下，pgbouncer.ini為主要設定檔，userlist.txt為可連線的使用者(在 pgbounce.ini中指定)。
- man pgbouncer可以看到manaul中提供的一個簡單配置的例子 。 [databases]
pg_template1 = host=127.0.0.1 dbname=template1
[pgbouncer]
pool_mode = session
listen_port = 6543
listen_addr = 127.0.0.1
auth_type = md5
auth_file = users.txt
logfile = pgbouncer.log
pidfile = pgbouncer.pid
admin_users = someuser
stats_users = stat_collector
- 上面的配置說明了該pgbouncer創建了針對127.0.0.1上的template1的一個連接池，該連接池對調用方的呈現的資料庫名稱是pg_template1,它映射到了template1上。所有訪問pbbouncer上的pg_template1的請求都會轉到template1上完成。
- pool_mode 指明了連接池的模型，pgbouncer目前支援三種連接池模型。分別是session, transaction和statment三個級別。
- a. session. 會話級連結。只有與當用戶端的會話結束時，pgbouncer才會收回已分配的連結
- b. transaction 事務級連接。當事務完成後，pgbouncer會回收已分配的連結。也就是說用戶端只是在事務中才能獨佔此連結，非事務的對資料庫的請求是沒有獨享的連結的。
- c. statement 語句級連結。任何對資料庫的請求完成後，pgbouncer都會回收連結。此種模式下，用戶端不能使用事務，否則會造成資料的不一致。 pgbouncer的預設設置是session連結。
- listen_port和listen_addr是pgbouncer監聽的位址和埠號。
- auth_type和auth_file是bppgbouncer用以完成用戶端身份認證。auth_file中保存用戶名和密碼，根據驗證方式(auth_type)的不同，auth_file的內容也有不同。
- md5: 基於md5的密碼驗證，
- auth_file中需要有普通文本和md5值兩種形式的密碼；
- crypt: 基於crypt的密碼驗證(man 3 crypt), auth_file必須包含文本密碼；
- plain: 明文驗證方式；
- trust: 不進行驗證，但auth_file依然需要保存用戶名；
- any: 也不進行驗證，而且auth_file中不需要保存用戶名了。但此種方式需要在pg_template1中明確說明用戶名進行真實資料庫的登錄。如: pg_template1 = host=127.0.0.1 user=exampleuser dbname=template1.否則會報錯的。 需要說明的是：auth_file中的用戶名、密碼都必須使用雙引號，否則還是報錯。
- logfile和pidfile分別保存log檔和pid檔的路徑。
- admin_users：列出哪些用戶可以登錄pgbouncer進行管理，以逗號進行分隔 stats_users：列出哪些用戶可以登錄pgbouncer進行唯讀操作，如可以列出伺服器狀態，訪問連結等，但是不能執行reload。
