我有一个与Amazon Aurora PostgreSQL兼容的数据库，作为一个“live”试点实例运行。
我计划在明年年初正式生产转型，我曾设想过包括开发和测试实例的创建、启动快照恢复等。此外，我还迫切需要做一些对现有视图和过程有潜在影响的数据模型改进，我不愿意在“实时”情况下这样做，尽管目前没有停机的直接影响。
我读过亚马逊关于Aurora克隆的文档，但是没有找到任何关于在实践中使用它的“真实世界”文章或帖子。我看到一篇非亚马逊的文章，它只是重新声明了亚马逊的摘要。
有没有人对这种能力有直接的经验？或者是机械的内部知识？明确地：
您能独立地对每个实例进行DDL（模式）更改吗？文档中没有提到这一点。我不确定术语“clone”的使用是否意味着它们在结构上保持相同，但是考虑到所引用的用例，我无法想象您基本上是通过克隆来冻结DB结构的。
是否有任何性能影响（考虑到“冻结”共享页和实例特定页之间的存储分布）？
如果创建数据库的克隆，然后再删除该克隆，是否不可逆转地更改了原始数据库的存储模式（包括该过程的任何性能影响）？
它是否改变了引擎盖下的删除行为？我不知道Aurora存储的工作方式（而且对数据库存储的了解也不多），但在过去，存储可以被回收以用于删除的数据。在这个模型中，如果克隆数据库，然后从表中删除几行，会发生什么情况？
我将通过创建一个“老式克隆”（快照还原到一个新实例）来测试它，然后克隆它，但在此期间我很感激地收到了任何见解！
最佳答案
是的，您可以对克隆进行架构更改，而这些更改根本不会影响基础数据库。它们将导致克隆需要复制表中的每一页，因为需要为克隆更改所有原始页。
这取决于-我们已经看到，如果修改一个大表的模式，克隆可能会非常慢-我还没有得到官方解释，但我认为这是因为克隆必须通过原始页指针链接才能到达其副本，对于一个小表或一个大表中相对较少的页面来说，这是很好的，但是一旦由于架构更改而基本上复制了整个表，我们就会看到这样一种情况：在克隆上，一个子秒的SELECT查询需要80秒。我要说的是，实际的模式更改不会花费比预期更长的时间。
不，原始数据库的页永远不会被克隆所触及，它们将被使用，直到克隆修改它们，此时它们将被复制以供克隆使用。如果以后删除整个原始数据库或整个克隆，也没关系，这两个数据库的工作方式就好像它们完全独立于其他数据库一样，它们只共享未经更改的页面。
不，基本上和3的答案一样。如果删除克隆中的行，则包含这些行的页将被复制到克隆中，而原始页则保持不变。
正如您所描述的，我们正在使用克隆来开发和暂存生产副本，它工作得很好，但是正如我所说的，有一个场景（模式更改为大表）我们看到了一些非常糟糕的性能。一般来说，性能都很好，我们看不到常规插入、更新或删除的性能有任何显著的差异——如果运行一个大更新，它触及了一个大表中的大多数行，那么可能会更明显，但是对于常规应用程序工作，它的性能很好。
关于postgresql - Amazon Aurora PostgreSQL:克隆功能:不利之处？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/52605119/