基于GCE与Cloud SQL PostgreSQL搭建PgBouncer：多库、安全及用户管理问询

1. 安全最佳实践：保障连接安全 #

必须启用SSL/TLS加密，这是Cloud SQL与PgBouncer连接的核心安全要求，具体配置步骤：

• 在Cloud SQL控制台开启强制SSL连接，拒绝所有未加密的连接请求。
• 从Cloud SQL控制台下载CA证书（server-ca.pem），上传到GCE实例的指定目录（例如/etc/pgbouncer/ssl/）。
• 修改PgBouncer配置文件pgbouncer.ini，指定SSL参数：

  [databases]
  your_db = host=your-cloud-sql-private-ip port=5432 dbname=your_db sslmode=verify-full sslrootcert=/etc/pgbouncer/ssl/server-ca.pem
  

• 额外安全加固：使用Cloud SQL的私有IP通过VPC peering连接，避免公网暴露；给运行PgBouncer的GCE服务账号仅授予Cloud SQL Client角色，遵循最小权限原则。

2. 用户管理：服务账号下的多用户权限控制 #

用服务账号运行PgBouncer时，无法直接管理数据库用户，推荐两种落地方案：

方案一：数据库内用户验证（auth_query） #

配置PgBouncer从Cloud SQL数据库中拉取用户权限信息，实现动态验证：

1. 在Cloud SQL中创建专门用于PgBouncer验证的用户（例如pgbouncer_auth），授予查询用户密码的权限：

   CREATE USER pgbouncer_auth WITH PASSWORD 'strong-password';
   GRANT SELECT ON pg_shadow TO pgbouncer_auth;
   

2. 修改pgbouncer.ini启用数据库验证：

   auth_type = md5
   auth_user = pgbouncer_auth
   auth_query = SELECT usename, passwd FROM pg_shadow WHERE usename=$1
   

这样PgBouncer会通过数据库查询验证客户端的用户名和密码，无需在本地维护用户列表。

方案二：IAM数据库用户映射 #

如果使用Cloud SQL IAM数据库用户，配置PgBouncer用服务账号身份令牌完成认证：

1. 给GCE服务账号授予Cloud SQL Client角色，确保其有权访问Cloud SQL实例。
2. 在pgbouncer.ini中配置IAM认证参数：

   auth_type = scram-sha-256
   auth_user = cloudsql-iam-service-account
   

3. 客户端连接时，用户名填写IAM邮箱，密码留空，PgBouncer会自动用服务账号的身份令牌完成认证，映射到对应的数据库用户权限。

3. 访问控制：多数据库多用户的权限隔离 #

需要结合PgBouncer配置和Cloud SQL IAM/数据库权限实现双重控制：

• PgBouncer层面：在[databases]段配置数据库与用户的绑定关系，限制特定用户只能连接指定数据库：

  [databases]
  db1 = host=... dbname=db1 user=db1_user
  db2 = host=... dbname=db2 user=db2_user
  

  也可通过userlist.txt维护允许连接的用户列表，直接拒绝未授权用户的连接请求。
• Cloud SQL层面：
  1. 用IAM策略限制哪些服务账号/用户能访问Cloud SQL实例。
  2. 在数据库内给每个用户授予最小必要权限，例如：

     GRANT CONNECT ON DATABASE db1 TO db1_user;
     GRANT SELECT ON TABLE db1.table1 TO db1_user;
     

  严格避免给用户过度授权。

4. 性能最佳实践：多数据库多用户场景优化 #

• 连接池模式选择：优先使用transaction模式，相比session模式能更高效复用连接，适合多用户短事务场景；若有长事务需求，可针对特定数据库单独配置session模式：

  [databases]
  db_long_trans = host=... pool_mode=session
  db_short_trans = host=... pool_mode=transaction
  

• 连接数配置：根据Cloud SQL的最大连接数（例如默认1000），合理设置PgBouncer参数：

  max_client_conn = 1000  # 最大客户端连接数
  default_pool_size = 20  # 每个数据库的默认连接池大小
  reserve_pool_size = 5   # 预留应急连接数
  

  避免连接池过载导致Cloud SQL拒绝连接。
• 监控与调优：开启PgBouncer的stats功能，通过psql -p 6432 pgbouncer连接后执行SHOW POOLS;查看连接池状态；同时监控GCE的CPU、内存使用率，避免资源瓶颈。
• 规避长事务：transaction模式下长事务会占用连接池资源，导致其他请求排队，建议拆分长事务或单独配置session模式。

5. 故障排查：用户与服务账号常见问题 #

常见问题及陷阱 #

• 用户验证失败：
  • 检查auth_query语句是否正确，pgbouncer_auth用户是否有查询pg_shadow的权限。
  • 若使用IAM用户，确认服务账号是否拥有Cloud SQL Client角色，客户端连接时的用户名是否为正确的IAM邮箱。
• 服务账号权限不足：
  • 不要给服务账号过度授权，仅授予Cloud SQL Client即可，避免权限泄露。
  • 确认GCE实例是否正确关联了目标服务账号，能否正常获取身份令牌。
• SSL连接失败：
  • 检查CA证书路径是否正确，sslmode是否设置为verify-full，Cloud SQL是否开启了强制SSL。
• 连接池耗尽：
  • 通过SHOW POOLS;查看used和free连接数，调整default_pool_size或max_client_conn参数。

排查技巧 #

• 开启PgBouncer的debug日志：log_level = debug，查看pgbouncer.log中的连接错误细节。
• 用psql -h localhost -p 6432 -U your_user your_db测试客户端连接，定位问题出在客户端、PgBouncer还是Cloud SQL。
• 查看Cloud SQL的审计日志，确认是否有拒绝连接的记录。

内容的提问来源于stack exchange，提问作者Noureddine Abdelmonem