案例研究：硬件集群.vs.复制-数据库

以下是基于Tier 1银行的真实情况。我们使用的是Sybase 工具，例如ASE和Replication Server，但是这个案例也非常适用于其他的引擎，如带有数据防护(Data Guard)的Oracle等。

我去年在一家大银行工作，我们有一段损失惨重的经历，最后由复制挽救了我们。现在，我深信任何的基于硬件的解决方案，例如集群，无论如何也比不上基于软件的解决方案，例如复制。只要你稍微具有一点灵活性和思想就能获得同样的效果的时候，为什么花费大量的金钱在硬件集群上呢?我会在以下的内容中阐述我的观点。

Peter Thawley 的一篇名为《互联网时代的高可用性》("High Availability in the Internet Age")的文章中的观点非常吸引我。这篇文章发表在国际Sybase用户组织(ISUG)杂志的1999 第三版上。作者提出，eBay所遇到的不能正常运行的时间就是硬件错误导致的Oracle数据库错误引起的。装载Oracle数据库花了大约24小时，与此同时，公司损失了大量收入。不论是什么引起了这次的故障时间，其中有一个就可能是体系结构和为此错误承担责任的数据库管理员。虽然错误是由于硬件的问题，很少是由于冗余(redundancy)和镜像(mirroring)，但是它们确实可能会引起这种情况。

我所工作的银行有一个交易系统，已经运行了两年。它具有较大的数据库，大概有70GB，使用的是Solaris 2.7 and Sybase 11.9.2 (按照今天的标准就是石器时代了)。他们非常努力地为这个数据库去创建一个合适的防范业务风险机制(business contingency，BC)。关键问题就是一个交易必须要写入数据库并且使用者界面要在3秒钟内显示出来交易条目的确认信息。这个系统必须具有处理每小时6万个交易输入复制的能力，并且从产品到BC的交易传递必须要以能够最小化或者消除所有的交易损失的方式进行设计。系统还必须机有支持300个在线交易人的能力。

在网站的两个星期里面，我们使用Sybase复制创建了业务持续性系统，具有处理以上关键问题的能力。到了11月的中期，我们将系统投入产品和客户端在周末做了一些初始化的测试，确认了复制间断性的工作以及交易传递到BC站点上。有趣的就是这个故事剩下的部分。

在一个决定性的工作日的下午，灾难来临了，数据服务器的硬件出现了问题。Sybase错误日志开始发送如下的信息:

00:00000:00000:2003/xx/xx xx:xx:xx.xx kernel sddone: write error on virtual
disk 2 block 8601952:
00:00000:00000:2003/xx/xx xx:xx:xx.xx kernel sddone: I/O error
09:00000:00757:2003/xx/xx xx:xx:xx.xx server Error: 694, Severity: 24,
State: 10
09:00000:00757:2003/xx/xx xx:xx:xx.xx server An attempt was made to read
logical page '11311459', virtpage '42156387' from virtual d
evice '2' for object '1723869208' in database '5'. The page was not read
successfully. You may have a device problem or an operating
system problem.
00:00000:00006:2003/xx/xx xx:xx:xx.xx server Error: 823, Severity: 24,
State: 2
00:00000:00006:2003/xx/xx xx:xx:xx.xx server I/O error detected during wait
for BUF pointer = '0xb8b3d5a0', MASS pointer = '0xb8b3d5
a0', (Buf#: '0'), page ptr = '0x9801c000', dbid = '5', Mass virtpage =
'42156384', Buffer page = '11311456', Mass status = '0x4689110
0', Buffer status = '0x1', size = '16384', cache (id: 0) = 'default data
cache'.
09:00000:00757:2003/xx/xx xx:xx:xx.xx kernel

ASE运行在E4500 服务器上，有两台Sun A5200阵列用于数据存储。问题就是一个完全的阵列由于一个磁盘的错误而是去了控制!你可以对找个原因进行争辩。然而，它看上去就像是这个类型的阵列的内在设计问题。(在A5200的三个特定的磁盘插槽上，你需要插入磁盘。这些磁盘习惯重复发送“fcal”信号，并且其中的一个错误和fcal信号没有达到的时候，阵列就会出现问题。)因为我们有两个阵列，我们期望镜像阵列可以挽救我们。不幸的是，这种情况没有出现。

问题是虽然存储阵列中的一个已经失去了控制，Sybase设备被重新安置在一个卷上，在这个卷上含有损坏的磁盘和它的镜像在同一个阵列中。依次追踪到了几个月之前在一个阵列中做了热交换的Veritas ，这就是最初收到影响的磁盘。由于人的错误，这个问题一直没有检测出来或者是被忽略了。所以当单个阵列在写入数据的过程中失败的时候，交易数据库中就出现了一个洞。

我想要指出的一点是有关我们进行恢复的速度。我们检测了BC数据库以及在崩溃之前2分钟写入数据库的最后的交易条目。计数器显示这个交易条目确实是最后已过进入交易系统的交易。在这个情况下，我们能做的就是交换接口文件并请求用户重新开启他们的应用程序。当我们对BC数据库进行完整的测试，系统又显示良好了，所以这个信号又关闭了!

最根本的问题就是是否以硬件级别的磁盘镜像形式出现的硬件冗余可以对数据库提供完善的保护。许多组织都倾向于使用局域(传统的磁盘镜像)或者广域(存储区域网络)硬件镜像来创建冗余和弹性。例如，EMC的SRDF就是一个硬件层次上对距离进行了扩展的冗余解决方案。作为一个选项，软件复制可以被采用。我将在下面解释我为什么倾向于软件解决方案。

作为一名从业人员，我一直认为以数据复制的方式(虽然在某种程度上是异步的)完成的软件高可用性(HA)解决方案优于基于硬件的磁盘到磁盘景象。下面我提出的论据是基于如下的公理，即虽然数据库是构建在文件系统或者原始分区上，他们的根本行为是以纯粹的文件系统不同的方式进行。实际上，假设磁盘到磁盘、比特到比特的镜像会对你的数据提供充分的保护的观点是过于简单化了。

高可用性磁盘到磁盘镜像最常见的形式就是为了从基本磁盘到镜像磁盘的比特到比特的数据拷贝设计的。只要两个磁盘所处位置之间的距离不是太大，并且在两个站点之间由GB级别的快速连接存在，写入就几乎是同时发生的。第一眼看过去，这样的解决方案看起来是完美的;他们几乎可以是可以立即产生效果的。在本地或者远程聚簇上面应用这样的解决方案，我们可以得到数据的高可用性。

在实际中，数据库比一个单纯的逐个比特拷贝要复杂得多。数据库引擎在基于进程的RDBMSZ，例如Oracle中，通过后台进程，或者在基于线程模型的数据库，例如Sybase中，通过内部进程执行了许多任务。这些进程执行例行任务，例如检测点和那些维护数据库必需的事务日志和数据的冲洗，但是实际上这些都与数据的可用性没有关系。换句话说，大多数此类形式的数据都不需要被拷贝或者复制。比较而言，在基于数据复制的高可用性设计中，这些多余的数据永远不会被复制，因为人们认为它对于BC数据库而言实际上并不需要。这就给我们指出了软件复制是如何与硬件镜像区别开来的。

复制的形式通常是在表级别上的事务(插入、更新和删除)，从一个源数据库到一个或多个目标数据库。比起硬件镜像，它基本上要么是全部要么是一点也不，但复制:

将数据从一个源移动到另一个。

只将一部分数据子集从源移动到目标。所以你可以描述数据的子集;例如，复制被选中的表。

在从源移动到目标的过程中，允许处理/转换数据。

这指出了使用复制技术获得可用性的另一个好处。通常客户们使用磁盘镜像和磁盘快照技术来维护热数据库，通常付出较高的成本。这些技术在实际问题方面，例如磁盘上的坏扇区，效果良好。然而，如果有I/O设备或者数据库管理软件层上由于软件错误发生的数据损坏，这个损坏只会简单地传播到远端的设备上!由于Sybase Replication Server 是在逻辑层通过将事务转换为复制服务器上面的SQL 操作进行处理，那么这个风险就被完全避免了。