Baron Schwartz创建了一个关于MMM使用情况的讨论，并迅速转向到一般集群的辩论，正如Florian Haas在他的博客上写的，这不仅仅是DRBD与MySQL复制进行对比的问题。

　　你认为通过一些像MMM等零碎的东西拼凑起来的方案是数据库集群吗?或者是整合了一些东西我们就可以叫它集群了吗?这是决定开源数据库集群未来的核心问题。

　　我个人对这个问题非常感兴趣，我设计的Tungsten集群认为答案就是两个最根本的变化。首先，集群解决方案在不断发展演变，反过来，它会对现有的集群产生非常大的变化;第二，对于大部分用户而言，新的集群方案要比从多个独立的块构建起来的解决方案要好得多。

　　要知道为什么，让我们从人们使用开源数据库的历史谈起吧，为什么过去十年左右他们一直关心集群，开源数据库有广泛的用户，小到中型业务应用如内容管理系统是一个非常大的部分，大型网站如Facebook或GameSpot是另一类例子。有大量的定制应用介于两者之间，它们不适合使用单个采用双核或四核CPU的数据库，但使用2-4台服务器就完全没有问题了。

　　很长一段时间以来，部分用户引入集群主要是基于两方面的考虑：确保可用性和提高性能。对于跨集群的分散处理，小型商务机是一个很好的解决方案，MySQL复制的也常常用在多主机集群上，但这一技术在过去几年得到较大的改变。

　　改变的理由很简单：硬件。多核架构、便宜的内存和闪存不仅改变了数据库的成本，同时还改变了数据库计算的基本方法，从1991年到现在，内存的价格发生了天翻地覆的变化。例如，在两年之内在固态硬盘上建立大型数据库是完全可能的，假设有合理的软件支持随机读写磁盘将会接近内存的速度，极其便宜的磁盘归档已经在互联网上传播开来，离线磁带的成本下降到快要崩溃的边缘。

　　此外，开源数据也开始跟上硬件的发展水平，在MySQL社区，MySQL 5.4和Drizzle主要集中在多核扩展上，PostgreSQL已经攻克了这个问题，商业供应商如Schooner真在推进定制设备，集成新的硬件要比用户自动做要好得多，并提高了数据库启动时的性能改善。

　　有了多核的利用，加上便宜的内存和固态硬盘，对于绝大多数用户而言，一台数据库主机上基本上就能提供足够的运行性能，不用再在每个节点上部署2-4台服务器了。换句话说，性能可伸缩正在迅速成为用户群越来越关注的问题，这些用户并不需要无限的性能，只要满足他们的需要即可。

　　未来几年基于三个方面的原因，会促进开源MySQL数据库集群的发展：

　　1、 可用性

　　保持数据库的可用性一直以来都是开源数据库用户关注度最高的一个方面，这不是猜测的，自2006年以来，我和成千上万的人都谈过这个问题，并且大多数用户都希望不用经过大量的集成和配置就可以开始运行。

　　2、 数据保护

　　数据丢失是一件糟糕的事情，大多数用户都希望每隔几分钟就对数据做一次拷贝，这样就不用担心什么时候发生大的数据丢失了。异地保护也相当受推崇，不信你可以找任何一个DBA谈谈这个问题。

　　3、 硬件利用率

　　随着硬件成本的下降，关注前端硬件投资正变得有些过时，现在重点需要考虑的是运营成本，我们先来看看功耗，假设有一台双核CPU主机功率是250W，我们就需要一倍的功率用来冷却和其它消耗，按照最近加州的电价计算，一年大约需要600美元的电费，电力只是其中一部分业务开支。

　　继续来看数据库集群的未来：肯定会大量存在。但现有的集群需要满足开源数据库在效率和成本方面新的需要，但从紧耦合的主/主模式到共享磁盘的如Postgres-R和RAC将会完全不一样。相反，我们将看到更多主/从复制的扩展性，为了符合大众市场的需要，它们需要涵盖下面这些特性：

　　1、 简化管理和监视

　　关于集群最大的抱怨是它复杂难懂。如果你使用主/从方式代替了其它复杂的方式，那这个问题是可以解决的。你可以基于业务规则使用简单可配置的策略来控制失效切换，使用作业管理队列调度周期性任务，如备份。

　　2、 快速、灵活的复制

　　大型服务器会造成大型的更新负载，单一的从服务器肯定受不了，要么需要并行数据库复制，要么需要磁盘级的方法，如PostgreSQL 8.5的日志流/热备或DBRD。许多用户都需要同步复制，跨站点复制也越来越常见。最后，复制方法需要可插拔的，因为不同的复制方法有不同的长处。复制本身只是集群解决方案的一部分，不管复制类型如何，大部分都是相同的。

　　3、 自顶向下的数据保护

　　简化备份是一个良好的开端，异地数据存储，自动数据一致性检查和数据修复是必要的功能。大多数集群和复制框架都很少或没有提供这方面的功能，对于集成数据保护的用户将从新的集群方法获得巨大的好处。

　　4、 分区管理

　　在不远的将来，大多数应用程序都只需要单一的数据库服务器，但大多数组织都有多个应用程序，而对于互联网服务供应商来说则可能有成千上万个，我们必须要为数据库指定分区，并允许应用程序透明地找到它们，这种大规模的水平分区是单个应用数据库运行在单一主机上遗留下来的问题。

　　5、 云和虚拟化操作

　　长远来说，虚拟化是硬件利用率问题的最简单的治疗方案，比其它方法更简单和透明，目前已有很多应用运行在ISP的虚拟机或云环境中，为了能够在虚拟环境下运行，数据库集群必须只能是软件，安装简单，要最低限度占用资源，同时，还需要支持无缝数据库配置，并具有可伸缩的能力，如添加一个新的虚拟机，或在现有4核心虚拟机上增加到8核心，同时按需增大内存。

　　6、 透明应用程序访问

　　应用程序要能够使用常见的API无缝连接到集群，并且无需更改SQL，对于采用简单的主/从式或磁盘块方法实现的集群要比其它更复杂的方法实现的集群要更容易做到，同时，应用程序访问需要能够处理简单的基于性能的路由，如指导报告或备份副本数据库。

　　7、 开源

　　由于种种原因，闭源集群对于开源市场而言注定会是厄运，基础的集群组件必须开源，其中部分依赖于现有的用于存储和数据库日志级的开源技术，通过开放源码的方式创造大众市场解决方案。

　　前面我已经说过，我们正在构建Tungsten，Tungsten的目标是让越来越多的应用程序运行在单一数据库上，当然，我们也会提升数据库性能，但我们认识到久而久之其它问题也会来临，上面描述的技术属性还是容易实现的，我们已经实现了一部分功能，不久将会更加完善。主/从集群模式不仅是可行的，对于大多数用户它都工作得很好。

　　目前许多应用程序都有严重的性能问题，现有的软件不能满足需要。Facebook和其它大型站点将会继续使用大规模的，定制的MySQL集群以及非SQL方法。分析和报告业务将继续需要越来越大的数据库，并要求具有并行查询和自动分区的功能。有一些特殊的应用程序，如Telco，需要一个紧密耦合的集群，这种环境下可能需要重新改写应用程序，这是高端市场的特殊情况。

　　大部分用户需要更简单的，更实际的东西，假设选择了结合大量技术，如MMM，各种备份方案，cron作业，Maatkit等组成的综合方案，有些人可能会不知从何下手，硬件功能的转变和对应数据库的改进是集群解决方案的发展趋势，如Tungsten就是切实可行的实现，它包括了用户的实际需要，并是完全集成的。我打赌大部分用户会认为这就是数据库集群的未来。

　　p.s.我在Tungsten上已经工作了很长的一个夏天了，我们正努力工作，为了能够在9月7日发布一个完整的开源集群解决方案。关于Tungsten的更多信息，请去该项目的主页http://tungsten.sourceforge.net/获取信息。

　　原文出处：http://scale-out-blog.blogspot.com/2009/09/future-of-database-clustering.html

　　原文名：The Future of Database Clustering

　　作者：ROBERT HODGES