CN104536971A - 一种具备高可用性的数据库 - Google Patents
一种具备高可用性的数据库 Download PDFInfo
- Publication number
- CN104536971A CN104536971A CN201410722383.3A CN201410722383A CN104536971A CN 104536971 A CN104536971 A CN 104536971A CN 201410722383 A CN201410722383 A CN 201410722383A CN 104536971 A CN104536971 A CN 104536971A
- Authority
- CN
- China
- Prior art keywords
- database
- redo
- data base
- master data
- standby
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1446—Point-in-time backing up or restoration of persistent data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/284—Relational databases
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Mining & Analysis (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
本发明实施例公开了一种具备高可用性的数据库,包括至少两组集群,所述的集群通过网络连接,所述的集群包括至少一个节点和至少一个存储装置;其中,所述的一组集群为主数据库,其余集群为备份数据库。本发明实施例所提供的具备高可用性的数据库能够使得数据库系统中多节点负载均衡,可以用多个廉价PC服务器代替昂贵的小型机或大型机,节约硬件及维护成本,具有高扩展性;同时采用了多个共享存储设备,当主数据库不能正常工作时,可以切换备份数据库进行服务减少了服务停止时间,并且数据不会丢失。
Description
技术领域
本发明涉及数据库领域,尤其涉及一种具备高可用性的数据库。
背景技术
随着现代计算机科学技术的发展,数据库已逐步成为计算机信息系统的基础和核心,被广泛应用于电信、金融、政府、企业、能源等关键行业。数据库应用的高可用性也越来越引起人们的关注。在高可用的解释方面,有人给出了如下的诠释:
(1)系统失败或崩溃(system faults and crashes);
(2)应用层或者中间层错误(application and middleware failures);
(3)网络失败(network failures);
(4)介质失败,一般指存放数据的媒体故障(media failures);
(5)人为失误(Human Error);
(6)容灾(Disasters and extended outages);
(7)计划宕机与维护(Planned downtime,maintenance and managementtasks)。
由此可见,高可用不仅仅包含了系统本身故障,应用层的错误,人为错误等等,还应当包括数据冗余、容灾以及计划的维护时间,也就是说,一个真正的高可用环境,不仅仅是能避免系统本身的问题,还应当能防止天灾人祸,以及有一个简单可靠的系统维护方法(如硬件升级、软件升级等等计划停机维护)。
对于oracle数据库来说,一般采用的是双机热备的方式达到高可用性。如图1所示,常用的做法是采用两台(或多台)服务器,使用共享的存储设备(磁盘阵列柜或存储区域网SAN)。两台服务器系统A(SYSTEM A)与系统B(SYSTEM B)可以采用互备、主从、并行等不同的方式。在工作过程中,两台服务器将以一个虚拟的IP地址对外提供服务,依工作方式的不同,将服务请求发送给其中一台服务器承担。同时,服务器通过心跳线(listener)侦测另一台服务器的工作状况。当一台服务器出现故障时,另一台服务器根据心跳侦测的情况做出判断,并进行切换,接管服务。对于用户而言,这一过程是全自动的在很短时间内完成,从而对业务不会造成影响。由于使用共享的存储设备,因此两台服务器使用的实际上是一样的数据,由双机或集群软件对其进行管理。这方式的优点是有利于数据库的升级,当其中系统A需要升级的时候,就把服务切换到系统B上运行,升级A的oracle程序,之后还可以把服务切换回到A来,然后升级B的oracle程序。这个升级过程不会影响用户的oracle使用,因为总有一台机器可以使用oracle程序来响应用户的服务请求,同时由于保存了两份数据库的数据文件,这样如果其中一台服务器出现了数据损坏或者文件丢失,也不会因为单点故障导致数据无法恢复了。
虽然oracle的双机热备机制可以解决单点故障和数据安全等问题,但是其自身的局限性和缺点也尤为明显,存在的问题有如下几个方面:
(1)只有一台机器发挥作用,另外的机器浪费投资;
(2)性能相对较差,单一数据库无法承担大量的并发操作;
(3)实际成本更高;
(4)发生故障时,需要切换时间,并不是真正24X7不间断运行;
(5)扩展性差,每添加一个节点必须停掉所有的服务器。
发明内容
有鉴于此,本发明实施例提出一种具备高可用性的数据库,以实现对应提高数据库的可用性。
本发明实施例提供了一种具备高可用性的数据库,所述的具备高可用性的数据库包括若干个节点及共享存储设备,所述的共享存储设备至少为两个,所述的至少两个的共享存储设备中一个为主数据库(Primary Database),其余共享存储设备为备用数据库(Standby Database)。
本发明实施例所提供的具备高可用性的数据库能够使得数据库系统中多节点负载均衡,可以用多个廉价PC服务器代替昂贵的小型机或大型机,节约硬件及维护成本,具有高扩展性;同时采用了多个共享存储设备,当主数据库不能正常工作时,可以切换备份数据库进行服务减少了服务停止时间,并且数据不会丢失。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本发明的其它特征、目的和优点将会变得更明显:
图1是现有技术所提供的双机热备的数据库结构示意图;
图2是本发明实施例所提供的集群的逻辑结构示意图;
图3是本发明实施例所提供的集群的物理结构示意图;
图4是本发明实施例一所提供的具备高可用性的数据库的结构示意图;
图5是本发明实施例二所提供的具备高可用性的数据库中的主数据库与备用数据库同步方法的流程示意图;
图6是本发明本发明实施例二所提供的具备高可用性的数据库中的主数据库与备用数据库同步方法的示意图。
具体实施方式
下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅用于解释本发明,而非对本发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与本发明相关的部分而非全部内容。
图2是本发明实施例一所提供的集群的逻辑结构示意图;图3是本发明实施例一所提供的集群的物理结构示意图;图4是本发明实施例一所提供的具备高可用性的数据库的结构示意图。
图2是本发明实施例一所提供的集群的逻辑结构示意图,由图2可以看出,集群可以由若干个物理计算机组成(每个叫做一个节点),这些节点间通过网络连接(心跳网络)。每个节点上都运行一个实例(Instance),这些实例通过一个特殊的软件(Clusterware,集群软件)的协助,共同操作一个数据库。从外部用户视角看,他们看到的只是一个数据库。从逻辑上看,集群由存储层、网络层、集群件层、应用层4层组成。集群软件可以采用Oracle RAC,可以支持24x 7有效的数据库应用系统,在低成本服务器上构建高可用性数据库系统,并且自由部署应用,无需修改代码。在Oracle RAC环境下,Oracle集成提供了集群软件和存储管理软件,为用户降低了应用成本。当应用规模需要扩充时,用户可以按需扩展系统,以保证系统的性能。Oracle RAC有以下优点:
(1)多节点负载均衡;
(2)提供高可用:故障容错和无缝切换功能,将硬件和软件错误造成的影响最小化;
(3)通过并行执行技术提高事务响应时间;
(4)通过横向扩展提高每秒交易数和连接数;
(5)节约硬件成本,可以用多个廉价PC服务器代替昂贵的小型机或大型机,同时节约相应维护成本;
(6)可扩展性好,可以方便添加删除节点,扩展硬件资源。
图3是本发明实施例一所提供的集群的物理结构示意图,由图3可以看出RAC集群实际上是实例级别的容灾,但是各个实例在后台与共享存储器(SHARESTORAGE)连接,其仍然只使用了一份数据文件(DATAFILE),通常这份DATAFILE保存在磁盘阵列这样的共享存储器里面,如果由于未知的原因一个节点出现了错误宕机了,这个时候RAC的另外一个节点会通过INSTANCE RECOVERY的方式构建GRID并且访问宕机节点的日志文件(LOGFILE)进行恢复,达到数据的0损失。但是如果数据文件出现了错误,即使节点再多也无计可施。
图4是本发明实施例一所提供的具备高可用性的数据库物理结构示意图;。
参见图4,本发明实施例采用的是安装4台oracle软件的服务器,2台存储,其中的两台服务器与一台存储形成一个集群,另外两台服务器与另一存储形成另一集群,在每一集群内,所有服务器与存储互相通过网络连接。通过集群软件设置集群内每一台服务器为节点,使得每一集群都能构架成为一个独立的数据库。
通过相应的软件设置,可以将本实施例中的两个集群分别设定为主数据库(Primary Database)和备用数据库(Standby Database),主数据库及备用数据库的设定由用户自行随意设定,用户可以根据数据库相应的负载和服务器的相应性能自行选取。对于多个集群所组成的数据库,用户只需通过设定其中的一个集群为主数据库,其余的集群都可以设定为备用数据库,主数据库只能存在一个,备用数据库可以根据实际需要设定多个。
主数据库与备用数据库需要通过网络进行连接,为了保证主数据库和备用数据库随时可以通信,主数据库与备用数据库需要通过专用网络(DedicatedNetwork)进行连接,保证主数据库与备用数据库在在任何时候、任何地方,任何网络状况下都能够正常连接。出于同地点可能也会出现类似于自然灾害等不可控因素的考虑,两台存储可以分别部署在不同的地点(不同的城市)。
在正常运行状态下,主数据库处于开放(Open)状态对外提供服务,备用数据库处于恢复状态。用户可以在主数据库上进行操作,这些操作会被记录在联机日志和归档日志中。
如果是可预见因素需要关闭主数据库,比如软硬件升级,可以把备用数据库切换为主数据库继续对外服务,这样即减少了服务停止时间,并且数据不会丢失。如果异常原因导致主数据库不可用,也可以把备用数据库强制切换为主数据库继续对外服务。
本发明实施例通过构建多个集群,并将多个集群通过网络连接,并分别设置集群为主数据库和备份数据库,能够在正常工作状态下使得每一个节点都负载均衡,能够在主数据库的集群中n-1个节点发生故障的情况下保证数据库能够正常访问。可以及时的将主数据库上的数据及时备份到备用数据库上,并在主数据库无法提供服务时,可以通过备用数据库进行还原,并且可以及时将业务切换到备用数据库上去,不影响用户正常使用;在备用数据库集群中n-1个节点发生故障的情况下也可以正常备份数据库,在整个数据库只有一个节点正常工作,也可以保证系统的正常运行。
图4示出了本发明的第二实施例。
图5是本发明实施例二所提供的高可用数据库的同步方法的流程图;图6是本发明本发明实施例二所提供的具备高可用性的数据库中的主数据库与备用数据库同步方法的示意图。所述的高可用数据库以本发明实施例一所提供的高可用数据库为基础,进一步的,提供了所述的高可用数据库中主数据库与备用数据库同步方法。
参见图5及图6,所述的高可用数据库中主数据库与备用数据库同步方法包括:
步骤S201,主数据库发送产生的重做(Redo)日志。
重做信息(redo)是Oracle在在线(或归档)重做日志文件中记录的信息,记载了所有数据的改变。主数据库在运行过程中,会源源不断地产生Redo日志,采用LGWR后台进程将日志内容写入,LGWR的作用是把日志缓存区的数据从内存写到磁盘的REDO文件里,完成数据库对象创建、更新数据等操作过程的记录。一般设定的LGWR的触发条件为:
在事务提交的时候(COMMIT)
Redo Log Buffer三分之一满
Redo Log Buffer多于一兆的变化记录。
此外,也可以采用ARCH进程来完成,ARCH就是负责在重做日志文件切换后将已经写满的重做日志文件复制到归档日志文件中,以防止循环写入重做日志文件时将其覆盖。所以,只有数据库运行在归档模式时,这个ARCH进程才会被启动。主数据库可以通过REDO传输服务(Redo Transport Services,RTS)将redo数据的传输到一个或多个备用数据库。
步骤S202,备用数据库接收主数据库发送的Redo日志。
备用数据库中的的RFS(Remote File Server)进程负责接收主数据库传输的redo日志,在RFS进程接收到日志后,会将日志写到备用重做日志(StandbyRedo Log)或者归档日志(Archived Log)文件中。如果通过RFS进程接收主数据库的redo日志,保存在本地,就是备用重做日志(Standby Redo Log),备用数据库的ARCN再将其写入归档,就是备用数据库的归档重做日志(archived redo logs)。
步骤S203,备用数据库重演所接收到的主数据库发送的Redo日志。
备用数据库采用应用日志应用服务(Log Apply Services),将数据重做到备用数据库,以保持与主数据库的事务一致。重做数据即可以从备用数据库的归档文件中读取,也可以在实时应用打开的情况下直接应用备份重做日志(standby redo log)文件。
根据备份数据库重演日志方式的不同,可分为物理备份(PhysicalStandby)和逻辑备份(Logical Standby)。
物理备份使用的是介质恢复(Media Recovery)技术,在数据块级别进行恢复,这种方式没有数据类型的限制,可以保证两个数据库完全一致。物理备份数据库只能在挂载(Mount)状态下进行恢复,也可以是在打开状态,但只能以只读方式打开,并且打开时不能执行恢复操作,此时standby数据库仍然可以继续接收redo数据,不过并不会触发操作,直到数据库恢复redo应用。即在打开状态下不能应用日志。也就是说read-only模式时不能执行redo应用,redo应用时数据库肯定处于未打开状态。
物理备份提供了一个健全而且极高效的灾难恢复及高可用性的解决方案。更加易于管理的角色转换及最更短的计划内或计划外停机时间,应用物理备份数据库,能够确保即使面对无法预料的灾害也能够不丢失数据。由于物理备份是基于块对块的复制,因此与对象、语句统统无关,物理备份与主数据库完全一致。
逻辑备份是逻辑上与主数据库相同,结构可以不一致。逻辑备份通过sql应用与主数据库保持一致,也正因如此,逻辑备份可以以读-写(read-write模式打开,你可以在任何时候访问逻辑备份数据库。同样有利也有弊,逻辑备份对于某些数据类型以及一些数据定义语言(Data Definition Language,DDL)、数据操作语言(Data Manipulation Language,DML)会有操作上的限制。
Logical Standby使用的是Logminer技术,通过把日志内容还原成SQL语句,然后SQL引擎执行这些语句,Logminer Standby不支持所有数据类型,可以在视图DBA_LOGSTDBY_UNSUPPORTED中查看不支持的数据类型,如果使用了这种数据类型,则不能保证数据库完全一致。Logical Standby数据库可以在恢复的同时进行读写操作。
根据重做应用(Redo Apply)发生的时间可以分成两种:一种是实时应用(Real-TimeApply),这种方式必须备份重做日志(Standby Redo Log),每当日志被写入备份重做日志(Standby Redo Log)时,就会触发恢复,使用这种方式的好处在与可以减少数据库切换(Switchover或者Failover)的时间,因为切换时间主要用在剩余日志的恢复上。另一种是归档时应用,这种方式在主数据库发生日志切换,触发备份数据库的归档操作,归档完成后触发恢复。这也是默认的恢复方式。
根据上述同步方法,本发明实施例所提供的数据库通过软件设置允许定义3种数据保护模式,分别是最大保护(Maximum Protection),最大可用(MaximumAvailability)和最大性能(Maximum Performance)。
1、最大保护(Maximum Protection)
这种模式能够确保绝无数据丢失。要实现这一步当然是有代价的,它要求所有的事务在提交前其REDO不仅被写入到本地的在线重做日志(Online Redologs),还要同时写入到备份数据库的备份重做日志(Standby Redo logs),并确认重做数据至少在一个备用数据库中可用(如果有多个的话),然后才会在主数据库上提交事务。如果出现了什么故障导致备份数据库不可用的话(比如网络中断),主数据库会被挂起(Shutdown),以防止数据丢失。使用这种方式要求备份数据库必须配置备份重做日志(Standby Redo Log),而主数据库必须使用LGWR,SYNC,AFFIRM方式归档到备份数据库。
2、最高可用性(Maximum availability)
这种模式在不影响主数据库可用前提下,提供最高级别的数据保护策略。其实现方式与最大保护模式类似,也是要求本地事务在提交前必须至少写入一台备份数据库的备份重做日志(Standby Redo logs)中,不过与最大保护模式不同的是,如果出现故障导致备份数据库无法访问,主数据库并不会被挂起(Shutdown),而是自动转为最高性能模式,等备份数据库恢复正常之后,主数据库又会自动转换成最高可用性模式。这种方式虽然会尽量避免数据丢失,但不能绝对保证数据完全一致。这种方式要求备份数据库必须配置备份重做日志(Standby Redo Log),而主数据库使用LGWR,SYNC,AFFIRM方式归档到备份数据库。
3、最高性能(Maximum performance)
这种模式在不影响主数据库性能前提下,提供最高级别的数据保护策略。事务可以随时提交,当前主数据库的重做(REDO)数据至少需要写入一个备用数据库,不过这种写入可以是不同步的。如果网络条件理想的话,这种模式能够提供类似最高可用性的数据保护,而仅对主数据库的性能有轻微影响。这也是创建Standby数据库时,系统的默认保护模式。这种方式可以使用LGWRASYNC或者ARCH进程实现,备份数据库也不要求使用备份重做日志(StandbyRedo Log)。
本发明实施例通过主数据库发送产生的重做(Redo)日志,备用数据库接收主数据库发送的Redo日志,备用数据库重演所接收到的主数据库发送的Redo日志,能够使备份数据库与主数据库的数据同步,并且根据需要可以灵活采用物理备份或者逻辑备份。并根据主数据库与备用数据库数据同步,提供了最大保护(Maximum Protection),最大可用(Maximum Availability)和最大性能(Maximum Performance)三种保护模式,进一步提高了数据库的可用性。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
本领域普通技术人员应该明白,上述的本发明的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个计算装置上,或者分布在多个计算装置所组成的网络上,可选地,他们可以用计算机装置可执行的程序代码来实现,从而可以将它们存储在存储装置中由计算装置来执行,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样,本发明不限制于任何特定的硬件和软件的结合。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间的相同或相似的部分互相参见即可。
以上所述仅为本发明的优选实施例,并不用于限制本发明,对于本领域技术人员而言,本发明可以有各种改动和变化。凡在本发明的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (9)
1.一种具备高可用性的数据库,其特征在于:所述的具备高可用性的数据库包括至少两组集群,所述的集群通过网络连接,所述的集群包括至少一个节点和至少一个存储装置;其中,所述的一组集群为主数据库,其余集群为备份数据库。
2.根据权利要求1所述的具备高可用性的数据库,其特征在于:所述的集群通过专用网络连接。
3.根据权利要求1所述的具备高可用性的数据库,其特征在于:所述的主数据库与备份数据库放置在不同地点。
4.根据权利要求1所述的具备高可用性的数据库,其特征在于,所述的备用数据库为物理备份备用数据库或者逻辑备份备用数据库。
5.根据权利要求1所述的具备高可用性的数据库,其特征在于,所述的物理备份备用数据库与主数据库同步方法包括如下步骤:
主数据库发送产生的重做(Redo)日志;
备用数据库接收主数据库发送的Redo日志;
备用数据库重做所接收到的主数据库发送的Redo日志。
6.根据权利要求1所述的具备高可用性的数据库,其特征在于,所述的具备高可用性的数据库具有最大保护、最大可用和最高性能三种保护模式。
7.根据权利要求6所述的具备高可用性的数据库,其特征在于,所述的最大保护模式的实现方法为:
REDO数据在事务提交之前同时写到本地联机重做日志和至少一个备数据库上的备用重做日志;
在故障导致主数据库无法写REDO到至少一个事务一致性备数据库的备重做日志时,关闭主数据库。
8.根据权利要求6所述的具备高可用性的数据库,其特征在于,所述的最高性能模式的实现方法为:
事务提交时,将REDO数据写入到主数据库的本地联机重做日志;
将REDO数据写入至少一个备用数据库上的备用重做日志。
9.根据权利要求6所述的具备高可用性的数据库,其特征在于,所述的最大可用模式的实现方法为:
REDO数据在事务提交之前同时写到本地联机重做日志和至少一个备数据库上的备用重做日志;
在故障导致主数据库无法写REDO到至少一个事务一致性备数据库的备重做日志时,转入最高性能模式。
在故障消除,并且解决所有重做日志文件中的中断后,重新转入最大可用模式。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410722383.3A CN104536971A (zh) | 2014-12-02 | 2014-12-02 | 一种具备高可用性的数据库 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201410722383.3A CN104536971A (zh) | 2014-12-02 | 2014-12-02 | 一种具备高可用性的数据库 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN104536971A true CN104536971A (zh) | 2015-04-22 |
Family
ID=52852499
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201410722383.3A Pending CN104536971A (zh) | 2014-12-02 | 2014-12-02 | 一种具备高可用性的数据库 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN104536971A (zh) |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104852969A (zh) * | 2015-04-24 | 2015-08-19 | 昆明船舶设备集团有限公司 | Rac与hans高可靠系统融合 |
CN105159991A (zh) * | 2015-09-01 | 2015-12-16 | 北京皮尔布莱尼软件有限公司 | 一种保持数据一致性的方法、装置、系统和应用服务器 |
CN105573867A (zh) * | 2015-12-30 | 2016-05-11 | 浪潮(北京)电子信息产业有限公司 | 一种MySQL高可用性的实现方法及系统 |
CN106021019A (zh) * | 2016-05-12 | 2016-10-12 | 广西尊达电子商务有限公司 | 一种数据库自动恢复方法 |
CN106843745A (zh) * | 2015-12-03 | 2017-06-13 | 南京中兴新软件有限责任公司 | 容量扩展方法及装置 |
CN106991120A (zh) * | 2017-02-22 | 2017-07-28 | 杭州沃趣科技股份有限公司 | 一种实现Oracle数据库同机房零数据丢失的方法 |
CN107819605A (zh) * | 2016-09-14 | 2018-03-20 | 北京百度网讯科技有限公司 | 用于在服务器集群中切换服务器的方法和装置 |
CN108415797A (zh) * | 2018-03-05 | 2018-08-17 | 山东超越数控电子股份有限公司 | 一种避免服务器故障切换时数据库数据丢失的方法 |
CN108664359A (zh) * | 2018-05-23 | 2018-10-16 | 上海达梦数据库有限公司 | 一种数据库恢复方法、装置、设备及存储介质 |
CN108881379A (zh) * | 2018-05-03 | 2018-11-23 | 网宿科技股份有限公司 | 一种服务器集群间数据同步的方法和装置 |
CN109542682A (zh) * | 2018-11-16 | 2019-03-29 | 上海达梦数据库有限公司 | 一种数据备份方法、装置、设备和存储介质 |
CN109857523A (zh) * | 2017-11-30 | 2019-06-07 | 阿里巴巴集团控股有限公司 | 一种用于实现数据库高可用性的方法及装置 |
CN110175089A (zh) * | 2019-05-17 | 2019-08-27 | 国电南瑞科技股份有限公司 | 一种具有读写分离功能的双活灾备系统 |
CN110955556A (zh) * | 2018-09-27 | 2020-04-03 | 阿里巴巴集团控股有限公司 | 数据库恢复方法及装置、存储介质、数据库系统 |
CN111880969A (zh) * | 2020-07-30 | 2020-11-03 | 上海达梦数据库有限公司 | 存储节点恢复方法、装置、设备和存储介质 |
CN112069018A (zh) * | 2020-07-21 | 2020-12-11 | 上海瀚银信息技术有限公司 | 一种数据库高可用方法及系统 |
CN112347065A (zh) * | 2019-08-07 | 2021-02-09 | 中国船舶工业系统工程研究院 | 一种警用预案制定过程记录重演方法及系统 |
CN113448758A (zh) * | 2021-06-30 | 2021-09-28 | 未鲲(上海)科技服务有限公司 | 处理任务的方法、装置及终端设备 |
WO2024131184A1 (zh) * | 2022-12-23 | 2024-06-27 | 华为云计算技术有限公司 | 一种数据库的容灾方法及相关设备 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020112094A1 (en) * | 2001-02-15 | 2002-08-15 | Pederson Donald R. | Optimized end transaction processing |
US20060064416A1 (en) * | 2004-09-17 | 2006-03-23 | Sim-Tang Siew Y | Method and system for data reduction |
CN102158540A (zh) * | 2011-02-18 | 2011-08-17 | 广州从兴电子开发有限公司 | 分布式数据库实现系统及方法 |
CN103840961A (zh) * | 2012-11-23 | 2014-06-04 | 景幂机械(上海)有限公司 | 双机热备份系统 |
CN103902617A (zh) * | 2012-12-28 | 2014-07-02 | 华为技术有限公司 | 分布式数据库同步方法和系统 |
-
2014
- 2014-12-02 CN CN201410722383.3A patent/CN104536971A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020112094A1 (en) * | 2001-02-15 | 2002-08-15 | Pederson Donald R. | Optimized end transaction processing |
US20060064416A1 (en) * | 2004-09-17 | 2006-03-23 | Sim-Tang Siew Y | Method and system for data reduction |
CN102158540A (zh) * | 2011-02-18 | 2011-08-17 | 广州从兴电子开发有限公司 | 分布式数据库实现系统及方法 |
CN103840961A (zh) * | 2012-11-23 | 2014-06-04 | 景幂机械(上海)有限公司 | 双机热备份系统 |
CN103902617A (zh) * | 2012-12-28 | 2014-07-02 | 华为技术有限公司 | 分布式数据库同步方法和系统 |
Non-Patent Citations (6)
Title |
---|
STEVE BOBROWSKI: "《Oracle 8i for Linux实用指南》", 30 April 2001, 机械工业出版社 * |
吕海波: "《ORACLE内核技术揭密》", 30 September 2014, 机械工业出版社 * |
杨剑 等: "Oracle Data Guard容灾技术的研究与实现", 《现代计算机》 * |
潘伟: "基于Oracle 10g数据库系统高可用性框架研究与设计", 《中国优秀硕士学位论文全文数据库信息科技辑》 * |
罗敏: "《品悟性能优化》", 31 May 2011, 清华大学出版社 * |
赵会东: "《Oracle入门经典》", 30 April 2013, 机械工业出版社 * |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104852969A (zh) * | 2015-04-24 | 2015-08-19 | 昆明船舶设备集团有限公司 | Rac与hans高可靠系统融合 |
CN105159991A (zh) * | 2015-09-01 | 2015-12-16 | 北京皮尔布莱尼软件有限公司 | 一种保持数据一致性的方法、装置、系统和应用服务器 |
CN105159991B (zh) * | 2015-09-01 | 2019-08-02 | 北京皮尔布莱尼软件有限公司 | 一种保持数据一致性的方法、装置、系统和应用服务器 |
CN106843745A (zh) * | 2015-12-03 | 2017-06-13 | 南京中兴新软件有限责任公司 | 容量扩展方法及装置 |
CN105573867A (zh) * | 2015-12-30 | 2016-05-11 | 浪潮(北京)电子信息产业有限公司 | 一种MySQL高可用性的实现方法及系统 |
CN106021019A (zh) * | 2016-05-12 | 2016-10-12 | 广西尊达电子商务有限公司 | 一种数据库自动恢复方法 |
CN107819605A (zh) * | 2016-09-14 | 2018-03-20 | 北京百度网讯科技有限公司 | 用于在服务器集群中切换服务器的方法和装置 |
CN106991120A (zh) * | 2017-02-22 | 2017-07-28 | 杭州沃趣科技股份有限公司 | 一种实现Oracle数据库同机房零数据丢失的方法 |
CN109857523B (zh) * | 2017-11-30 | 2023-05-09 | 阿里巴巴集团控股有限公司 | 一种用于实现数据库高可用性的方法及装置 |
CN109857523A (zh) * | 2017-11-30 | 2019-06-07 | 阿里巴巴集团控股有限公司 | 一种用于实现数据库高可用性的方法及装置 |
CN108415797A (zh) * | 2018-03-05 | 2018-08-17 | 山东超越数控电子股份有限公司 | 一种避免服务器故障切换时数据库数据丢失的方法 |
CN108881379A (zh) * | 2018-05-03 | 2018-11-23 | 网宿科技股份有限公司 | 一种服务器集群间数据同步的方法和装置 |
CN108664359A (zh) * | 2018-05-23 | 2018-10-16 | 上海达梦数据库有限公司 | 一种数据库恢复方法、装置、设备及存储介质 |
CN110955556B (zh) * | 2018-09-27 | 2023-05-02 | 阿里云计算有限公司 | 数据库恢复方法及装置、存储介质、数据库系统 |
CN110955556A (zh) * | 2018-09-27 | 2020-04-03 | 阿里巴巴集团控股有限公司 | 数据库恢复方法及装置、存储介质、数据库系统 |
CN109542682A (zh) * | 2018-11-16 | 2019-03-29 | 上海达梦数据库有限公司 | 一种数据备份方法、装置、设备和存储介质 |
CN110175089A (zh) * | 2019-05-17 | 2019-08-27 | 国电南瑞科技股份有限公司 | 一种具有读写分离功能的双活灾备系统 |
CN112347065A (zh) * | 2019-08-07 | 2021-02-09 | 中国船舶工业系统工程研究院 | 一种警用预案制定过程记录重演方法及系统 |
CN112347065B (zh) * | 2019-08-07 | 2023-08-18 | 中国船舶工业系统工程研究院 | 一种警用预案制定过程记录重演方法及系统 |
CN112069018A (zh) * | 2020-07-21 | 2020-12-11 | 上海瀚银信息技术有限公司 | 一种数据库高可用方法及系统 |
CN112069018B (zh) * | 2020-07-21 | 2024-05-31 | 上海瀚银信息技术有限公司 | 一种数据库高可用方法及系统 |
CN111880969A (zh) * | 2020-07-30 | 2020-11-03 | 上海达梦数据库有限公司 | 存储节点恢复方法、装置、设备和存储介质 |
CN111880969B (zh) * | 2020-07-30 | 2024-06-04 | 上海达梦数据库有限公司 | 存储节点恢复方法、装置、设备和存储介质 |
CN113448758A (zh) * | 2021-06-30 | 2021-09-28 | 未鲲(上海)科技服务有限公司 | 处理任务的方法、装置及终端设备 |
WO2024131184A1 (zh) * | 2022-12-23 | 2024-06-27 | 华为云计算技术有限公司 | 一种数据库的容灾方法及相关设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN104536971A (zh) | 一种具备高可用性的数据库 | |
US9460183B2 (en) | Split brain resistant failover in high availability clusters | |
US9535907B1 (en) | System and method for managing backup operations of virtual machines | |
US20140244578A1 (en) | Highly available main memory database system, operating method and uses thereof | |
CN106815097A (zh) | 数据库容灾系统和方法 | |
CN102710752B (zh) | 灾备存储系统 | |
US20070220059A1 (en) | Data processing node | |
Stonebraker | Errors in database systems, eventual consistency, and the cap theorem | |
CN101578586A (zh) | 在故障转移和故障回复环境中使用虚拟拷贝 | |
US7457830B1 (en) | Method and system of replicating data using a recovery data change log | |
KR20110044858A (ko) | 데이터 센터들에 걸쳐 데이터 서버들내 데이터 무결정의 유지 | |
CN105302667B (zh) | 基于集群架构的高可靠性数据备份与恢复方法 | |
US7702757B2 (en) | Method, apparatus and program storage device for providing control to a networked storage architecture | |
CN105069160A (zh) | 一种基于自主可控数据库的高可用性方法及构架 | |
CN103294787A (zh) | 分布式数据库系统的多副本存储方法和系统 | |
CN108810150B (zh) | 协同办公系统应用级灾备系统的数据复制方法 | |
CN108964986B (zh) | 协同办公系统应用级双活灾备系统 | |
CN103136070A (zh) | 一种数据容灾处理的方法和装置 | |
WO2017014814A1 (en) | Replicating memory volumes | |
CN114706714A (zh) | 一种同步计算机内存分割快照的方法 | |
JP2006285336A (ja) | 記憶装置及びストレージシステム並びにその制御方法 | |
JP2015005037A (ja) | 情報処理装置、情報処理装置の制御プログラム、および情報処理装置の制御方法 | |
JP5154843B2 (ja) | クラスタシステム、計算機、および障害回復方法 | |
CN114089923A (zh) | 一种双活存储系统及其数据处理方法 | |
JP2005055995A (ja) | ストレージ制御方法、および、冗長化機能を有するサーバシステム |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20150422 |
|
RJ01 | Rejection of invention patent application after publication |