我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我已经在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。它鼓励使用迁移脚本。在每个版本中,我们将更改脚本合并到一个文件中,以简化理解,并允许dba“支持”更改。
其他回答
我已经开始研究sqlHawk,它的目标是围绕这个问题提供(开源)工具。
它目前处于相当早期的阶段,但已经支持存储和执行存储过程以及运行脚本更新。
如果有任何人有时间看这个工具,我将非常感激。
为公然的自我推销道歉,但我希望这对某人有用!
是的,我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制,所以我们可以恢复到任何带标签的版本。
我们还有ant任务,可以在需要时重新创建db。
此外,SQL还被标记为与之配套的源代码。
我有一切必要的重新创建我的数据库从裸露的金属,减去数据本身。我相信有很多方法可以做到这一点,但我所有的脚本等都存储在subversion中,我们可以通过将所有这些从subversion中取出并运行安装程序来重建DB结构等。
是的,总是这样。您应该能够在需要时使用一组有用的示例数据重新创建生产数据库结构。如果你不这样做,随着时间的推移,保持运行的小改变会被遗忘,然后有一天你会被咬,严重的。这是一种保险,你可能认为你不需要,但当你这样做的那一天,它的价格是它的10倍!
“简短版本:将您的生产数据库转储到git存储库中,以实现即时备份解决方案。”