PostgreSql 边边角角也能搞死你 之 小菜的一天

小菜今天第一天上班，开发的缪牛要小菜将开发的库导入到生产，晚上应用要上线。

之前小菜也是有用过的PG的，但基本上都是在自己的测试机上做一些“高大上”的东西。导库这样的事情，其实小菜是不大愿意干的，换句话没有技术含量。

很快小菜将测试库的表都弄到了生产库，但是缪牛马上就打电话，告诉小菜不对，问小菜怎么做的，小菜说就 dump  restore 呀，缪牛问怎么在生产上看到了其他测试库，怎么搞得。

我们看看小菜怎么做的

在源库

pg_dumpall -f databaseall.out

在目的

psql -f databaseall.out

缪牛看完后兑到，你问问你们组的老鸟行不行，别在瞎搞了， 小菜找到老鸟问，您说说我哪里错了，不就是复制整体的测试库然后到生产不就完了，他们说我瞎搞。

老鸟问：你自己看看你这样做对不对，首先开发要的是dvdrental库，你却把所有的库都备份了，另外PG的库中大多都有一些extension，而你看下面你恢复库时的报错，部分插件在生产中是没有被设置的，你就直接做，人家那样怼你已经很客气了。

老鸟继续说道，下次你先问清楚，到底要那个库，并且看看你的测试库和生产库之间的extension 有什么区别，并且不要随意用 pg_dumpall 这个命令来进行测试到生产的操作，测试里面的库太多，都复制到单个项目的生产库，这样可不行。

那怎么看数据库里面的extension呢，同时要注意PG里面cluster 中每个库的extension都可能不一样，所以

select extname,extowner,extnamespace,extrelocatable,extversion from pg_extension；

如果发现测试库里面的extension 在生产库没有，首先你先要将这两方的extension 对齐再说后面的。

再说你备份，你备份其实使用pg_dump就可以了

你按照我的这个命令来备份

 pg_dump -Fc -f dvdrental.out  --no-tablespace  --encoding=utf8 --clean --no-owner --dbname=dvdrental --disable-triggers

在目的库上恢复

pg_restore dvdrental.out --dbname='dvdrental' --no-owner   -c  --if-exists  -Fc

当然如果是生产库上已经存在了这个数据库，就不能这样做了，这样做也是要惹祸的。

为什么要去掉 owner呢，小菜问，你说呢，你能确认开发库上的用户在生产上存在吗？并且生产还要使用这个用户，老鸟不高兴的回答

所以仅仅恢复最纯净的东西就可以了，至于用户的账户怎么做，看开发的执行文档，根据需要建立就可以了。

过了有半个小时，缪牛又来了，直接问老鸟，你告诉他做完了，现在更糟糕了，生产数据都乱了。

原来是，在老鸟告诉他怎么做以后，已经正常了，后来由于部分调试原因，测试的表的字段有相关的改变，开发要求，更新原来的表结构，但小菜又将上面的命令做了一遍，现在已经有生产数据进去了，开发很不高兴。

因为业务部门投诉说，系统里面有乱数据，责问这是怎么回事？

其实最简单的操作方法

1 将原来的生产库导入的库整体删除

2 创建新的生产库

3  将表结构备份在导入就可以了

pg_dump -Fc -f dvdrental.out  --no-tablespace  --encoding=utf8 --clean --no-owner --dbname=dvdrental  --disable-triggers --schema-only

pg_restore dvdrental.out --dbname='dvdrental' --no-owner   -c  --if-exists  -Fc

小菜一上午被投诉了2次，心情估计是好不了。

下午开发又投诉小菜，说让他建立一个数据库一个多小时建不出来，严重影响他们的开发任务，已经被投诉到运维总监哪里。

老鸟问，到底怎么回事，小菜委屈的把截图给老鸟看，你看不是我不建，建不上呀。

那你这样不就行了

select datname,usename,application_name,client_addr,client_hostname,backend_start  from pg_stat_activity where datname = 'template1';

SELECT pg_terminate_backend(2269);

这样不就能查看到到底谁在打开 templet1 不关闭了吗？，看上面的图，这个库不就建立上了吗？

老鸟有点生气的说，下次不会多问问，别在那憋宝，弄得总监还以为我们排挤你了。

小菜不好意思，好好下次一定问哈

快到下班的时候，小菜再次被投诉，因为生产中发生了一个事故，虽然和小菜没有直接的关系。

事情是新来了一个开发，在程序打包的时候，将一条 drop table 的语句误打包到了执行文件中，而这个表已经在业务系统上运行了，并且还有不到300万的数据。被投诉的理由，小菜分配的权限不对，开发死死咬住，如果运维部不给出执行 DDL 的权限，也不会发生这样的事情，运维总监也很为难，的确当初的规范中明确的标识，在生产中的应用账户不能拥有DDL数据库权限。

小菜是怎么给账户赋予权限的呢？

老鸟无奈的说，你怎么不问问呢，公司是有规定的（小菜小声的说给了权限能用不就好了），赋予应用账户的权限，只能赋予DML 权限和存储过程，或函数的运行权限赋予，其他的都不能做。

当然你也要确认应用所处的schema

grant select,update,delete,insert on all tables IN schema public to app_financial;

在建立这些权限后，需要核实相关的权限

select * from information_schema.table_privileges where grantee= 'app_financial';

select * from information_schema.routine_privileges where grantee= 'app_financial';

select * from information_schema.usage_privileges where grantee='app_financial';

检查相关的权限的赋予的情况。

小菜无奈的说，哎早知道问问了，一会HR 吧小菜叫到办公室。转天就再也没有看到小菜的身影。

故事纯属瞎编乱造，如有雷同，和我无关，另外最近一些事情给我的感触是高大上的东西要懂，你手边的活也不能差，否则西瓜，芝麻都没有。