数据库集群系统研究系列(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
,如需转载请自行联系原作者


相关文章
|
运维 监控 关系型数据库
AI 时代的 MySQL 数据库运维解决方案
本文探讨了大模型与MySQL数据库运维结合所带来的变革,介绍了构建结构化运维知识库、选择合适的大模型、设计Prompt调用策略、开发MCP Server以及建立监控优化闭环等关键步骤。通过将自然语言处理能力与数据库运维相结合,实现了故障智能诊断、SQL自动优化等功能,显著提升了MySQL运维效率和准确性。
1095 18
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
存储 NoSQL 数据库
Redis 逻辑数据库与集群模式详解
Redis 是高性能内存键值数据库,广泛用于缓存与实时数据处理。本文深入解析 Redis 逻辑数据库与集群模式:逻辑数据库提供16个独立存储空间,适合小规模隔离;集群模式通过分布式架构支持高并发和大数据量,但仅支持 database 0。文章对比两者特性,讲解配置与实践注意事项,并探讨持久化及性能优化策略,助你根据需求选择最佳方案。
1277 5
|
Cloud Native 关系型数据库 分布式数据库
阿里云PolarDB与沃趣科技携手打造一体化数据库解决方案,助推国产数据库生态发展
阿里云瑶池数据库与沃趣科技将继续深化合作,共同推动国产数据库技术的持续创新与广泛应用,为行业生态的繁荣注入更强劲的技术动力。
阿里云PolarDB与沃趣科技携手打造一体化数据库解决方案,助推国产数据库生态发展
|
运维 监控 关系型数据库
AI 时代的 MySQL 数据库运维解决方案
本方案将大模型与MySQL运维深度融合,构建智能诊断、SQL优化与知识更新的自动化系统。通过知识库建设、大模型调用策略、MCP Server开发及监控闭环设计,全面提升数据库运维效率与准确性,实现从人工经验到智能决策的跃迁。
1301 27
|
存储 缓存 自然语言处理
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
482 8
评论功能开发全解析:从数据库设计到多语言实现-优雅草卓伊凡
|
SQL 安全 关系型数据库
数据库安全管理新范式:DBKEEPER一体化数据库权限管控堡垒机解决方案
在数字化时代,数据库安全至关重要。DBKEEPER提供一站式数据库安全访问与权限管控解决方案,支持多种数据库,具备精细化权限管理、数据脱敏、高危操作拦截、全面审计等功能,助力企业实现智能、安全的数据治理,满足金融、医疗、互联网等行业合规需求。选择DBKEEPER,让数据库安全管理更高效!
数据库安全管理新范式:DBKEEPER一体化数据库权限管控堡垒机解决方案
|
Cloud Native 关系型数据库 分布式数据库
客户说|知乎基于阿里云PolarDB,实现最大数据库集群云原生升级
近日,知乎最大的风控业务数据库集群,基于阿里云瑶池数据库完成了云原生技术架构的升级。此次升级不仅显著提升了系统的高可用性和性能上限,还大幅降低了底层资源成本。
|
存储 关系型数据库 数据库
高性能云盘:一文解析RDS数据库存储架构升级
性能、成本、弹性,是客户实际使用数据库过程中关注的三个重要方面。RDS业界率先推出的高性能云盘(原通用云盘),是PaaS层和IaaS层的深度融合的技术最佳实践,通过使用不同的存储介质,为客户提供同时满足低成本、低延迟、高持久性的体验。

推荐镜像

更多
  • DNS