PostgreSql 边边角角也能搞死你 之 小菜的一天
- 2019 年 11 月 13 日
- 筆記
很快小菜将测试库的表都弄到了生产库,但是缪牛马上就打电话,告诉小菜不对,问小菜怎么做的,小菜说就 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 吧小菜叫到办公室。转天就再也没有看到小菜的身影。
故事纯属瞎编乱造,如有雷同,和我无关,另外最近一些事情给我的感触是高大上的东西要懂,你手边的活也不能差,否则西瓜,芝麻都没有。