开发/阶段与生产之间的数据库同步

我对开发和生产之间的WordPress数据库同步有问题，我想知道其他人如何解决它。我知道这个问题，但它并没有真正涵盖更原始和更实际的用例。

假设我有一个在线WordPress网站。我将所有内容都转储了下来，并将其复制到我们的开发环境中。我开始进行更改。1周后，我准备部署更新。同时，生产站点上的数据库已更改（新帖子，新评论等）。在发布期间，如何在生产和开发之间同步更改，是否可以（至少一定程度上）自动化该过程？

我可能会想念一个更好的方法，但我将给您2个选择：

1.使用XML导出来导出新帖子和评论。然后使用WordPress导入器将新帖子和评论导入回dev数据库

最好导入到dev中，然后将数据库移至生产环境，因为导入时它将从生产环境下载所有新的媒体文件。

同时，生产发生了变化（新帖，新评论等）

这样可以解决您带来的任何更改内容的问题。

2.使用INSERT IGNORE INTO MySql命令从dev添加新表。或REPLACE命令覆盖同一表中的重复行。

在使用MySql之前，请对两个数据库进行备份，然后将gz数据库移至生产服务器并上载转储（如果与生产相同，请更改dev的名称。

INSERT IGNORE INTO `_wp_production_db`.`wp_cool_plugin_options`
SELECT *
FROM `_wp_dev_db`.`wp_cool_plugin_options`

我对MySql命令不满意，因此我会选择选项1。

如果只是更多完全相同的数据类型（一些新的博客文章，新的评论），我不确定为什么需要真正同步它。并不是因为它完全相同，所以它将改变网站上代码的工作方式。我通常不担心它，除非它是一种新型数据。

我只是一直确保我对网站的数据有一个很好的样本，而不是每个来自实时网站的帖子，页面，评论。

一旦触及并行进行更改的主题，就触及配置管理区域。拥有许多模式，它们自己的社区（http://www.cmcrossroads.com/）和工具不仅用于版本管理（如svn / git），还用于支持配置管理（模式）（如clearcase）。（完全不同的区域）。

在这种情况下，这仍然是一个简单的情况，您会发现它在工作上有一些限制，一些手动工作和一些清单。

我正在考虑的场景使它更能描述理想的解决方案：可能在世界各个角落的多个开发人员在同一个代码库上工作，多个测试环境，多个验收环境，多个生产验收环境。

如果您想更专业一点：

a）写下您遇到的所有配置项的列表，这可能是WordPress代码本身，来自外部的插件，内容，元数据，并确定您要带入其中的“管理”中的哪些，哪些重要。

b）描述可能发生的工作流程，例如修复会发生什么，开发中的新事物会发生什么，在哪种情况下您会改变内容，被称为什么，由谁来做，谁是它的所有者例如新帖子或新插件。

c）对于并行工作，首先描述您要管理的配置项，确定流程始终是从开发到生产，还是确实需要通过两种方式完成所有流程。

d）为（a）下的每种CI类型编写一个解决方案。例如，对于所有文本（或类似php文件的导出文本，但XML文件中还包括纯文本）的合并都是可能的。这真的没问题，但是您需要一个好的合并工具。例如，使用ClearCase，您将以三种方式合并以下情况：1）琐碎的合并：它将自动执行这些操作2）非琐碎的自动：它将自动执行这些操作，但您需要检查一下3）非琐碎的非自动：这是一个冲突，例如在1行上进行了一些更改。非琐碎的部分是您需要手动处理的最小部分，一个好的合并工具将引导您完成此工作，例如，使用大写字母（也可以进行词合并，并且您可以在其中链接其他商业或非商业合并的特定文件）类型）。此外，如果您在（a）文件中标识了仅应复制的文件，则它们的行为将不被合并，而只是被复制而覆盖另一版本而不进行合并（例如，未修改的插件）。这些类型中的许多类型都有可能具有不同的行为。但是写下CI之间的关系，

然后，对于非基于文本的合并，您需要决定如何处理它们，例如在2个地方更改的图像。您可以在这里决定生产始终具有优先权（至少我是这样认为的），这很简单。

因此，要解决此问题，您需要一个支持不同流的版本管理工具。每个流将代表一个部分。（这可能会非常复杂，具体取决于您的需求，但是在这种情况下，我认为这非常简单）。

如果现在您可以在WordPress的安装下管理这些流，并将它们与数据库的内容同步，等等...，那么您可以在CM /版本控制工具中执行合并，然后将其导出到其他环境中。

问题是...您需要先写下来。这不是技术黑客。这是Config Management的默认模式，因此这里也没有什么奇怪的，但是您需要将其写下来。您可能会发现，例如，已安装的插件使用一些在其他环境中不同的数据对数据库进行了更改，因此您需要执行一些额外的步骤。

从技术上讲，几乎总是一切皆有可能，尽管始终使用相同的方法和使用相同的CM模式集，但请查看http://www.cmcrossroads.com/forums以了解复杂度是数十倍或数百倍的方案。

简而言之：在其下放置一个版本管理层，自动执行合并并处理冲突，然后将其导入目标环境。考虑适合这里的流策略并写下来。执行微小的CM管理。那将是专业的解决方案，否则将安装一些数据库复制黑客，脚本等...

我刚刚发布了有关如何将生产数据同步到我们的登台的帖子，请查看我的博客文章，网址为：http : //blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database从生产到分期环境/

如果您也想同步代码和其他内容，我建议您使用相关的忽略文件创建一个git或mercurial存储库。

如果您想从登台进行产品差异化更新，那么我想创建迁移脚本是最安全，最佳的方法。