CN107145403B - 面向Web开发环境的关系型数据库数据回溯方法 - Google Patents

面向Web开发环境的关系型数据库数据回溯方法 Download PDF

Info

Publication number
CN107145403B
CN107145403B CN201710262218.8A CN201710262218A CN107145403B CN 107145403 B CN107145403 B CN 107145403B CN 201710262218 A CN201710262218 A CN 201710262218A CN 107145403 B CN107145403 B CN 107145403B
Authority
CN
China
Prior art keywords
database
data
log
time
backup
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.)
Active
Application number
CN201710262218.8A
Other languages
English (en)
Other versions
CN107145403A (zh
Inventor
陆佳炜
卢成炳
李�杰
肖刚
张元鸣
徐俊
周焕
高燕煦
马俊
陈烘
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhejiang University of Technology ZJUT
Original Assignee
Zhejiang University of Technology ZJUT
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Zhejiang University of Technology ZJUT filed Critical Zhejiang University of Technology ZJUT
Priority to CN201710262218.8A priority Critical patent/CN107145403B/zh
Publication of CN107145403A publication Critical patent/CN107145403A/zh
Application granted granted Critical
Publication of CN107145403B publication Critical patent/CN107145403B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

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/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • 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/1474—Saving, restoring, recovering or retrying in transactions
    • 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/21—Design, administration or maintenance of databases
    • 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/21—Design, administration or maintenance of databases
    • G06F16/219—Managing data history or versioning
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/80—Database-specific techniques

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)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

一种面向Web开发环境的关系型数据库数据回溯方法，包括以下步骤：第一步、建立Web环境SeeLog日志处理模型，过程如下：1.1自动获取SeeLog日志；1.2根据算法动态调整日志持久化行为；1.3采用日志分割策略进行持久化操作；第二步、采用TBack数据回溯机制进行数据库恢复，过程如下：一旦数据库在某一时间点发生故障，利用数据库事务日志进行数据回溯，将数据库恢复至故障发生之前的任意时间点；第三步、采用内存日志的自备份机制，将每个事务即时写入持久化层，保证内存日志不会丢失。本发明能实现低成本的数据备份并且可以不依赖于具体的关系型数据库种类和版本。

Description

面向Web开发环境的关系型数据库数据回溯方法
技术领域
本发明涉及一种Web开发环境下关系型数据库数据回溯方法。
背景技术
随着信息时代的发展，数据的妥善保存必不可少，数据通常保存在数据库中，一旦数据库发生故障，就会造成数据丢失。因此，数据库的备份恢复技术显得尤为重要。
目前，系统应用层面的备份技术主要采用双机热备份的方式；而数据库层面，常见的数据库备份恢复方案主要有物理备份和逻辑备份两种。物理备份需要将数据库的物理文件(包括控制文件、数据文件、日志文件等)拷贝到存储介质中，根据备份时数据库的运行状态又分为脱机备份和联机备份两种。脱机备份是指在关闭数据库的情况下，将数据库的物理文件拷贝到存储介质，一般利用操作系统自带的命令和工具来完成，操作简单，缺点在于这种方法往往需要将数据库关闭，对于系统应用的连续性有一定影响。联机备份是指在数据库开启并提供用户访问的情况下，对物理文件做操作系统级别的备份，缺点是操作比较复杂，需要对操作系统有较深的认识。逻辑备份是针对用户、表空间、表、分区等数据库逻辑组件进行备份，一般将数据库逻辑组件信息导出转存为二进制文件，恢复操作中，将导出的二进制文件重新装载到目标数据库中。特点在于操作灵活，可实现不同数据库之间的数据迁移，可以对单个数据库对象进行备份。许多商业数据库厂商采用不同的实现方式提供了很多功能强大的逻辑磁带读写工具，如Oracle公司的export/import、数据泵技术等。
江苏瑞中数据股份有限公司的史英杰、朱恒、粟勇等人发明了一种实时数据库备份恢复方法，实现一个备份工具程序，支持实时数据库在离线和在线状态下的全量备份，同时支持数据库在线状态下的增量数据备份，实现一个恢复工具程序，支持对备份出来的文件进行整理恢复，确保备份的有效性；采用备份文件块的方式，提高备份效率，极大减少备份过程对实时数据库及其应用的影响。阿里巴巴集团控股有限公司的李奕、李铮等人提供一种通过使用日志恢复数据库数据的方法及设备，以解决现有技术存在的数据库定期备份机制中从数据库备份程序最后一次进行备份的时间点到主数据库损坏的时间点期间的数据丢失问题。包括以下步骤：将应用程序中的业务数据转换成日志数据；将日志数据存储于灾备文件中；将灾备文件中的日志数据解析为具备数据库格式的数据；将解析得到的数据重建获得业务数据；将重建的业务数据更新到备用数据库。
目前，业界通常采用的备份方案是定时计划执行数据库全量备份，使用数据库自带工具将数据库完整地导出到存储介质中，同时开启数据库自带的事务日志功能进行增量备份。此做法的缺陷是执行全量备份时会影响数据库的访问，用户体验不佳，同时数据库自带的数据库事务日志文件繁多，恢复时需要人工恢复每个日志文件，过程繁琐。
发明内容
针对现有的关系型数据库数据备份方案，原来数据库维护采用双机热备份等方式，成本高且效率低，而NoSQL数据库的日志恢复策略、主从备份技术还无法完全适用于关系型数据库。本发明基于Web开发环境，针对此开发环境下使用关系型数据库作为持久层处理时提出的一种面向Web开发环境的关系型数据库数据回溯方法，能实现低成本的数据备份并且可以不依赖于具体的关系型数据库种类和版本。
本发明所采用的技术方案是：
一种面向Web开发环境的关系型数据库数据回溯方法，包括以下步骤：
第一步、建立Web环境SeeLog日志处理模型，过程如下：
1.1自动获取SeeLog日志：Web环境下，当用户操作数据库时，会执行 DML(DataManipulation Language)语句，包含：UPDATE、INSERT、DELETE 三种形式。成功执行DML语句后，会触发日志处理单元。日志处理单元运用 AOP(Aspect Oriented Programming)面向切面编程的思想，以业务处理过程中对数据库的修改作为切入点(Pointcut)，将日志记录的代码以通知(Advice) 的形式织入(weaving)切入点中，形成切面(Aspect)，达到日志处理逻辑与业务操作逻辑分离的目的。日志处理单元通过对底层连接数据库代码进行注入，记录下所有对系统增删改的SQL语句及其占位符参数，形成SeeLog日志。该日志为文本数据，反映了用户操作行为，每一行都代表一次用户的原子操作，每行数据是一个由操作时间(OperateTime)、操作类型(OperateType)、 SQL语句(SQL)、占位符参数(Parameters)、是否批量(IsBatch)操作构成的五元组。其中操作时间精确到毫秒，操作类型有插入(Insert)、修改 (Update)、删除(Delete)3种取值，当批量操作为true时，需要分割占位符参数属性的取值，以便区分占位符参数的前后关系。日志数据使用半形式化方法来描述：
LogData＝OperateTime,[OperateType],SQL,{Parameters},[IsBatch]
OperateType＝’Insert’|’Update’|’Delete’
IsBatch＝’True’|’False’
1.2根据算法动态调整日志持久化行为：SeeLog日志的作用是记录用户对数据库修改的所有行为，从而保证在数据库发生故障后，能真实还原用户操作数据库的场景，使数据库达到故障发生之前的状态。在SeeLog日志处理模型中，日志首先会被写入内存，一段时间后再将内存中的日志写入持久化层。此处的间隔时间不是固定数值，本发明提供一种多因子动态权重算法决定是否执行内存日志持久化，算法如下：
1.2.1.确定影响因子，此处影响因子为内存占用率memory_usage、CPU占用率cpu_usage、磁盘占用率io_usage、Web应用用户访问量 user_traffic、已存储的SQL语句量sql_amount；
1.2.2.设立基准权重W_stdi，由于每个因子对最终结果的影响不同，因此需要预先设定通常情况下，每个因子的权重；
1.2.3.为每个因子设定阈值Thresholdi，当影响因子的值达到最大值后，基本可以决定最终结果，例如：当内存占用率达到100％时，就必须要执行从内存中写入持久化文件的操作，从而释放日志数据所占用的内存。因此，需要为每个因子设定阈值，在影响因子的数值未达到阈值之前，该因子的权重即为基准权重；当影响因子的数值达到阈值后，该因子的权重将动态增加，以增强对最终结果的影响；
1.2.4.建立权重动态增加函数，并计算动态增加后的权重W_coti。根据影响因子的特点可以设置为线性函数、指数函数、对数函数等，也可以自行建立复合函数。例如：
权重增加函数可设置为简单的线性函数W_coti＝K*Factori+C，其中
K为线性函数的斜率，反应了权重增加的速率；
C为线性函数的截距，代表权重的初始设定值；
Factor＝Valuememory_usage|(1-Valuecpu_usage)|(1-Valueio_usage)|(1-Rateuser_traffic)| Ratesql_amount
需要注意，有些影响因子为负相关，例如：磁盘占用率越高，该因子的权重越低。因此，需要将因子的取值设置为1-Valuefactor；
1.2.5.确定动态变化后各因子的权重W_newi，若影响因子未达到阈值，则W_newi＝W_stdi；若影响因子达到阈值，则W_newi＝W_coti。公式如下：
Figure BDA0001275067180000041
1.2.6.根据变化后的权重计算最终结果，此处计算结果为将内存中日志写入持久化层的概率，因此需要将影响因子的具体数值转化为百分比，此处为Web应用用户访问量、已存储的SQL语句量，方法如下：
Ratememory_usage＝Valuememory_usage
Ratecpu_usage＝Valuecpu_usage
Rateio_usage＝Valueio_usage
Rateuser_traffic＝Valueuser_traffic/Maxuser_traffic
Ratesql_amount＝Valuesql_amount/Maxsql_amount
对于负相关的影响因子，此处为CPU占用率、磁盘占用率、Web应用用户访问量，在乘以相应权重之前，需要用1-百分比数值进行转换，方法如下：
Factormemory_usage＝Ratememory_usage＝Valuememory_usage
Factorcpu_usage＝1-Ratecpu_usage＝1-Valuecpu_usage
Factorio_usage＝1-Rateio_usage＝1-Valueio_usage
Factoruser_traffic＝1-Rateuser_traffic＝1-Valueuser_traffic/Maxuser_traffic
Factorsql_amount＝Ratesql_amount＝Valuesql_amount/Maxsql_amount
将每个因子转换后的数值Factori*变化后各因子的权重W_newi，并将相乘后的结果相加，即可得到将内存中日志写入持久化层的概率 Probabilitywrite，加权运算公式如下：
Probabilitywrite＝∑(Factori×W_newi)
因此，只要设定执行操作的概率阈值Probabilitythreshold，当Probabilitywrite大于Probabilitythreshold时，程序即执行内存日志持久化的操作。
1.3采用日志分割策略进行持久化操作：当内存日志写入持久化层时，若将所有SeeLog日志写入同一个文件中，会使得单个文件非常大，严重影响打开和读取的效率。因此，需要将日志进行分割，将单个日志文件的最大数据行设置为Rowmax，该数值可根据实际需要自行更改。首个日志文件会根据创建时间命名，每当数据行数达到Rowmax时，则新建文件继续写入，所有文件新建时都以创建时间作为文件名，以便搜索文件时快速定位时间点。
第二步、采用TBack数据回溯机制进行数据库恢复，方案如下：
一旦数据库在某一时间点发生故障，可以利用数据库事务日志进行数据回溯，将数据库恢复至故障发生之前的任意时间点。
步骤2.1TBack数据回溯机制必须基于某一时刻的数据库版本进行恢复，因此需要建立数据库里程碑(数据库正常运行状态下的一次全量备份)。里程碑的意义在于：恢复数据时，先将数据库还原至里程碑时的状态，然后依据 SeeLog日志，按照时间流的形式重现用户操作进行数据回溯。数据库备份人员可按具体项目需要，不定期进行一次数据库备份，建议选择Web应用用户访问量较少时进行。数据库里程碑的建立根据采用数据库类型不同而略有差异，但都依托数据库自带命令行工具或GUI完成，备份人员执行一次备份任务后，需要将备份文件进行归档，并在里程碑历史表中添加本次里程碑建立信息，里程碑历史表中详细记录了从数据库新建开始到目前为止，每次里程碑建立的时间 (需要精确到毫秒)、备份文件归档路径以及备份文件名，方便对数据库历史进行定位追踪。TBack数据回溯机制采用基于用户行为分析的备份策略，通过感知用户在Web应用中对数据库所做的修改进行记录，而无法监测到管理员直接对数据库所做的改动。因此每当数据库结构发生改变或者DBA管理员手动修改数据库之后，需要数据库备份人员建立一个里程碑，否则会导致回溯机制失效。
步骤2.2数据库故障发生后，先确定待恢复时间timeEnd，一般为数据库发生故障前的某个时间点，然后对照里程碑历史表选择合适的里程碑，一般情况下可选择故障发生前最近一次里程碑，根据记录的路径获取相应的备份文件，并记下里程碑建立的时间timeStart。打开数据库自带命令行工具或GUI，读取里程碑备份文件，执行数据库还原命令，由于采用数据库类型不同，还原命令会略有差异。执行成功后，数据库还原至里程碑时的状态。
步骤2.3启动新线程，程序首先确定回溯起始文件，进入SeeLog日志的存放目录，逐个搜索文件名，找到相邻的两个文件F1、F2，使得F1的文件名时间小于里程碑建立的时间timeStart；而F2的文件名时间刚好大于timeStart。此时文件F1记录的是从F1的文件名时间开始到timeStart期间的所有用户行为，因此可以确定回溯起始文件为F1。按照同样的方法，可以根据待恢复时间 timeEnd搜索得到回溯结束文件。接着程序将继续定位恢复起始数据行，由于日志文件的每行数据都记录着用户的操作时间，因此可以根据操作时间进行快速定位。回溯起始文件中，操作时间大于timeStart的第一条数据所在行即为恢复起始数据行lineStart；同样，回溯结束文件中，操作时间小于timeEnd的最后一条数据所在行即为恢复结束行lineEnd。然后程序将读取lineStart到lineEnd区间内的所有用户行为，并逐条将数据压入队列中，该队列创建在内存中，SeeLog 日志每行数据构成的五元组将作为参数传入，该五元组存储在队列的每一个元素中。由于区间内可能会存在大量的用户行为数据，数据量的多少与里程碑建立的频率以及用户访问量有关，若一次性将所有数据读入内存，可能会造成内存溢出。因此本发明设立动态缓存，规定先将数据按序读入内存，当读取的数据行达到一定量(该数值可根据当前服务器性能设定)后，暂停数据的读入，当前线程进入线程池中等待，此时队列将无法继续添加元素，实行单向流出策略，流出的数据将执行步骤2.4的操作，当列队中的元素全部流出后，唤醒数据读取的线程继续读入数据。
步骤2.4采用管道流处理机制，首先任务执行中枢将解析Web应用中的数据源配置，并建立数据库连接，然后从队列中取出一个元素进入管道流，其他元素在队列中继续等待，任务执行中枢将读取元素中的五元数据组< OperateTime,[OperateType],SQL,{Parameters},[IsBatch]>，根据五元组中的是否批量属性(IsBatch)，确定是否开启数据库事务，读取SQL语句属性(SQL) 生成预处理语句，并将占位符参数(Parameters)填入，接着根据操作类型属性 (OperateType)执行当前预处理语句，执行成功后，本条用户行为数据还原完毕，继续从队列中取出下一个元素进入管道流。当任务执行中枢取出当前队列中所有的元素后，会唤醒步骤2.3中等待的线程，此时可以继续读取日志文件中的下一部分数据。
步骤2.5若步骤2.4中的任务执行中枢未能成功执行预处理语句，将挂起从队列中读取元素进入管道流的操作，并每间隔一段时间重复执行一次当前的预处理语句，若能成功执行，则恢复挂起的操作，继续读取队列中的元素；若重复执行一定次数后，仍未能执行成功，将提示数据库恢复人员手工排查错误，并暂停整个程序的运行，直到当前预处理语句成功执行，程序才继续运行并恢复挂起的操作。当lineStart到lineEnd区间内的所有数据都恢复成功后，数据回溯完毕，数据库成功还原至故障发生之前的状态。
第三步、采用内存日志的自备份机制，将每个事务即时写入持久化层，保证内存日志不会丢失。
如果Web服务器发生宕机或者重启，自上一次将内存中的日志写入持久化层到服务器发生宕机或重启这段时间内的日志，由于仅保存在内存中，还未及时写入持久化层，服务器的宕机或重启将会导致这部分日志丢失。
通过配备一台备份服务器，并提供一个额外线程，将该线程作为AOP通知，织入对数据库修改的切入点中，线程执行以下操作：在每条SQL操作语句及参数被写入内存的同时，将该条SQL语句和参数发送至备份服务器上。由于需要不间断地向备份服务器发送数据，并且发送频率不定，与用户行为密切相关，因此需要该线程与备份服务器之间建立长连接。
与主服务器不同的是，备份服务器并不是每间隔一段时间将内存中的日志写入持久化文件，而是每接收到一条SQL语句便直接持久化。同样，由于需要不间断地接收数据，并且接收频率不定，需要日志写入程序与持久化文件之间的IO通道保持打开的状态，备份服务器仅执行数据接收及持久化的操作，并不为其他应用提供服务，因此保持IO打开并不会产生其他影响。与主服务器相同，当单个文件数据行数达到Rowmax时，程序关闭当前IO通道，新建日志文件，以创建时间命名，并重新建立IO通道。通过备份服务器的即时持久化，保证了每一次用户行为操作都被即时记录并备份，避免了因数据库宕机或重启而导致内存中日志丢失的尴尬。
本发明的有益效果是：成本低，数据库无依赖(数据库宕机也不影响日志恢复)、写入高效，不需要对数据库进行多次备份，基于用户操作日志的备份也能对用户行为进行分析挖掘。
下面结合附图进一步说明本发明。
附图说明
图1示出了SeeLog日志处理模型图。
图2示出了TBack数据回溯机制。
图3示出了内存日志的自备份机制。
具体实施方式
下面结合附图对本发明作进一步描述。
参照图1～图3，一种面向Web开发环境的关系型数据库数据回溯方法，包括以下步骤：
第一步、建立Web环境SeeLog日志处理模型，过程如下：
1.1自动获取SeeLog日志：Web环境下，当用户操作数据库时，会执行 DML(DataManipulation Language)语句，包含：UPDATE、INSERT、DELETE 三种形式。成功执行DML语句后，会触发日志处理单元。如图1(1)所示，用户需求以流的方式并行向服务器发送，而需求中的DML语句会触发日志处理单元，将这些DML语句按照执行的时间先后顺序写入内存中。日志处理单元运用AOP(Aspect Oriented Programming)面向切面编程的思想，以业务处理过程中对数据库的修改作为切入点(Pointcut)，将日志记录的代码以通知(Advice) 的形式织入(weaving)切入点中，形成切面(Aspect)，达到日志处理逻辑与业务操作逻辑分离的目的。日志处理单元通过对底层连接数据库代码进行注入 (例如使用Java语言，以jar包的方式注入到Web应用中来)，记录下所有对系统增删改的SQL语句及其占位符参数，形成SeeLog日志。该日志为文本数据，反映了用户操作行为，每一行都代表一次用户的原子操作，每行数据是一个由操作时间(OperateTime)、操作类型(OperateType)、SQL语句(SQL)、占位符参数(Parameters)、是否批量(IsBatch)操作构成的五元组。其中操作时间精确到毫秒，操作类型有插入(Insert)、修改(Update)、删除(Delete) 3种取值，当批量操作为true时，需要分割占位符参数属性的取值，以便区分占位符参数的前后关系。日志数据使用半形式化方法来描述：
LogData＝OperateTime,[OperateType],SQL,{Parameters},[IsBatch]
OperateType＝’Insert’|’Update’|’Delete’
IsBatch＝’True’|’False’
例如：Web应用中，用户user1将自己的密码修改为abc，程序将执行UPDATE语句对数据库进行修改操作，此时将触发日志处理单元，该单元会记录下本次修改操作的时间、操作类型为update、SQL语句为update user set password＝？where username＝？、占位符参数为abc、user1、是否批量操作为false。
1.2根据算法动态调整日志持久化行为：SeeLog日志的作用是记录用户对数据库修改的所有行为，从而保证在数据库发生故障后，能真实还原用户操作数据库的场景，使数据库达到故障发生之前的状态。在SeeLog日志处理模型中，日志首先会被写入内存，一段时间后再将内存中的日志写入持久化层(如图1 (2)所示)。此处的间隔时间不是固定数值，本发明提供一种多因子动态权重算法决定是否执行内存日志持久化，算法如下：
1.2.1.确定影响因子，此处影响因子为内存占用率memory_usage、CPU占用率cpu_usage、磁盘占用率io_usage、Web应用用户访问量 user_traffic、已存储的SQL语句量sql_amount；
1.2.2.设立基准权重W_stdi，由于每个因子对最终结果的影响不同，因此需要预先设定通常情况下，每个因子的权重；
1.2.3.为每个因子设定阈值Thresholdi，当影响因子的值达到最大值后，基本可以决定最终结果，例如：当内存占用率达到100％时，就必须要执行从内存中写入持久化文件的操作，从而释放日志数据所占用的内存。因此，需要为每个因子设定阈值，在影响因子的数值未达到阈值之前，该因子的权重即为基准权重；当影响因子的数值达到阈值后，该因子的权重将动态增加，以增强对最终结果的影响；
1.2.4.建立权重动态增加函数，并计算动态增加后的权重W_coti。根据影响因子的特点可以设置为线性函数、指数函数、对数函数等，也可以自行建立复合函数。例如：
权重增加函数可设置为简单的线性函数W_coti＝K*Factori+C，其中
K为线性函数的斜率，反应了权重增加的速率；
C为线性函数的截距，代表权重的初始设定值；
Factor＝Valuememory_usage|(1-Valuecpu_usage)|(1-Valueio_usage)|(1-Rateuser_traffic)| Ratesql_amount
需要注意，有些影响因子为负相关，例如：磁盘占用率越高，该因子的权重越低。因此，需要将因子的取值设置为1-Valuefactor；
1.2.5.确定动态变化后各因子的权重W_newi，若影响因子未达到阈值，则W_newi＝W_stdi；若影响因子达到阈值，则W_newi＝W_coti。公式如下：
Figure BDA0001275067180000111
1.2.6.根据变化后的权重计算最终结果，此处计算结果为将内存中日志写入持久化层的概率，因此需要将影响因子的具体数值转化为百分比，此处为Web应用用户访问量、已存储的SQL语句量，方法如下：
Ratememory_usage＝Valuememory_usage
Ratecpu_usage＝Valuecpu_usage
Rateio_usage＝Valueio_usage
Rateuser_traffic＝Valueuser_traffic/Maxuser_traffic
Ratesql_amount＝Valuesql_amount/Maxsql_amount
对于负相关的影响因子，此处为CPU占用率、磁盘占用率、Web应用用户访问量，在乘以相应权重之前，需要用1-百分比数值进行转换，方法如下：
Factormemory_usage＝Ratememory_usage＝Valuememory_usage
Factorcpu_usage＝1-Ratecpu_usage＝1-Valuecpu_usage
Factorio_usage＝1-Rateio_usage＝1-Valueio_usage
Factoruser_traffic＝1-Rateuser_traffic＝1-Valueuser_traffic/Maxuser_traffic
Factorsql_amount＝Ratesql_amount＝Valuesql_amount/Maxsql_amount
将每个因子转换后的数值Factori乘以变化后各因子的权重W_newi，并将相乘后的结果相加，即可得到将内存中日志写入持久化层的概率 Probabilitywrite，加权运算公式如下：
Probabilitywrite＝∑(Factori×W_newi)
因此，只要设定执行操作的概率阈值Probabilitythreshold，当Probabilitywrite大于Probabilitythreshold时，程序即执行内存日志持久化的操作。
1.3采用日志分割策略进行持久化操作：当内存日志写入持久化层时，若将所有SeeLog日志写入同一个文件中，会使得单个文件非常大，严重影响打开和读取的效率。因此，需要将日志进行分割，将单个日志文件的最大数据行设置为Rowmax，该数值可根据实际需要自行更改。首个日志文件会根据创建时间命名，每当数据行数达到Rowmax时，则新建文件继续写入，所有文件新建时都以创建时间作为文件名，以便搜索文件时快速定位时间点。
第二步、采用TBack数据回溯机制进行数据库恢复，方案如下：
一旦数据库在某一时间点发生故障，可以利用数据库事务日志进行数据回溯，将数据库恢复至故障发生之前的任意时间点。
步骤2.1TBack数据回溯机制必须基于某一时刻的数据库版本进行恢复，因此需要建立数据库里程碑(数据库正常运行状态下的一次全量备份)。里程碑的意义在于：恢复数据时，先将数据库还原至里程碑时的状态，然后依据 SeeLog日志，按照时间流的形式重现用户操作进行数据回溯。数据库备份人员可按具体项目需要，不定期进行一次数据库备份，建议选择Web应用用户访问量较少时进行。数据库里程碑的建立根据采用数据库类型不同而略有差异，但都依托数据库自带命令行工具或GUI完成(如使用MySQL数据库，可采用MySQL Workbench进行数据库备份，点击Server选择Data Export，选择目标数据库和导出路径后Start Export即可，导出时需要勾选Dump Stored Procedures and Functions、Dump Events和Dump Triggers，确保导出数据的同时备份存储过程、函数、事件和触发器)，备份人员执行一次备份任务后，需要将备份文件进行归档，并在里程碑历史表中添加本次里程碑建立信息，里程碑历史表中详细记录了从数据库新建开始到目前为止，每次里程碑建立的时间(需要精确到毫秒)、备份文件归档路径以及备份文件名，方便对数据库历史进行定位追踪。 TBack数据回溯机制采用基于用户行为分析的备份策略，通过感知用户在Web应用中对数据库所做的修改进行记录，而无法监测到管理员直接对数据库所做的改动。因此每当数据库结构发生改变或者DBA管理员手动修改数据库之后，需要数据库备份人员建立一个里程碑，否则会导致回溯机制失效。
步骤2.2数据库故障发生后，先确定待恢复时间timeEnd，一般为数据库发生故障前的某个时间点，然后对照里程碑历史表选择合适的里程碑，一般情况下可选择故障发生前最近一次里程碑，根据记录的路径获取相应的备份文件，并记下里程碑建立的时间timeStart。打开数据库自带命令行工具或GUI，读取里程碑备份文件，执行数据库还原命令，由于采用数据库类型不同，还原命令会略有差异。执行成功后，数据库还原至里程碑时的状态。例如：数据库于2017-01-01 00:00:00.001发生故障，确定待恢复时间timeEnd为2017-01-01 00:00:00.000，假设上一次建立里程碑的时间为2016-06-01 00:00:00.000，因此 timeStart为2016-06-01 00:00:00.000。打开MySQL Workbench，点击Server选择Data Import，选择本次里程碑备份文件的路径，点击Start Import还原数据库。
步骤2.3启动新线程，程序首先确定回溯起始文件，进入SeeLog日志的存放目录，逐个搜索文件名，找到相邻的两个文件F1、F2，使得F1的文件名时间小于里程碑建立的时间timeStart；而F2的文件名时间刚好大于timeStart。此时文件F1记录的是从F1的文件名时间开始到timeStart期间的所有用户行为，因此可以确定回溯起始文件为F1。按照同样的方法，可以根据待恢复时间 timeEnd搜索得到回溯结束文件。接着程序将继续定位恢复起始数据行，由于日志文件的每行数据都记录着用户的操作时间，因此可以根据操作时间进行快速定位。回溯起始文件中，操作时间大于timeStart的第一条数据所在行即为恢复起始数据行lineStart；同样，回溯结束文件中，操作时间小于timeEnd的最后一条数据所在行即为恢复结束行lineEnd。假设F1的文件名为2016-05-31 20.00.00.000，F2的文件名为2016-06-01 10.00.00.000，此时文件F1记录的是从 2016-05-31 20:00:00.000到2016-06-0110:00:00.000期间的所有用户行为，读取文件F1找到操作时间大于2016-06-01 00:00:00.000的数据行，假设为第500行，操作时间为2016-06-01 00:00:00.001，则lineStart为500；同理，可找到文件名为 2016-12-31 20:00:00.000的回溯结束文件，lineEnd为600，操作时间为 2017-01-01 00:00:00.000。然后程序将读取lineStart到lineEnd区间内的所有用户行为，并逐条将数据压入队列中(如图2(1)所示)，该队列创建在内存中，SeeLog日志每行数据构成的五元组将作为参数传入(例如：用户user1将自己的密码修改为abc的行为，五元数据组为<2016-06-01 10:00:00.000,update,update user set password＝？whereusername＝？,abc、user1,false>)，该五元组存储在队列的每一个元素中。由于区间内可能会存在大量的用户行为数据，数据量的多少与里程碑建立的频率以及用户访问量有关，若一次性将所有数据读入内存，可能会造成内存溢出。因此本发明设立动态缓存，规定先将数据按序读入内存，当读取的数据行达到一定量(该数值可根据当前服务器性能设定)后，暂停数据的读入，当前线程进入线程池中等待，此时队列将无法继续添加元素，实行单向流出策略，流出的数据将执行步骤2.4的操作，当列队中的元素全部流出后，唤醒数据读取的线程继续读入数据。
步骤2.4采用管道流处理机制，如图2(2)所示，首先任务执行中枢将解析Web应用中的数据源配置，并建立数据库连接，然后从队列中取出一个元素进入管道流，其他元素在队列中继续等待，图2(3)所示，任务执行中枢将读取元素中的五元数据组<OperateTime,[OperateType],SQL,{Parameters}, [IsBatch]>，根据五元组中的是否批量属性(IsBatch)，确定是否开启数据库事务，读取SQL语句属性(SQL)生成预处理语句，并将占位符参数(Parameters) 填入，接着根据操作类型属性(OperateType)执行当前预处理语句，执行成功后，本条用户行为数据还原完毕，继续从队列中取出下一个元素进入管道流。当任务执行中枢取出当前队列中所有的元素后，会唤醒步骤2.3中等待的线程，此时可以继续读取日志文件中的下一部分数据。
步骤2.5若步骤2.4中的任务执行中枢未能成功执行预处理语句，将挂起从队列中读取元素进入管道流的操作，并每间隔一段时间重复执行一次当前的预处理语句，若能成功执行，则恢复挂起的操作，继续读取队列中的元素；若重复执行一定次数后，仍未能执行成功，将提示数据库恢复人员手工排查错误，并暂停整个程序的运行，直到当前预处理语句成功执行，程序才继续运行并恢复挂起的操作。当lineStart到lineEnd区间内的所有数据都恢复成功后，数据回溯完毕，数据库成功还原至故障发生之前的状态。
第三步、采用内存日志的自备份机制，将每个事务即时写入持久化层，保证内存日志不会丢失。
如果Web服务器发生宕机或者重启，自上一次将内存中的日志写入持久化层到服务器发生宕机或重启这段时间内的日志，由于仅保存在内存中，还未及时写入持久化层，服务器的宕机或重启将会导致这部分日志丢失。
通过配备一台备份服务器，并提供一个额外线程，将该线程作为AOP通知，织入对数据库修改的切入点中，线程执行以下操作：如图3(1)所示，在每条SQL操作语句及参数被写入内存的同时，将该条SQL语句和参数发送至备份服务器上。由于需要不间断地向备份服务器发送数据，并且发送频率不定，与用户行为密切相关，因此需要该线程与备份服务器之间建立长连接。
如图3(2)所示，与主服务器不同的是，备份服务器并不是每间隔一段时间将内存中的日志写入持久化文件，而是每接收到一条SQL语句便直接持久化。同样，由于需要不间断地接收数据，并且接收频率不定，需要日志写入程序与持久化文件之间的IO通道保持打开的状态，备份服务器仅执行数据接收及持久化的操作，并不为其他应用提供服务，因此保持IO打开并不会产生其他影响。与主服务器相同，当单个文件数据行数达到Rowmax时，程序关闭当前IO通道，新建日志文件，以创建时间命名，并重新建立IO通道。通过备份服务器的即时持久化，保证了每一次用户行为操作都被即时记录并备份，避免了因数据库宕机或重启而导致内存中日志丢失的尴尬。

Claims (4)

1.一种面向Web开发环境的关系型数据库数据回溯方法，其特征在于：包括以下步骤：
第一步、建立Web环境SeeLog日志处理模型，过程如下：
步骤1.1自动获取SeeLog日志：Web环境下，当用户操作数据库时，会执行DML语句，包含：UPDATE、INSERT、DELETE三种形式；成功执行DML语句后，会触发日志处理单元；日志处理单元运用AOP面向切面编程的思想，以业务处理过程中对数据库的修改作为切入点，将日志记录的代码以通知的形式织入切入点中，形成切面，达到日志处理逻辑与业务操作逻辑分离的目的；
步骤1.2根据算法动态调整日志持久化行为：SeeLog日志的作用是记录用户对数据库修改的所有行为，从而保证在数据库发生故障后，能真实还原用户操作数据库的场景，使数据库达到故障发生之前的状态；在SeeLog日志处理模型中，日志首先会被写入内存，一段时间后再将内存中的日志写入持久化层；
步骤1.3采用日志分割策略进行持久化操作：当内存日志写入持久化层时，将日志进行分割，将单个日志文件的最大数据行设置为Rowmax，Rowmax的数值根据实际需要自行更改；首个日志文件会根据创建时间命名，每当数据行数达到Rowmax时，则新建文件继续写入，所有文件新建时都以创建时间作为文件名，以便搜索文件时快速定位时间点；
第二步、采用TBack数据回溯机制进行数据库恢复，过程如下：
一旦数据库在某一时间点发生故障，利用数据库事务日志进行数据回溯，将数据库恢复至故障发生之前的任意时间点；
步骤2.1TBack数据回溯机制必须基于某一时刻的数据库版本进行恢复，建立数据库里程碑，里程碑的意义在于：恢复数据时，先将数据库还原至里程碑时的状态，然后依据SeeLog日志，按照时间流的形式重现用户操作进行数据回溯，数据库备份人员可按具体项目需要，不定期进行一次数据库备份，建议选择Web应用用户访问量较少时进行；数据库里程碑的建立根据采用数据库类型不同而略有差异，但都依托数据库自带命令行工具或GUI完成，备份人员执行一次备份任务后，需要将备份文件进行归档，并在里程碑历史表中添加本次里程碑建立信息，里程碑历史表中详细记录了从数据库新建开始到目前为止，每次里程碑建立的时间、备份文件归档路径以及备份文件名，方便对数据库历史进行定位追踪；TBack数据回溯机制采用基于用户行为分析的备份策略，通过感知用户在Web应用中对数据库所做的修改进行记录，而无法监测到管理员直接对数据库所做的改动；因此每当数据库结构发生改变或者DBA管理员手动修改数据库之后，需要数据库备份人员建立一个里程碑，否则会导致回溯机制失效；
步骤2.2数据库故障发生后，先确定待恢复时间timeEnd，为数据库发生故障前的某个时间点，然后对照里程碑历史表选择合适的里程碑，选择故障发生前最近一次里程碑，根据记录的路径获取相应的备份文件，并记下里程碑建立的时间timeStart，打开数据库自带命令行工具或GUI，读取里程碑备份文件，执行数据库还原命令，由于采用数据库类型不同，还原命令会略有差异，执行成功后，数据库还原至里程碑时的状态；
步骤2.3启动新线程，程序首先确定回溯起始文件，进入SeeLog日志的存放目录，逐个搜索文件名，找到相邻的两个文件F1、F2，使得F1的文件名时间小于里程碑建立的时间timeStart；而F2的文件名时间刚好大于timeStart，此时文件F1记录的是从F1的文件名时间开始到timeStart期间的所有用户行为，因此可以确定回溯起始文件为F1；按照同样的方法，根据待恢复时间timeEnd搜索得到回溯结束文件；接着程序将继续定位恢复起始数据行，由于日志文件的每行数据都记录着用户的操作时间，因此可以根据操作时间进行快速定位；回溯起始文件中，操作时间大于timeStart的第一条数据所在行即为恢复起始数据行lineStart；同样，回溯结束文件中，操作时间小于timeEnd的最后一条数据所在行即为恢复结束行lineEnd，然后程序将读取lineStart到lineEnd区间内的所有用户行为，并逐条将数据压入队列中，该队列创建在内存中，SeeLog日志每行数据构成的五元组将作为参数传入，该五元组存储在队列的每一个元素中；
步骤2.4采用管道流处理机制，首先任务执行中枢将解析Web应用中的数据源配置，并建立数据库连接，然后从队列中取出一个元素进入管道流，其他元素在队列中继续等待，任务执行中枢将读取元素中的五元数据组<OperateTime,[OperateType],SQL,{Parameters},[IsBatch]>，根据五元组中的是否批量属性IsBatch，确定是否开启数据库事务，读取SQL语句属性生成预处理语句，并将占位符参数Parameters填入，接着根据操作类型属性OperateType执行当前预处理语句，执行成功后，本条用户行为数据还原完毕，继续从队列中取出下一个元素进入管道流；当任务执行中枢取出当前队列中所有的元素后，会唤醒步骤2.3中等待的线程，此时可以继续读取日志文件中的下一部分数据；
步骤2.5若步骤2.4中的任务执行中枢未能成功执行预处理语句，将挂起从队列中读取元素进入管道流的操作，并每间隔一段时间重复执行一次当前的预处理语句，若能成功执行，则恢复挂起的操作，继续读取队列中的元素；若重复执行一定次数后，仍未能执行成功，将提示数据库恢复人员手工排查错误，并暂停整个程序的运行，直到当前预处理语句成功执行，程序才继续运行并恢复挂起的操作；当lineStart到lineEnd区间内的所有数据都恢复成功后，数据回溯完毕，数据库成功还原至故障发生之前的状态；
第三步、采用内存日志的自备份机制，将每个事务即时写入持久化层，保证内存日志不会丢失。
2.如权利要求1所述的一种面向Web开发环境的关系型数据库数据回溯方法，其特征在于：所述第三步中，如果Web服务器发生宕机或者重启，自上一次将内存中的日志写入持久化层到服务器发生宕机或重启这段时间内的日志，由于仅保存在内存中，还未及时写入持久化层，服务器的宕机或重启将会导致这部分日志丢失；
通过配备一台备份服务器，并提供一个额外线程，将该额外线程作为AOP通知，织入对数据库修改的切入点中，线程执行以下操作：在每条SQL操作语句及参数被写入内存的同时，将该条SQL语句和参数发送至备份服务器上；由于需要不间断地向备份服务器发送数据，并且发送频率不定，与用户行为密切相关，因此需要该线程与备份服务器之间建立长连接；
所述备份服务器每接收到一条SQL语句便直接持久化；同样，由于需要不间断地接收数据，并且接收频率不定，需要日志写入程序与持久化文件之间的IO通道保持打开的状态，备份服务器仅执行数据接收及持久化的操作，并不为其他应用提供服务，因此保持IO打开并不会产生其他影响；当单个文件数据行数达到Rowmax时，程序关闭当前IO通道，新建日志文件，以创建时间命名，并重新建立IO通道。
3.如权利要求1或2所述的一种面向Web开发环境的关系型数据库数据回溯方法，其特征在于：所述步骤1.1中，日志处理单元通过对底层连接数据库代码进行注入，记录下所有对系统增删改的SQL语句及其占位符参数，形成SeeLog日志，该日志为文本数据，反映了用户操作行为，每一行都代表一次用户的原子操作，每行数据是一个由操作时间OperateTime、操作类型OperateType、SQL语句、占位符参数Parameters、是否批量IsBatch操作构成的五元组；其中操作时间精确到毫秒，操作类型有插入、修改、删除3种取值，当批量操作为true时，需要分割占位符参数属性的取值，以便区分占位符参数的前后关系；日志数据使用半形式化方法来描述：
LogData＝OperateTime,[OperateType],SQL,{Parameters},[IsBatch].
OperateType＝’Insert’|’Update’|’Delete’
IsBatch＝’True’|’False’。
4.如权利要求1或2所述的一种面向Web开发环境的关系型数据库数据回溯方法，其特征在于：所述步骤2.3中，设立动态缓存，规定先将数据按序读入内存，当读取的数据行达到一定量后，暂停数据的读入，当前线程进入线程池中等待，此时队列将无法继续添加元素，实行单向流出策略，流出的数据将执行步骤2.4的操作，当列队中的元素全部流出后，唤醒数据读取的线程继续读入数据。
CN201710262218.8A 2017-04-20 2017-04-20 面向Web开发环境的关系型数据库数据回溯方法 Active CN107145403B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710262218.8A CN107145403B (zh) 2017-04-20 2017-04-20 面向Web开发环境的关系型数据库数据回溯方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710262218.8A CN107145403B (zh) 2017-04-20 2017-04-20 面向Web开发环境的关系型数据库数据回溯方法

Publications (2)

Publication Number Publication Date
CN107145403A CN107145403A (zh) 2017-09-08
CN107145403B true CN107145403B (zh) 2020-06-30

Family

ID=59775208

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710262218.8A Active CN107145403B (zh) 2017-04-20 2017-04-20 面向Web开发环境的关系型数据库数据回溯方法

Country Status (1)

Country Link
CN (1) CN107145403B (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108062263A (zh) * 2017-12-27 2018-05-22 深圳市科力锐科技有限公司 数据切换方法、装置、服务器、系统及存储介质
CN109992448B (zh) * 2017-12-31 2021-08-06 中国移动通信集团山西有限公司 文件变化增量备份方法、装置、设备及介质
CN108874592B (zh) * 2018-06-20 2020-04-10 焦点科技股份有限公司 一种针对Log-structured存储引擎的数据冷备方法及系统
CN111177141A (zh) * 2018-11-09 2020-05-19 上海擎感智能科技有限公司 利用MySQL并行复制恢复数据方法、设备及系统
CN110209527B (zh) * 2018-11-30 2023-05-05 腾讯科技（深圳）有限公司 数据恢复方法、装置、服务器以及存储介质
CN110399359B (zh) * 2019-07-24 2023-09-01 创新先进技术有限公司 一种数据回溯方法、装置及设备
CN110532123B (zh) * 2019-08-30 2023-08-04 北京小米移动软件有限公司 HBase系统的故障转移方法及装置
CN110750594B (zh) * 2019-09-30 2023-05-30 上海视云网络科技有限公司 一种基于mysql增量日志实时跨网络数据库同步方法
CN111046052B (zh) * 2019-11-11 2021-04-06 蚂蚁区块链科技(上海)有限公司 一种数据库中的操作记录存储方法、装置及设备
CN110895500A (zh) * 2019-11-18 2020-03-20 上海易点时空网络有限公司 基于mydumper的数据回档方法及装置、存储介质
CN110968592B (zh) * 2019-12-06 2023-11-21 深圳前海环融联易信息科技服务有限公司 元数据采集方法、装置、计算机设备及计算机可读存储介质
CN111737203A (zh) * 2020-06-09 2020-10-02 阿里巴巴集团控股有限公司 数据库历史日志回溯方法、装置、系统、设备及存储介质
CN112286892B (zh) * 2020-07-01 2024-04-05 上海柯林布瑞信息技术有限公司 后关系型数据库的数据实时同步方法及装置、存储介质、终端
CN111708749B (zh) * 2020-07-24 2021-01-12 深圳市富之富信息科技有限公司 操作日志记录方法、装置、计算机设备及存储介质
CN113300873B (zh) * 2021-02-05 2024-05-24 阿里巴巴集团控股有限公司 基于五元组哈希路径的故障绕行方法以及装置
CN114661248B (zh) * 2022-05-25 2022-10-04 恒生电子股份有限公司 数据处理方法及装置
CN117494146B (zh) * 2023-12-29 2024-04-26 山东街景智能制造科技股份有限公司 一种模型数据库管理系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103197988A (zh) * 2012-01-05 2013-07-10 中国移动通信集团湖南有限公司 一种数据备份、恢复的方法、设备和数据库系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10127259B2 (en) * 2011-09-29 2018-11-13 Oracle International Corporation System and method for database persistence of transaction logs
US8671085B2 (en) * 2011-12-09 2014-03-11 Microsoft Corporation Consistent database recovery across constituent segments

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103197988A (zh) * 2012-01-05 2013-07-10 中国移动通信集团湖南有限公司 一种数据备份、恢复的方法、设备和数据库系统

Also Published As

Publication number Publication date
CN107145403A (zh) 2017-09-08

Similar Documents

Publication Publication Date Title
CN107145403B (zh) 面向Web开发环境的关系型数据库数据回溯方法
US10884837B2 (en) Predicting, diagnosing, and recovering from application failures based on resource access patterns
US7386752B1 (en) Using asset dependencies to identify the recovery set and optionally automate and/or optimize the recovery
WO2019154394A1 (zh) 分布式数据库集群系统、数据同步方法及存储介质
US7814057B2 (en) Page recovery using volume snapshots and logs
US10169385B2 (en) Managing replicated data
US8849764B1 (en) System and method of data intelligent storage
US7590668B2 (en) Pausable backups of file system items
KR101044849B1 (ko) 자동 데이터베이스 또는 파일 시스템 정비 및 수리를 위한시스템 및 방법
US7340646B2 (en) Apparatus, system, and method for resource group backup
US9223661B1 (en) Method and apparatus for automatically archiving data items from backup storage
KR20150070134A (ko) 가상 데이터베이스를 생성하기 위한 소스 데이터베이스의 지정 시간 복사의 검색
US8103911B2 (en) Method and system for disaster recovery based on journal events pruning in a computing environment
US9037905B2 (en) Data processing failure recovery method, system and program
CN110543386B (zh) 一种数据存储方法、装置、设备和存储介质
CN111078667B (zh) 一种数据迁移的方法以及相关装置
JP2007524173A (ja) データベースのデータ復旧システムおよびその方法
US8762347B1 (en) Method and apparatus for processing transactional file system operations to enable point in time consistent file data recreation
WO2021008029A1 (zh) 案例执行方法、装置、设备及计算机可读存储介质
CN110569142A (zh) 一种oracle数据增量同步系统及方法
US20100185589A1 (en) Disaster recovery data sync
CN112380067A (zh) 一种Hadoop环境下基于元数据的大数据备份系统及方法
US20130262393A1 (en) Database backup without particularly specifying server
CN106649000A (zh) 实时处理引擎的故障恢复方法及相应的服务器
WO2023240995A1 (zh) 一种双机热备系统的数据恢复方法、装置及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant