云计算时代的高可用数据库是可扩展、容错且与任何私有云或公共云兼容的数据库实例。它们旨在提供业务连续性，而不会因任何类型的硬件或网络故障而导致用户体验的影响。其核心设计原则是消除任何单点故障，并提供平稳的故障转移体验。
公共云和私有云使企业能够摆脱容易出错的传统架构，并运行具有可靠性为5个9和6个9的应用程序。业务应用程序可以按需、即时且经济高效地进行调整。数据库应用程序一直是所有企业基础设施的主要组成部分，但这些应用程序(特别是关系数据库)在使用云计算能力方面仍有很长的路要走。它们被设计为大型单片应用程序，当组织尝试以可扩展的方式可靠地运行它们时，将面临着相当大的挑战。
传统的分布式环境数据库通常部署为多个独立的数据库实例，具有统一查询的能力。对于测试/开发环境，生成数据库的许多物理副本在后台创建，导致数据蔓延。云计算与这些解决方案的集成是有限的：重点是数据的位置，而不是使用分布式系统的强大功能。让我们考虑针对高可用性和测试/开发数据库的情况解决这些问题的不同选项。
高度可用的数据库
云计算时代的高可用数据库是可扩展、容错且与任何私有云或公共云兼容的数据库实例。它们旨在提供业务连续性，而不会因任何类型的硬件或网络故障而导致用户体验的影响。其核心设计原则是消除任何单点故障，并提供平稳的故障转移体验。
主动/被动数据库副本
第一种选择是在主/副本体系结构中部署数据库，以便在任何给定时间单个主服务器提供数据库请求。复制策略使用数据库供应商的复制特性或外部第三方复制工具从主服务器同步复制数据。一旦主服务器发生故障，副本服务器就会接管并使用复制的数据在故障发生之前重新启动数据库。
这种方法可能会遇到数据库性能和可靠性问题。数据库操作将与这两个位置的网络一样快。第三方复制工具可能无法提供稳定的数据复制，并且可能在故障转移后使数据库处于不一致的状态。
内置高可用性的数据库
第二种选择是寻找提供内置高可用性的数据库解决方案。此功能在Noss数据库(如Cassandra和MongoDB)中更常见。它们从数据库层创建一致的数据副本，并启用容错数据库。然而，这种方法可能对许多企业不起作用，因为传统的关系数据库管理系统缺乏这种能力。此外，混合和多云复制通常不是这些解决方案的选择。
测试/开发数据库
克隆数据库是测试、开发和分析的共同要求。生产数据库始终在隔离的基础设施中运行，并且为备份、大数据分析和质量保证创建此数据库的一个或多个副本。
快照和克隆
要将数据库复制到另一个站点或云平台，操作人员可以获取快照并将其物理克隆到其他位置。这样做涉及设置策略，该策略定期获取数据库的快照。并将其克隆到预定义位置。用户需要像Oracle RMAN这样的解决方案，它可以跟踪快照之间的变化，采取一致的备份，并在需要时进行恢复。但是对于所有数据库都不存在这样的解决方案，并且使用远程数据中心和云平台来创建这样的克隆仍然是复杂的(如果可行的话)过程。
适用于私有云、混合云和多云的高可用存储
解决这些问题的更好解决方案是从存储层完全抽象数据库层，并让存储解决方案处理应用程序的高可用性。软件定义存储(SDS)可以通过提供不同类型的硬件和软件故障的数据保护来提供此功能。软件定义存储(SDS)还可以灵活地在后端使用任何类型的存储硬件，其中包括物理服务器和虚拟云实例。
这种方法的唯一缺点是投资于正确的解决方案，这种解决方案很容易与客户选择的数据库应用程序集成，并且还与其他数据库兼容以实现转换。此外，此类解决方案应该能够在任何私有云或公共云上运行，并且应该模糊内部部署和公共云位置之间的界限。
以下是这样的解决方案：
数据库即服务
社交媒体、投资、游戏等需要5个9或6个9的可用性，并采用全球可访问性的应用程序，需要最适合云端的整个数据库系统。数据库即服务(DBaaS)提供了一种在云中运行数据库的简便方法，可以节省购买服务器、构建基础设施和构建大型团队来管理这些数据库的时间。供应商提供多种方式来使用数据库即服务(DBaaS)产品，例如安装了数据库的虚拟机，DB Schema即服务以及具有专用硬件的数据库，用于RDBMS以及NoSQL数据库。
在考虑任何基于云计算的数据库安装时，必须解决以下问题：
(1)供应商锁定：每个提供商都有自己的业务流程框架，这使得消费者更难从一个提供商转移到另一个提供商。
(2)数据同步：总是需要外部工具以一致的方式将数据从一个位置复制到另一个位置。这些工具通常具有破坏性，昂贵且复杂，并且它们构成了跨越多个位置和环境的巨大瓶颈。
(3)云计算成本分析：决定在云平台中应该使用哪些应用程序和数据之前，应该进行仔细的预算分析。如果不设计混合云，其预算很容易失控，同时要记住为了获得简单性和灵活性需要付出代价。
迄今为止，数据库已经存在了50多年，长期在传统的办公环境中成功运行。现在是企业通过采用云计算解决方案运行现代数据库来获得竞争优势的时候了。