开发者社区> 技术小甜> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

数据库集群系统研究系列(2)-现存的数据库的解决方案的原理解析

简介:
+关注继续查看

数据库

数据库集群

 

 

 

 


此种方式是异步串行复制或日志拷贝(Log Shipping)。主数据库完成事务处理后,生成事务处理日志,日志记录通过FIFO 队列,进入备份数据库处理,从而得到备份数据。此种方式的缺陷在于:
a. 复制队列溢出问题:主数据库是并行处理而日志拷贝是串行的,因此备份数据库处理日志记录也是串行的。因此,FIFO 队列的溢出随时可能发生。一旦发生,队列必须重建,从而需要重新建立备份数据库。此种方法对于一般客户来讲是不可行的。
b. 或者为了避免队列溢出,必须保证主数据库处理事务的速度小于备份数据库,这样将严重束缚主数据库的性能发挥。
c. 由于日志拷贝是异步的,主备数据库不是实时一致。因此无法用备份数据库作负荷均衡。
d. 由于主备数据库永远不一致, 主数据库一旦发生事故,就一定会丢失数据。在这种情况下,要么需要手工恢复数据库,这会消耗大量的人工成本,或者数据根本就不能恢复。


2.串行同步复制
此类集群往往是由昂贵的专用软硬件构成的,原理图如下:


 

 

此类系统采用专用的高速网络和软件技术,将每个数据库的请求,通过同步复制的方式,同步在主备两台数据库服务器上执行正确后,才将结果返回给数据库客户。

此系统的特点是:
a. 主数据库被强迫与备份数据库同步串行处理,因此性能受到限制。
b. 主备数据库中任意一个出现问题,都会迫使事务处理交易回滚,因此整个系统的可靠性比单机系统降低了一半。
c. 由于以上问题,这种备份方式只适用于近距离光纤网络(5 英里)。
d. 专用系统造价昂贵,又加上述明显缺陷,因此市场上很少被采用。

 

基于双机容错技术

从技术适应性的角度讲,双机容错比较适合于无状态应用,或者状态信息较少的应用切换,以此达到应用级的高可用性目的,其实并不适合于数据库级的应用切换。

 

 

 

此种结构往往是两个服务器共享一个磁盘阵列,这里两个服务器共享一个虚拟的IP 供数据库客户使用,形成一个单一的逻辑数据库映象。

此种所谓的数据库集群的目的是,一旦主机系统出现问题,备份系统通过心跳机制的检测,完成从主机系统到备份系统的切换,它有下列特点:

a. 此种高可用性解决方案只是无状态系统(典型的如Web 服务器)的普通容错切换思想在数据库领域的应用。
b. 此系统本身只有一个单一的数据映象,数据储存在共享的磁盘阵例上,因此共享的磁盘阵例成为了整个系统的单点错误源。
c. 由于是单一数据映象,因此必须采用通常的复制或备份方法获取第二份数据,以保证数据的安全性。因此所有复制或备份方法的缺点,此类系统全部存在。
d. 主机系统和备份系统之间是没有任何负载均衡关系的,在正常情况下,备份系统是闲置在那里,因此对用户来说是一种投资浪费。
e. 在错误切换的时候,往往存在切换时间长,而且更严重的是存在丢失用户交易数据丢失的现象,结果导致系统被迫停止服务,或者需要人工修复数据,或者数据永远找不回来。
f. 在错误切换的时候,有时候会发生备份系统的数据库启动不了的情况,这时候,整个数据库系统也就无法访问了,这与双机方案本身是高可用性方案的宗旨是相抵触的。

 

以RAC 为代表的系统

RAC 的英文全称是:Real Application Cluster(真正的应用级集群)。我们需要关注的是“应用级”。为了缓解数据库系统日益增长的性能压力,ORACLE 公司推出了RAC系统。它基本结构如下:


 

 

 

 


此类系统,专门是针对数据库性能问题而提出的。采用共享磁盘阵列的方式,因此在结构上和上述双机容错相似,不同的地方在于此系统中的数据库节点之间采用的不是简单的心跳检测,而是ORACLE 公司自己定义的一套复杂的信息交换协议,以此来动态分配来自数据库客户端的请求。它的特点是:

a. 是个应用级的集群,也就是针对ORACLE 的数据库管理系统(因为数据库管理系统对于操作系统来讲,就是一个“应用程序”,因此被称为“应用级集群”),专门为提高数据库性能而设计。
b. 此系统本身只有一个单一的数据映象,数据储存在共享的磁盘阵例上,因此享的磁盘阵例成为了整个系统的单点错误源。
c. 管理配置复杂。
d. 由于是单一数据映象,因此必须采用通常的复制或备份方法获取第二份数据,以保证数据的安全性。因此所有复制或备份方法的缺点,此类系统全部存在。
e. 由于数据库系统本身具有高I/O 的特性,因此,RAC 系统里,磁盘I/O 是提高性能的关键地方。

综合上所述,针对数据库系统普遍存在的三大方面的问题,上述各个技术和方案,各有不同的侧重,实现的代价和复杂度也各不相同,但是它们有共同的特点是:只解决数据库系统的某一方面的问题,甚至在解决这方面问题的时候,同时加重了另外一个或两个方面的问题

 

 























本文转自yanyangtian51CTO博客,原文链接: http://blog.51cto.com/yanyangtian/1152889
,如需转载请自行联系原作者


版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
2.0 解析系列 | 如丝般顺滑!一线运维人员谈如何实现数据库的平滑在线升级
OB君:9月21日,OceanBase 2.0 在云栖大会上重磅发布。我们将在接下来的时间里为大家持续推出 “OceanBase 2.0 技术解析系列” 文章,分别从 可运维性、分布式架构、数据可用性、性价比及兼容性 五个方面对OceanBase 2.0的产品新特性及其背后的技术原理进行深入的解析。
2202 0
libtool的工作原理
libtool 是一个通用库支持脚本,将使用动态库的复杂性隐藏在统一、可移植的接口中;使用libtool的标准方法,可以在不同平台上创建并调用动态库。可以认为libtool是gcc的一个抽象,其包装了gcc(或者其他的编译器),用户无需知道细节,只要告诉libtool需要编译哪些库即可,libtool将处理库的依赖等细节。
1056 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
数据库智能优化系统的探索与实践
立即下载
重新出发:阿里云数据库开源整体策略
立即下载
阿里巴巴数据库智能优化系统探索与实践
立即下载