我对开发和生产之间的WordPress数据库同步有问题,我想知道其他人如何解决它。我知道这个问题,但是它并没有真正涵盖更原始,更实际的用例。我将所有内容都转储了下来,并将其复制到我们的开发环境中。我开始进行更改。 1周后,我准备部署更新。同时,生产站点上的数据库已更改(新帖子,新评论等)。在发布期间,如何在生产和开发之间同步更改,是否可以(至少要自动化)此过程?

评论

wp.​​tutsplus.com/tutorials/…

试试这个插件wordpress.org/extend/plugins/duplicator

#1 楼

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




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

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


同时生产发生了变化(新帖,新评论等)


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

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

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


我对MySql命令不满意,所以我会选择选项1。

评论


请注意,XML导出停滞在帖子数量很大的地方,例如在我的博客+10.000帖子上,我无法使用它。

– edelwater
2010-11-14 21:26

@edelwater,是的,这取决于服务器的max_execution_time设置(通常为30秒),对于非常大的出口,必须将该值设置得更高(1-2分钟或更长时间)

–mike23
11年7月28日在14:18

#2 楼

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

评论


好点子!但是,如果生产在纯粹的内容区域(帖子,评论)有所更改,并且开发人员在说的设置和设置方面进行了更改(例如添加了5个插件并对其设置进行了调整),您将如何在不进行两次实际工作的情况下继承这些设置更改开发时间和生产时间)?

– Alex
2010-09-22 14:39

那才是真正的问题,我没有答案。

–curtismchale
2010-09-22在21:26

-1。有时我们确实需要使它们同步。专门用于数据库中的帖子/页面ID。

–弗朗西斯科·科拉莱斯·莫拉莱斯(Francisco Corrales Morales)
2014年7月21日在20:22

#3 楼

一旦触及并行进行更改的主题,就触及配置管理区域。具有许多模式,它们自己的社区(http://www.cmcrossroads.com/)和工具不是用于版本管理(如svn / git),而是用于支持配置管理(模式)(如clearcase)。 (完全不同的区域)。在这种情况下,这仍然是一个简单的情况,您会发现它在工作上存在一些局限性,一些手动工作和一些清单。

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

如果您想更专业一点:

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

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

c)并行工作首先描述您要管理的配置项,确定流程始终是从开发到生产,还是确实需要执行所有有两种方式。

例如使用ClearCase,您将以三种方式合并以下情况:
1)琐碎的合并:它将自动完成这些操作
2)非平凡的自动:它将自动执行这些操作,但您需要检查
3)非平凡的非自动:这是一个冲突,例如在1行上进行了几处更改。
非琐碎的部分是您需要手动处理的最小部分,一个好的合并工具将引导您完成此操作。
此外,如果您在(a)下标识了应该复制的文件,则只能将它们复制,然后将它们合并为单词合并,并且可以在其中进行其他商业或非商业合并的特定文件类型。行为将不被合并,而只是被复制而覆盖另一个版本而不合并(例如,您尚未修改的插件)。这些类型中的许多类型都有可能具有不同的行为。但是写下CI之间的关系,

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

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

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

问题是...您需要先写下来。这不是技术黑客。这是Config Management的默认模式,因此这里也没有什么奇怪的,但是您需要将其写下来。您可能会发现例如表示已安装的插件使用一些在其他环境中不同的数据对数据库进行了更改,因此您需要执行一些额外的步骤。从技术上讲,几乎总是一切皆有可能,尽管始终使用相同的方法并使用相同的CM模式集,但请检查http://www.cmcrossroads.com/forums以了解复杂度是数十倍或数百倍的方案。

#4 楼

我刚刚发表了一篇有关如何将生产数据同步到暂存台的文章,请查看我的博客文章,网址为:http://blog.wp.weightpoint.se/2012/01/04/synchronizing-wordpress-multisite-database -from-production-to-staging-envirorment /

如果您也想同步代码和其他内容,我建议使用相关的忽略文件创建git或mercurial存储库。
如果您想对登台进行差异化更新,那么我想创建迁移脚本是最安全,最佳的方法。