我这么做很麻烦 - 我想我会在StackOverflow上做一个Q / A来解释这个过程。
问题是关于复制RDS postgres数据库以供开发使用 - 尤其是测试数据库迁移脚本等。这就是为什么要关注“单个数据库”中的“单一模式”。
在我的情况下,我想创建一个尽可能隔离的测试数据库,同时保留在单个RDS实例中(因为整个RDS实例旋转需要5到15分钟,因为我很便宜)。 / p>
答案 0 :(得分:7)
这是仅使用命令行的答案。您必须安装Postgres客户端工具(不需要实际服务器)和对RDS实例的网络访问。
在下面的例子中:
rds.example.com
有一个RDS实例,其中有一个名为rds_master
的主用户。 db_dev_user
的名为dev_db
的数据库,其中包含架构app_schema
。pg_dump 打印出原始数据库的架构和数据,即使存在与数据库的活动连接,也将工作。当然,这些连接的性能可能会受到影响,但数据库的结果副本 transactional。
pg_dump --host=rds.example.com --port=5432 \
--format=custom \
--username=db_dev_user --dbname=dev_db \
> pgdumped
createuser 命令会创建测试应用程序/进程应该连接的用户(为了更好地隔离),请注意,创建的用户不是超级用户,也不能创建数据库或角色。
createuser --host=rds.example.com --port=5432 \
--username=rds_master \
--no-createdb --no-createrole --no-superuser \
--login --pwprompt \
db_test_user
如果没有此次授权命令,以下createdb
将失败:
psql --host=rds.example.com --port=5432 \
--username=rds_master --dbname=postgres \
--command="grant db_test_user TO rds_master"
createdb 在锡上做了它的说法;请注意db_test_user
角色"拥有" DB。
createdb --host=rds.example.com --port=5432 \
--username=rds_master --owner=db_test_user test_db
接下来是创建架构命令。 db_test_user
无法创建架构,但必须为架构授权,否则pg_restore
将失败,因为它最终会尝试还原到pg_catalog
架构(请注意user=rds_master
1}},但dbname=test_db
)。
psql --host=rds.example.com --port=5432 \
--username=rds_master --dbname=test_db \
--command="create schema app_schema authorization db_test_user"
最后,我们发出 pg_restore 命令:
pg_restore --host=rds.example.com --port=5432 \
--verbose --exit-on-error --single-transaction \
--username=db_test_user --schema=app_schema \
--dbname=test_db --no-owner \
./pgdumped
exit-on-error
- 因为否则会发现出现问题涉及太多的滚动和扫描(无论如何都是single-transaction
隐含的)single-transaction
- 如果事情变成梨形,则避免丢弃或重新创建数据库schema
- 只执行我们关心的架构(也可以将其提供给原始pg_dump
命令)dbname
- 确保使用我们创建的数据库no-owner
- 无论如何我们都以db_test_user
连接,所以一切都应由合适的用户拥有答案 1 :(得分:3)
对于生产,您最好只拍摄实例的RDS快照并恢复它,这将创建一个全新的RDS实例。
在一个基本上空的数据库上 - 创建快照需要几分钟,另外还需要5分钟左右来创建新的RDS实例(这就是为什么它在开发过程中很痛苦的一部分)。
只有新的RDS实例正在运行时才会收取费用。保持在免费层内是我想用开发目的创建具有相同实例的数据库的原因之一,而且不必处理第二个DNS名称;当你开始拥有多个环境时,这个效果会成倍增加。
运行第二个RDS实例是更好的生产选项,因为您几乎完全消除了对原始数据库的任何风险。此外,当您处理实际数据量时 - 快照/数据库创建时间将因读取/写入数据所花费的时间而相形见绌。对于大量数据,Amazon RDS快照创建/恢复过程可能比在某个服务器上运行的一组脚本具有更好的并行化。此外,RDS控制台使您可以了解还原的进度 - 随着数据集变得越来越大并且更多人参与其中,这变得非常宝贵。