我知道这里有很多变量，它们高度依赖于环境中的应用程序以及组织的需求。我首先阅读了这篇文章，因为问题类似。[https://serverfault.com/questions/380701/replicate-main-mysql-db-to-a-development-server-to-play-with-real-data][1]
我认为我可以从我的角度对这个问题进行更深入的探讨，并希望得到一些针对我们环境的建议。
- 我们有一个独立的服务器，托管在线学习管理系统。
- LMS 拥有数千名用户，并且其数据库被经常性地写入。
- 希望获取数据库的“快照”，并将其复制到开发服务器上进行测试、新构建等。
- 由于数据库的动态特性，快照需要相对接近（最多几天内）实时数据。
- 开发服务器需要读/写，但根本不会影响生产服务器。
- 数据库中的数据将包含 PII，并且需要在开发团队访问之前进行清理。
我认为一般的步骤应该是：
- 按照某种计划自动执行从生产到开发的 mysqldump
- 在 dev 上运行脚本来清理/匿名化数据
- 根据计划自动将干净数据恢复到开发
根据这些要求，我是否忽略了可能影响服务器中的数据或服务器上的负载/资源的任何明显因素？
答案1
计划 A
考虑以下设置：
- 主副本设置（普通复制）
- 副本需要额外的磁盘空间。（建议数据集大小的 3 倍。）
- 副本已设置 LVM。
- 在副本上，拍摄快照 - 无论数据集大小，这都需要一分钟左右。
- 匿名化快照中的数据（等等）。
- 使用快照进行测试。
- 快照与副本是分开的，副本继续接收写入。
- LVM 依赖于“写入时复制”，因此快照一开始几乎不占用磁盘空间，但会随着时间的推移而增大。完成测试后（或需要进行新的快照时），将其删除以收回磁盘空间。
计划A2——通过以这种方式使用多个副本，可以处理多个开发/测试/构建设置。
B 计划
- 在 3 个“节点”上设置 Galera 集群。所有 3 个节点将具有相同的数据。
- 当想要测试时，从集群中取出一个节点用于开发。
- 测试完成后，将其放回集群；它将自动重新同步。（在再次将其用于开发之前，请给它时间重新同步。）
- 请注意，如果匿名数据过于密集，重新同步将需要很长时间。
B2 计划-- 计划 B，但有 4 个节点；即使一个节点正在被开发人员使用，这也为您提供完全自动故障转移。
B3 计划-- 计划 B，但使用“garbd”来避免需要完整的第 3 个节点。（除非您有 4 个节点，否则此计划将无法进行故障转移。）
B4计划-- 如果有 5 个节点（其中一个节点可选为 garbd），您可以轮流使用两个节点供开发人员使用。一个节点忙于匿名，而另一个节点正在被积极使用。（出于各种原因，我不会超过 5 个节点。）
笔记
- 这里的建议是“一般性的”，并不针对 LMS。
- 拉取开发服务器仅需几分钟（加上匿名化）。
- 副本（常规或 Galera）提供了方便的备份技术。
答案2
开发人员可能会接触敏感的 PII 数据，这可能会使事情变得非常复杂。请咨询您的合规人员，了解这会带来哪些风险，以及应采取哪些控制措施和培训措施，以使开发人员像运营人员一样尊重数据。
不对开发和测试环境进行完整复制可能会完全避免 PII。让支持人员构建示例数据，从实际示例中进行清理。仅导入配置和构建数据，而不是有关人员的数据。这种将它们分开的方法需要做大量工作才能保持维护和切合实际，但可以保持开发和测试规模较小，并且不会有敏感数据。
根据 IT 的业务连续性程序，仍然需要测试完整恢复，即使只是为了测试备份。备份应以对生产性能影响可接受的方式进行，无论是像 mysqldump 这样的导出、复制还是块存储快照。
如果需要将生产环境的副本转换为非生产环境，我认为它应该是一个单独的支持环境或阶段环境，开发人员不应访问它，只有支持人员才能访问它。将测试中的事情的影响降到最低，用户会注意到。完整的非生产环境副本可能会长时间停机，因为重写所有 PII 需要很长时间。