Sql 在连续交付过程中，是否有适当的方法自动将数据从生产转移到开发？

在常见的连续交付过程中，代码从开发实例移动到暂存实例，再移动到生产实例

出于开发目的（复制bug，使用完整的数据集测试性能），开发人员大多数时候都会将数据从生产数据库提取到开发环境中。例如，请参见

在我的公司，在我们的连续交付过程中，除了生产之外，我们还使用了三个实例：

• 最新版本：每晚与我们的SCM中继同步
• 暂存：在部署到生产环境之前使用最新发布的版本
• 稳定：与生产中部署的软件版本完全相同（用于重现生产中发现的错误）

问题是，在稳定的实例上，为了复制bug，我们希望拥有与生产中完全相同的数据集。因此，我们希望每晚同步数据库

---

这是一种好的做法吗？如何实施？是否存在陷阱？

根据生产环境中的数据，您可能不希望将其复制回非生产环境。（或者在某些法规下甚至可能不允许复制。）如果您拥有客户数据、个人识别信息（PII）、受监管数据、财务数据、信用卡数据、健康数据、SSN或任何其他类型的敏感数据，如果您复制这些数据，则您需要在生产中拥有（或应该拥有）的完整控制—您可能没有，而且可能不想要

我建议您寻找几种VDB解决方案。

---

其中一个是Delphix，Windocks支持带有集成数据库克隆的容器，仅用于描述的用例。完全公开，我为Windocks工作

你说得对，你提出的安全问题是合法的。然而，对于我们管理的大多数项目来说，只需使用2~3个SQL更新（擦除名称、密码、地址和任何PII）使所有数据匿名就足够安全了。这是一个陷阱。理想情况下，您应该在移动数据之前对其进行清理。因此，您可能希望在生产环境中的另一个数据库实例中复制数据，对其中的数据进行清理，然后将其迁移到非prod环境中。否则，您的生产数据存在于非生产环境中，即使是短暂的，这可能会使该环境处于附加控制的范围内。此外，您不应存储密码或加密密码。您应该存储密码的散列值。您使用的是哪一个数据库？@FlorianMotlik PostgreSQL 9（但我考虑的是一个数据库不可知的解决方案）很难确定数据库不可知，因为不同的技术具有截然不同的复制技术。对于Postgres，我认为您有两种选择（以及大多数其他数据库）：*从主数据库到暂存/稳定数据库的流式复制*夜间备份并插入到稳定/暂存数据库我会选择夜间备份并重新插入，因为这也会测试您的备份恢复过程，但这取决于数据对您的新鲜度；git add data.sql；git提交；git推送，在另一端使用git钩子调用dbrestore data.sql？git将确保仅传输数据上的差异，以确保机密性（通过ssh进行身份验证）