如何在RDS实例中复制PostgreSQL RDS数据库

Question

我这么做很麻烦 - 我想我会在StackOverflow上做一个Q/A来解释这个过程。

问题是关于复制RDS postgres数据库的开发用途 - 特别是测试数据库迁移脚本等。这就是为什么关注“单一数据库”中的“单一模式”。在我的情况下，我想创建一个尽可能孤立的测试数据库，同时保留在单个RDS实例中（因为旋转整个RDS实例需要5-15分钟，因为我便宜）。

Answer 1

以下是仅使用命令行的答案，您必须安装Postgres客户端工具（不需要实际的服务器）和网络访问RDS实例。

在下面的例子：

• 我在rds.example.com一个RDS实例，它有一个名为rds_master一个主用户。
• 我有一个名为db_dev_user的“应用程序用户”，名为dev_db的数据库包含架构app_schema。
• 注意，“用户”和Postgres的“角色”是同义

---

pg_dump的打印出的模式和原始数据库的数据和将工作即使有活动连接数据库（当然，对于那些连接上的性能可能会受到影响）：

pg_dump --format=custom --host=rds.example.com --port=5432 --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_catalog架构pg_restore会失败（因此请注意，user=rds_master，但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 --verbose --exit-on-error --single-transaction --host=rds.example.com --port=5432 --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的 - 我们作为连接反正db_test_user，所以一切都应该由右所拥有用户

Answer 2

对于生产来说，最好是将实例的RDS快照恢复并创建一个全新的RDS实例。

在一个大部分为空的数据库上 - 创建快照需要几分钟，创建新RDS实例需要5分钟左右（这是开发过程中的一个原因）。

仅当新RDS实例运行时才会收取费用。保持在免费层是我想用相同的实例创建该数据库用于开发目的的另一个原因，另外也不需要处理第二个DNS名称;并且当你开始拥有多个环境时，这种影响会倍增。

运行第二个RDS实例是一个更好的计划，因为您几乎完全消除了原始数据库的任何风险。另外，当你处理实际的数据量时，快照/数据库的创建时间将会因读/写数据所花费的时间而变得相形见绌。对于大量数据，Amazon RDS快照创建/恢复过程很可能比在单个服务器上运行的一组脚本具有更好的并行性。此外，RDS控制台为您提供恢复进程的可行性 - 随着数据集越来越大，更多人参与其中，数据集变得非常宝贵。