我一直试图谨慎行事,不提前采用。我是 Enterprise Gold 订阅者。我为 Python/Django、Ruby on Rails 和 PHP(主要是 WordPress)分别建立了应用程序集群。(编辑:所有服务器都是 Linux。)我现在正在考虑冒险一试。我有多余的主机,所以我担心的不是转换的后勤问题。(除非您有 5.0 Master + 5.1 Slave 的恐怖故事要分享。)由于 Monty 的抱怨,我不太情愿,但我真的想要一些新功能。(尤其是 information_schema 的新增功能。)我是一名全职 DBA,所以我喜欢了解我的服务器和数据发生了什么。我在一家新闻机构工作,所以我们没有像普通 LAMP 用户那样经历停机时间的自由。感觉 5.1 的时代已经到来了。
你說什麼?
答案1
如果你有令人信服的理由,那么当你被授权花费(大量)时间时就去做吧。如果我是你的老板,我会想知道花费大量时间和风险的真正好理由。
升级像 MySQL 这样的组件将是一项艰巨的工作,尤其是性能测试。
无论如何,这实际上取决于您的应用程序被自动化测试用例覆盖的程度,以及您的发布流程的复杂程度。但升级数据库听起来像是需要进行所有可能的测试的事情。
您至少需要对应用程序的关键部分进行性能测试,并进行一些浸泡/压力测试,以确保您不会以某种方式使用它,因为随着时间的推移会导致机器崩溃。
根据您拥有的数据量(以及您的应用程序的冗余/停机时间要求;您的维护窗口有多大等等),转换的物流可能会或可能不会成为问题。
我想说的是,测试比迁移的后勤工作要困难得多,即使后勤工作并不简单。我最近从 4.1 升级到了 5,这个项目花了大约 6 个月的时间,主要是因为测试很困难。不过,我们几乎没有发现由 MySQL 升级引起的错误。