未来几年基于三个方面的原因，会促进开源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、 开源

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