如何合理规划 PostgreSQL 的数据库用户

PostgreSQL 作为世界上最领先的开源数据库，有一套强大的用户角色权限系统，和 MySQL 做一个对比：

但硬币的另一面则是对于简单场景来说增加了复杂度。在许多单应用场景，其实也不需要额外的 schema 层，也不需要额外的 owner。相信玩过 PG 的同学都碰到过类似 must be owner of table 的问题。

场景说明

我们就来说说简单的 PG 使用场景，数据库用户该如何配。所谓简单是指：

1. PG 实例就一个数据库
2. 数据库就一个默认的 public schema
3. 所有的表都在这个 public schema 下

而使用数据库的场景，由人到数据库，和应用到数据库两部分组成：

1. 人到数据库

   • DBA 操作
   • 数据库变更，DDL 和 DML 都有
   • 数据库查询

2. 应用到数据库

   • 数据库变更，DDL 的话通常在应用启动前做，除此之外都是 DML
   • 数据库查询

具体配置

最简单粗暴的当然是一个 superuser 搞定。本地安装 postgres 的话，第一个 postgres 用户其实就是这样的 superuser。

我们把人和应用拆开，如果应用在启动时还是需要变更 schema，则是下面这样

如果数据库 schema 变更发布已经和应用独立开来了，那么应用只需要有基本的数据库读写操作

到了这步如果除了 DBA 之外的人想访问数据库的话，直接把 DBA 用户交出去风险太大了，所以这时会选择引入像 Bytebase 这样的工具。DBA 在 Bytebase 上配置普通用户的数据库访问权限，而不用把用户名密码交出去。而且 schema 变更也可以在 Bytebase 上完成，这样大大减少了需要使用 DBA 账号直接操作数据库的情况，降低风险。

Pigsty 作为开箱即用的 PG 发行版，也预置了一套类似的默认角色。

额外注意

• 公有云数据库服务是不提供 superuser 的，他们只提供一个阉割版的 superuser，比如 Google Cloud SQL 里的 cloudsqlsuperuser

• 设置单独 migration 用户的原因一方面是为了方便监控，另一方面也使得我们可以给 migration 用户设置单独的默认连接参数，最常见设置的是 lock_timeout。要设置的原因是，做 DDL 时要加锁，加锁需要等待，而因为 PG 的队列机制，即使后面来的另外一条事务不需要 DDL 锁，一样会被 block 住。所以 migration 用户往往要设置一个 lock_timeout，避免长时间 block 后面的其他事务。

• 在 Postgres 里创建对象时，比如建表，建出来表的 owner 就是建表语句的执行者。所以当使用一个单独的 migration 用户来做 schema 变更时，表的 owner 也会是 migration。如果希望 owner 能反应具体的业务，比如说 payment 的话，那么可以再单独创建一个 payment 的角色，在 migration 执行的时候，使用 SET LOCAL ROLE 切换到 payment 再执行。

PostgreSQL 的用户角色体系还是有点复杂的，如果有什么其他额外建议和需要注意的地方，欢迎大家留言。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase