如何合理规划 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

相关推荐
一只fish13 分钟前
MySQL 8.0 OCP 1Z0-908 题目解析(17)
数据库·mysql
花好月圆春祺夏安41 分钟前
基于odoo17的设计模式详解---装饰模式
数据库·python·设计模式
A__tao44 分钟前
SQL 转 Java 实体类工具
java·数据库·sql
m0_653031361 小时前
腾讯云认证考试报名 - TDSQL数据库交付运维专家(TCCE PostgreSQL版)
运维·数据库·腾讯云
小马哥编程2 小时前
【iSAQB软件架构】架构决策记录-ADR
数据库·架构·系统架构·设计规范
萧鼎2 小时前
深度探索 Py2neo:用 Python 玩转图数据库 Neo4j
数据库·python·neo4j
m0_653031363 小时前
腾讯云认证考试报名 - TDSQL数据库交付运维专家(TCCE MySQL版)
运维·数据库·腾讯云
power 雀儿3 小时前
集群聊天服务器---MySQL数据库的建立
服务器·数据库·mysql
骑着王八撵玉兔5 小时前
【性能优化与架构调优(二)】高性能数据库设计与优化
数据库·性能优化·架构
想要入门的程序猿6 小时前
Qt写入excel
数据库·qt·excel