我项目中的开发人员希望将开发服务器上的开发数据库与实时服务器上的实时数据库同步，但我认为这不是一个好主意。尽管如此，部署代码库+数据库到实时数据库的最佳方式是什么？到目前为止，我使用 rsync 来传输数据，并使用简单的导出/导入数据库。最终设置包括一个开发服务器和 2 个实时服务器（一个在美国，一个在欧洲，用于 HA/LB）。有人提议使用 MariaDB 集群，但我不确定是否要在此设置中引入多主复制。尤其是因为 2 个实时服务器相距很远。此外，我必须设法为他们提供一个用于开发服务器的 up2date 实时数据库，因为开发人员显然无法在数据库很旧时将其推送到实时数据库（然后在导出/导入之间的时间内会缺少条目）。也许我在这里看不到森林中的树木，这相当简单。你们建议我怎么做？
答案1
由于这开始变成一种评论交流，所以我想我应该好好地把它写下来。
首先，将生产数据库（频繁地）同步到开发数据库是一个相当常见的要求，这样开发就可以根据接近实际情况进行。但反过来呢？我不确定我是否见过这种情况，而且我绝对不会这么做。
您说得对，架构或数据库内容更改通常需要更新生产数据库，以配合从开发中转移的代码更改。但合理的发布流程会通过制定更新架构、上传新内容和/或修改现有内容的程序，并在代码发布时部署这些程序来处理这个问题。
在我工作过的监管最严格的环境中，变化如下字面上地脚本化 - 一名开发人员编写了一份冗长的变更测试响应文档，详细说明了必须输入的内容、将看到的内容、应如何测试以及需要哪些结果。该脚本由第二名开发人员签署，以确认它已在干净的测试环境中进行了测试，并由第三开发人员不是这个过程是经过深思熟虑的。这确保没有人会耍小聪明，在发生奇怪的事情时偏离轨道。通常，第四开发人员将在脚本上共同签署，表明他/她已经确认了所声称看到和完成的一切。
该脚本还指定了一个经过测试的退出程序，如果响应与脚本中预期的不符，则由第三位开发人员执行该程序。如果整个过程通过审核，则生产环境通常会重新同步到开发和测试环境中。
我并不是说整个过程都适合您的环境；只是说它适合某些人。但您似乎想知道除了盲目地将开发同步到生产之外，如何处理架构和内容更改，所以我希望这能对此有所启发。如果您最终通过将开发同步到生产来进行部署，请确保您的备份是最新的，并且您的恢复过程经过了充分测试。您将需要它们。