当您有“销售”需求时，如何保持测试和生产电子商务数据库同步生产中的更新？
我读过下面的帖子，保持测试和生产服务器环境干净、同步和一致，但我仍然对最好的方法是什么有一些疑问。
“您应该对测试环境进行修改并将其复制到生产服务器”。问题是我正在使用 Magento 安装：我在不同时间在测试和生产环境中进行了不同的修改（例如生产服务器中的销售），我不知道保持它们同步的最佳方法是什么。
由于有 200 多个表，因此在 Magento 的表结构中进行“挖掘”将是一件痛苦的事情。
您对此有何看法？在这种情况下是否有工具可以帮助我同步数据库？有没有 MySql 配置可以做到这一点？
提前致谢！
I've read the following thread in SO, Keeping testing and production server environments clean, in sync, and consistent, and I still have some doubts in what is the best way to do it.
"You should do modifications to your test environment and replicate it to your production server". Problem is I'm using Magento installation: I have different modifications in test and production environment in different times (like sales in production server), and I don't know what is the best way to keep them in sync.
"Digging" in Magento's table structure is going to be a pain since there are 200+ tables.
What are your opinions about it? Are there tools that could help me to sync the databases in this situation? Is there a MySql configuration to do it?
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我知道我迟到了，但我刚刚发布了一个将生产数据库与暂存同步的脚本。
http://markshust.com/2011/09/08/syncing -magento-instance-生产-开发
一般来说，在登台上没有什么重要的，因为它随时可能被覆盖 - 它应该是生产的精确克隆，用于在几乎完全模仿生产的环境中进行测试。
开发（或本地计算机）是在将代码发送到暂存进行部署测试之前测试代码更新或更改的地方。
I know I'm late to the mix, but I just posted up a script that syncs production databases with staging.
http://markshust.com/2011/09/08/syncing-magento-instance-production-development
Generally, nothing should be important on staging as it could get overwritten at any time - it's supposed to be an exact clone of production for testing in an environment that just about exactly mimics production.
Development (or your local machine) is where you test code updates or changes before it is sent of to staging for deployment testing.
我正在运行一个 Magento 站点，其中包含一个生产实例、多个开发实例和一个测试实例。
Magento 通常非常干净地将元模型和数据库配置信息保存在代码中。每个模块都附带了需要运行才能安装的数据库脚本，并且 Magento 非常擅长在模块代码出现时自动运行这些脚本。有一些配置选项在管理员中修改并保留在数据库中，但很少。这与某些系统（例如 Drupal）不同，在这些系统中，数据库中保存了大量元模型信息，但从未反映在代码中。
我所做的就是在版本控制中跟踪代码库。例如，我将在开发版本中安装一个新模块。一旦代码运行，我将在版本控制中对其进行标记，将标记推送到测试实例，并将数据库从生产复制到测试实例。这让我对生产系统有了一个准确的了解。 （将 Magento 数据库从一个实例移动到另一个实例时，需要进行一些小更改。请参阅此回答了解详细信息。）
在部署时，通常只需要在管理中设置很少的配置选项。当我对它们进行测试时，我会记下它们，这给了我一份在转向生产过程中需要完成的工作清单。
如果您必须在部署时设置自动和即时配置选项，您可以在 config.xml 中指定您需要的默认配置选项，该配置选项将在您的模块之后加载（即取决于您的模块）。从来没有这样做过，但我看不出有什么理由它行不通。
对实时数据的任何更改（全面更改价格等），我都会在开发中编写脚本，在实时数据库的副本上进行测试，然后在生产中部署。
希望这有帮助。
I'm running a Magento site with a production instance, a number of development instances, and a testing instance.
Magento is generally pretty clean about keeping metamodel and database configuration information in code. Each module comes with the database scripts that it needs to run to install itself, and Magento's quite good about running these automatically when the code for a module shows up. There are some configuration options that are modified in the administrator and kept in the datbase, but very few. This is different than some systems, e.g. Drupal, where there is a massive amount of metamodel information kept in the database and never reflected in code.
What I do is keep track of the code base in version control. For example, I'll install a new module in a development version. Once the code is working, I'll tag it in version control, push the tag out to the test instance, and copy the database from production to the test instance. That gives me an exact picture of what the production system will look like. (Some small changes are required when moving a Magento database from instance to instance. See this answer for details.)
On deployment, there are usually only very few configuration options that need to be set in the admin. I make note of them as I put them through on test, and this gives me a list of what needs to be done with the move to production.
If you must have automatic and instant config options set with the deployment, you can specify the default config options to be what you need in a config.xml that will be loaded after your module (i.e. that depends on your module.) I've never done it this way, but I don't see any reason why it wouldn't work.
Any changes to live data (changing prices across the board, or the like), I script on dev, test on a copy of the live database, and deploy on production.
Hope this helps.
快速回答：Magento 企业应该通过允许您运行临时站点，然后通过管理界面同步价格和产品等内容来解决这个问题。我还没有完全成功，但这个想法是存在的。
当涉及到代码时，您仍然可以毫无困难地使用这些环境。例如，更改网站的外观或添加新插件可能不需要对数据库进行任何修改，因此应该是安全的。
添加新表或修改参数时，您需要跟踪所做的任何更改，并运行针对生产站点镜像这些更改的脚本。
因此，目录更改成为可能的问题点。我建议只对实时站点进行这些更改（因为它们是标准数据）并在使项目可见之前检查项目的配置。您还可以清除产品（但不是销售）的特定表并从测试数据库重新加载它们，但这将使您的网站在同步时离线一段时间。
如果这没有表达您的观点，请发布有关需要填充的有问题的更改的更多详细信息。
谢谢，
乔
Fast answer: Magento enterprise is supposed to take care of this by allowing you to run staging sites and then sync content such as prices and products via the admin interface. I have not have total success with it, but the idea is there.
When it comes to code, you may still be able to use the environments without much difficulty. For instance, changing the appearance of your site or adding new plugins may not require any modification of the database and should therefore be safe.
When adding new tables or modifying params, you'll need to keep track of any changes that are made and run a script mirroring those changes against the production site.
So that leaves catalog changes as the likely problem spot. I would advocate just making those changes to the live site (as they are standard data) and checking the configuration of the items before making them visible. You could also wipe out the specific tables for products (but not sales) and reload them from the test database, but this would take your site offline for a while whenever you sync.
If this misses your point, please post more detail about a problematic change that needs to be populated.
Thanks,
Joe
使用 GIT，创建远程分支、生产分支、发布分支，保持最新状态，并在需要时合并。您可以找到更多信息：http://git-scm.com/ 和 http://github.com/
Use GIT, create remote branches, your production branch, release branch, keep it up to date, merge when it's needed. You can find more: http://git-scm.com/ and http://github.com/