CN105740104A - 数据库中数据备份方法、装置及游戏系统 - Google Patents

数据库中数据备份方法、装置及游戏系统 Download PDF

Info

Publication number
CN105740104A
CN105740104A CN201610077627.6A CN201610077627A CN105740104A CN 105740104 A CN105740104 A CN 105740104A CN 201610077627 A CN201610077627 A CN 201610077627A CN 105740104 A CN105740104 A CN 105740104A
Authority
CN
China
Prior art keywords
table data
myisam
data
innodb
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.)
Granted
Application number
CN201610077627.6A
Other languages
English (en)
Other versions
CN105740104B (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.)
Netease Hangzhou Network Co Ltd
Original Assignee
Netease Hangzhou Network Co Ltd
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 Netease Hangzhou Network Co Ltd filed Critical Netease Hangzhou Network Co Ltd
Priority to CN201610077627.6A priority Critical patent/CN105740104B/zh
Publication of CN105740104A publication Critical patent/CN105740104A/zh
Application granted granted Critical
Publication of CN105740104B publication Critical patent/CN105740104B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1461—Backup scheduling policy
    • 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
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • 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
    • 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/825—Indexing scheme relating to error detection, to error correction, and to monitoring the problem or solution involving locking

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

本发明提供了一种数据库中数据备份方法、装置及游戏系统，其中，该方法包括：启动InnoDB表数据的重做日志同步复制，对数据库的InnoDB表数据进行备份；查找数据库中的MyISAM表数据；对查找到的MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；对锁定的MyISAM表数据进行备份；当InnoDB表数据和MyISAM表数据复制完成时，停止InnoDB表数据的重做日志的同步复制，解决了相关技术中，对InnoDB和MyISAM并存的数据库进行备份时，对数据库服务的影响较大的问题，进而达到了不仅提高了备份效率，而且最大限度地减少了备份过程对数据库服务的影响的效果。

Description

数据库中数据备份方法、装置及游戏系统
技术领域
本发明涉及通信领域，具体而言，涉及一种数据库中数据备份方法、装置及游戏系统。
背景技术
MySQL数据库是目前使用的最广泛的数据库之一，它有着多种数据存储引擎，主流使用的有InnoDB和MyISAM两种。其中，InnoDB引擎支持事务(ACID)，支持行级别的锁，支持外键，在一致性要求高的业务中使用得比较多。而MyISAM是默认引擎，不支持事务、外键等，但由于它结构比较简单，读取、插入性能比较高，体积也相对小很多，支持数据压缩。在相关技术中，可以根据业务的需求去选取数据引擎，一般对于一致性要求高的热数据，使用InnoDB引擎，对于数据量较大的历史数据，统计数据之类的，使用MyISAM引擎，各取其长。
从备份对数据库服务的影响来说，数据库备份分为三类，分别是热备份(hotbackup)，暖备份(warmbackup)，冷备份(coolbackup)。热备份是指在备份过程中数据库正常运行，并且应用系统可以正常地读取和写入数据。暖备份是指备份过程中数据库正常运行，但对一些数据库操作限制执行，譬如备份过程中表是只读的。最后，冷备份是指停机备份。当然，对于要求24小时在线的服务来说，冷备份是不可以接受的，最好是热备份，即使一定要使用暖备份，也是希望限制越少，时间越短，对服务的影响降到最低。
从备份的范围来说，数据库备份又分为全备份和增量备份，全备份顾名思义就是包含了数据库中全部表数据的备份，增量备份是相对全备份而言的，只备份变化了的数据，很显然，增量备份会比全备份更快更小，对服务的影响也更小。
这样就存在一个问题，InnoDB和MyISAM并存的数据库如何进行备份，既可以保持数据一致性，又可以把对服务的影响降到最低呢？
在相关技术中，MySQL数据库有两个主流的备份工具，一个是官方收费的mysqlbackup，一个是开源免费的xtrabackup。它们对InnoDB引擎的热备份、全备份和增量备份都有很完备的解决方案。
InnoDB表数据之所以可以很容易地做热备份，是因为每个InnoDB页数据都有个版本号LSN，而可以从log中找出备份过程中的修改，对比一下InnoDB页的LSN来知道备份数据是否做了这个修改，从而备份完成之后，恢复出一个某一点的一致数据版本。
而MyISAM的表数据没有这个特性，所以MyISAM的备份如果要求一致性的话必须锁表。相关技术中的备份工具也支持InnoDB和MyISAM引擎并存的数据库备份，但对MyISAM的备份的实现较为“暴力”，对数据库服务的影响较大。备份过程大概是这样的：先利用InnoDB的LSN特性进行热备份，即不停机不锁表，复制InnoDB表数据，复制过程中继续复制log，在InnoDB表数据复制完成之后，锁住全部表(只读，暖备份)，然后复制MyISAM表数据，复制完成之后停止复制log，解锁。
对于MyISAM表较少，数据量也小的情况下，相关技术中的备份工具也足够了，但如果MyISAM表很多，并且体积也很大的话，就会很影响服务了，体现在以下几方面：
1、复制MyISAM过程中，MySQL进入暖备份，整个数据库都是只读的，如果MyISAM表比较多，数据比较大，这个暖备份时间还是很长的，这段时间内所有表都不能写入，连InnoDB表也不可以，这对于要求24小时在线的服务来说，这也是比较难接受的。
2、每次都备份所有的MyISAM表数据，备份体积会较大。
3、直接用系统命令cp复制MyISAM表，导致服务器IO负载升高。
因此，在相关技术中，对InnoDB和MyISAM并存的数据库进行备份时，对数据库服务的影响较大的问题。
发明内容
本发明提供了一种数据库中数据备份方法、装置及游戏系统，以至少解决相关技术中，对InnoDB和MyISAM并存的数据库进行备份时，对数据库服务的影响较大的问题。
根据本发明的一个方面，提供了一种数据库中数据备份方法，启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；查找所述数据库中的MyISAM表数据；对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；对锁定的MyISAM表数据进行备份；当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
优选地，在停止所述InnoDB表数据的重做日志的同步复制之后，还包括：依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
优选地，当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
优选地，在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
优选地，对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；确定每块复制块复制完成之后的空闲等待时间；依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
优选地，对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
根据本发明的另一方面，提供了一种数据库中数据备份装置，包括：备份模块，用于启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；查找模块，用于查找所述数据库中的MyISAM表数据；锁定模块，用于对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；所述备份模块，还用于对锁定的MyISAM表数据进行备份；停止模块，用于当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
优选地，该装置还包括：恢复模块，用于依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
优选地，当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
优选地，该装置还包括：解锁模块，用于在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
优选地，所述备份模块包括：划分单元，用于将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；第一确定单元，用于确定每块复制块复制完成之后的空闲等待时间；第一备份单元，用于依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
优选地，所述备份模块包括：第二确定单元，用于确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；第二备份单元，用于依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
根据本发明的还一方面，提供了一种游戏系统，包括任一项所述的数据库中数据备份装置。
通过本发明，采用启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；查找所述数据库中的MyISAM表数据；对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；对锁定的MyISAM表数据进行备份；当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制，解决了相关技术中，对InnoDB和MyISAM并存的数据库进行备份时，对数据库服务的影响较大的问题，进而达到了不仅提高了备份效率，而且最大限度地减少了备份过程对数据库服务的影响的效果。
附图说明
此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：
图1是根据本发明实施例的数据库中数据备份方法的流程图；
图2是根据本发明实施例的InnoDB和MyISAM并存的数据库全备份流程图；
图3是根据本发明实施例的分块复制MyISAM表数据的流程图；
图4是根据本发明实施例的InnoDB和MyISAM并存的数据库增量备份的流程图；
图5是根据本发明实施例的InnoDB和MyISAM并存的数据库备份进行恢复的流程图；
图6是根据本发明实施例的数据库中数据备份装置的结构框图；
图7是根据本发明实施例的数据库中数据备份装置的优选结构框图一；
图8是根据本发明实施例的数据库中数据备份装置的优选结构框图二；
图9是根据本发明实施例的数据库中数据备份装置中备份模块62的优选结构框图一；
图10是根据本发明实施例的数据库中数据备份装置中备份模块62的优选结构框图二；
图11是根据本发明实施例的游戏系统的结构框图。
具体实施方式
下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。
在本实施例中提供了一种数据库中数据备份方法，图1是根据本发明实施例的数据库中数据备份方法的流程图，如图1所示，该流程包括如下步骤：
步骤S102，启动InnoDB表数据的重做日志同步复制，对数据库的InnoDB表数据进行备份(需要说明的是，该MyISAM表数据具体到以下的MySQL数据库时也会用MyISAM表来表述)；
步骤S104，查找数据库中的MyISAM表数据；
步骤S106，对查找到的MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；
步骤S108，对锁定的MyISAM表数据进行备份；
步骤S110，当InnoDB表数据和MyISAM表数据复制完成时，停止InnoDB表数据的重做日志的同步复制。
通过上述步骤，在对整个数据库进行备份时，仅对MyISAM表数据进行锁定，相对于相关技术中对数据库进行备份时，需要对整个数据库进行锁定，数据库中所包括的所有的数据表都不能进行相关操作，较大地影响了数据库的服务功能。采用本发明实施例的仅对需要备份MyISAM表数据进行锁定，而后备份，不仅解决了相关技术中，对InnoDB和MyISAM并存的数据库进行备份时，对数据库服务影响较大的问题，有效地减少了在对数据库进行备份时，对数据库服务的影响。
由于在对MyISAM表数据进行备份的过程中，其它的数据，例如，InnoDB表数据也可能会发生变化，为保证整个数据库中的所存储的数据的一致性，在停止InnoDB表数据的重做日志的同步复制之后，还依据停止InnoDB表数据的重做日志时记录的重做日志，将数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
需要说明的是，只要重做日志在同步复制，InnoDB表数据可以恢复至某一时刻。而MyISAM表数据从锁定到解锁，时间是静止的。例如，9：00同步复制重做日志，并从9：00开始对数据库的InnoDB表数据进行备份；9：10锁定MyISAM表；11：00停止重做日志的复制；11：10解除MyISAM表的锁定。若让InnoDB表数据恢复至11：00，则本次备份的时间为11：00；若让InnoDB表数据恢复至于9：10(或10：00)，则本次备份的时间为9：10(或10：00)。
较优行，当将数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止重做日志的同步复制的时间标记为本次数据库一致性备份的时间。例如，若以11:00作为本次备份时间，下一次做差量数据备份的时候，这次9:00-11:00之间的数据就不需要再次复制，进一步减少运算量。
采用上述恢复的处理方式，依据重做日志中记录的InnoDB备份数据的版本号，以及InnoDB表数据重做日志结束的时间点，将数据库的InnoDB表数据和MyISAM表数据恢复至同步状态。采用这样的处理，使得数据库中备份的InnoDB表数据和MyISAM表数据是处于同一时间节点的，即两者是同步的，实现了两者的一致性。具体恢复过程，以及恢复前的准备过程在之后的优选实施方式中进行详细描述。
为进一步减少备份过程对数据库的影响，可以在对锁定的MyISAM表数据进行备份完成后，解除对MyISAM表数据的锁定。
当数据库所包括的InnoDB表数据和MyISAM表数据较大时，直接用系统命令cp整个文件是很占用系统IO的，所以可以根据需要制定一套备份策略去控制备份的速度，例如，可以采用以下多种备份策略对InnoDB表数据和/或MyISAM表数据进行备份，例如，可以采用增量备份的方式进行备份：确定当前时间点的InnoDB表数据和/或MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；依据确定的差量数据对InnoDB表数据和/或MyISAM表数据进行备份。
采用上述增量备份的处理方式，相对于对整个MyISAM表数据进行备份而言，备份体积过大，浪费存储空间浪费资源。而MyISAM表数据并非更新频繁，修改的地方有限。因此，为进一步节约备份资源，可以只对修改的数据做备份，这样可以隔段时间才做一次全备份，这样可以大大缩短备份所需要的时间和减低要消耗的资源。
又例如，还可以采用分块备份的方式，先将锁定的MyISAM表数据划分为预定数目的复制块；确定每块复制块复制完成之后的空闲等待的时间；依据确定的空闲等待时间，对预定数目的复制块进行复制。采用上述分块复制和备份的方式，最大限定地减少了对服务器负载的影响。
基于上述实施例及优选实施例，针对InnoDB和MyISAM双引擎并存的，并且24小时不停机，对数据备份一致性要求高的数据库，在本实施例中，提供了一种对数据库服务影响最小的全量和增量的备份方法。下面对该方法进行大致说明。
本发明实施例所提供的备份方法是在相关技术中的备份工具的备份流程上面做改进，增加非锁全表复制、MyISAM的增量备份、MyISAM的分块复制等的特性。
1非锁全表复制
在复制MyISAM表数据的暖备份过程中，只锁住需要备份的MyISAM表，其他表不受影响，这样既保证了一致性，并且InnoDB的热数据可以一直写入，而放入MyISAM表中的数据的一般是历史数据或者统计数据等的冷数据，所以这个影响也是可以接受的。
2MyISAM的增量备份
对MyISAM表做增量备份，通过比较文件的最后修改时间，只复制修改过的表数据文件。而MyISAM一般都是统计表，冷数据，每天只对部分表更新数据，这个处理使得复制体积大为减少，加快了复制进程。
3MyISAM分块复制
当MyISAM表数据很大的时候，直接cpMyISAM表数据的时候把服务器弄得很卡，IO非常高，很耗系统资源。在本实施例中，使用分块复制的方式，“控制”复制速度，增加参数可调整块的大小和复制完一块之后sleep的秒数。这样修改之后，备份对数据库的影响可以调节，尽量不影响在线服务。
通过上述措施保证数据一致性的前提下，尽可能减少备份对数据库服务的影响。
结合上述实施例，对本发明优选实施方式进行说明。
在介绍备份流程之前，先解析一下几个重要概念。
1redolog(重做日志)
InnoDB存储引擎的重做日志文件记录的关于每个页的更改的物理情况，包括未提交的事务的变更，它用于数据库异常关闭的时候，恢复InnoDB的数据。它是持久化在物理磁盘中的一组文件，譬如ib_logfile0ib_logfile1。
2LSN(logsequencenumber)
LSN是重做日志里的数据库全局的版本号，InnoDB表数据页也有LSN标识，表示该数据页最新更新的LSN版本号。
3InnoDB表数据文件
InnoDB表数据主要存放在一个或者一组ibdata文件(系统空间文件)，包括元数据，undolog和各种buffer。如果没开启innodb_file_per_table的话，还包含所有databases的InnoDB表数据和索引数据。如果开启了innodb_file_per_table的话，每个表数据和索引会存放在单独的表空间，譬如表test会有一个对应的test.ibd。
4MyISAM表数据文件
每个MyISAM表都有对应的一个.MYD和.MYI文件，其中.MYD是表数据文件，.MYI是表索引文件。
结合上述概念，下面对本发明优选实施例进行说明。
图2是根据本发明实施例的InnoDB和MyISAM并存的数据库全备份流程图，如图2所示，该流程包括如下步骤：
步骤S202，启动一个后台进程去复制log；
需要说明的是，这里的log是指InnoDB的重做日志，由于后面复制InnoDB表数据需要一段时间，这个过程中数据库也不断有更新，会复制到不同版本的数据文件，而本发明实施例的备份是要求强一致性的，所以后面恢复数据的时候，需要根据重做日志去恢复成某个版本号的一致的数据。
步骤S204，复制InnoDB表数据；
在本步骤中，该复制包括复制系统空间(ibdata1)和复制表空间(.ibd)的数据。为了加快复制进程，可以配置开多个线程并行复制，每个线程复制不同的文件。尽管这个复制是在线复制，不需要停机，但数据量大的时候复制的时间比较长，也占用系统IO，所以可以对复制做一些限制，譬如xtrabackup可以指定每秒钟复制多少M的数据。
相关技术中的备份工具对于InnoDB表数据复制方案都比较完备，如果服务器配置较好，需要加快复制进程，那可以配置多开几个线程并行复制，如果服务器配置较差，或者服务比较繁忙，避免影响服务，则可以限制每秒复制的数据量，这些都可以根据实际情况配置。
步骤S206，找出所有需要备份的MyISAM表；
当InnoDB复制完成之后，可以做一些额外的备份操作，譬如复制MyISAM表数据，或者表结构(.frm)数据，但如何保证整个数据库备份的一致性呢？
这时InnoDB表数据变化是没关系的，因为步骤S202中的redolog还是在一直复制，所以后面还是可以通过log去把复制完成的InnoDB表数据准备好，恢复到某一点一致的数据。如果要备份MyISAM的数据的话，那么需要把要备份的MyISAM表加个读锁，只读不能写，保证复制的MyISAM表数据跟InnoDB表数据是一致的。这时InnoDB表不受影响，可以读和写。
如何找出要备份的MyISAM表数据呢？遍历数据库目录，找出所有.MYD后缀的文件
譬如数据库目录在/home/database/，找到下面所有的.MYD文件有
/home/database/a/test1.MYD
/home/database/a/test2.MYD
/home/database/b/test3.MYD
其中，a和b都是db，那么需要备份的MyISAM表有a.test1a.test2b.test3
步骤S208，锁住需要备份的MyISAM表；
在复制MyISAM表数据之前，需要让MySQL关闭MyISAM文件，并且确保数据都写到磁盘上了，没有在buffer中，于是可以执行以下语句去刷新缓冲区并且获取一个读锁：
FLUSHTABLESa.test1,a.test2,b.test3WITHREADLOCK
执行成功之后，数据库进入了暖备份阶段，不过这时InooDB表不受影响，可以照常读写，MyISAM表只读不能写，MyISAM通常是历史数据或者统计数据等的冷数据，所以影响比较小。
步骤S210，复制MyISAM表数据；
这里复制的数据包括MyISAM的数据文件(.MYD)和索引文件(.MYI)。当MyISAM表数据太大的时候，直接用系统命令cp整个文件是很占用系统IO的，所以在本发明实施例中，提供了一套策略去控制复制的速度。
这个策略主要是分块复制，控制复制块的大小和每块复制完成之后空闲等待的时间。图3是根据本发明实施例的分块复制MyISAM表数据的流程图，如图3所示，该流程包括如下步骤：
步骤S302，打开源文件；
步骤S304，打开目标文件；
步骤S306，从源文件中读取一块数据；
步骤S308，写进目标文件，并刷新缓冲区；
步骤S310，空闲等待一段时间，再读取再写入；
步骤S312，判断复制是否完成，在判断结果为是的情况下，进入步骤S314，否则返回步骤S306；
步骤S314，结束。
需要注意的是，如果这里不刷新缓冲的话，有可能都放在系统缓冲区中，没有真正地写进去目标文件，而等缓冲满了的时候再一次性写入，这样的话也有可能导致IO突然升高而影响数据库其他服务。这个策略的目标是分块复制和写入，尽量减少对服务器负载的影响。
注意，复制期间需要一直保持步骤S308中的读锁，但复制可能需要时间较长，可能会出现连接空闲等待timeout断开，锁释放掉的情况，所以这里还需要每复制一定数量的数据块就执行个select语句去保持连接。譬如
SELECT1
这样连接才不会空闲过久断开。
步骤S212，停止复制log的后台进程；
当MyISAM表数据也复制完成之后，就可以停止步骤S202步的后台复制log进程了，结束InnoDB的备份，停止之后会获得一个最后log的LSN，这个LSN是InnoDB备份的最终版本号。
另外，除了LSN之外，还得到一个MySQLbinlog的position，这个position可以跟binlog对应上，用于以后使用binlog进行备份恢复，或者设置主从备份。因为在步骤S208中锁住了MyISAM表，复制MyISAM表过程中数据没变化，所以可以认为InnoDB和MyISAM表数据是一致的，是同一个备份点的数据。
步骤S214，解锁；
InnoDB表数据备份结束之后，可以先把当前时间记录下来，这个时间标记MyISAM表数据的备份时间，然后可以把之前步骤S208的锁释放掉，结束MyISAM的备份，执行
UNLOCKTABLES；
步骤S216，记录备份信息；
需要把备份的关键信息记录下来，用于备份恢复或者后续的增量备份，关键信息包括步骤S212中的LSN和binlogposition，以及步骤S214中的MyISAM备份时间。
以上就是整个数据库的全备份流程，可见，整个过程对数据库服务的影响非常少，只是复制MyISAM阶段进入了暖备份，并且对InnoDB表没影响。
图4是根据本发明实施例的InnoDB和MyISAM并存的数据库增量备份的流程图，如图4所示，增量备份顾名思义是说只备份修改了的数据，根据二八原则，80％的数据修改只集中在20％的数据里面(当然，这是业务相关的，可能你惊讶地发现这个占比会更小)，每次都对全部数据做备份，无疑使浪费存储空间浪费资源的事情，如果能每天只对修改的数据做备份，隔段时间(譬如一周)才做一次全备份，这样可以大大缩短备份所需要的时间和减低要消耗的资源。增量备份包括一下步骤：
步骤S402，读取上一次的备份信息；
因为增量备份是基于之前的备份，首先需要知道从哪里开始记录修改，主要需要的是全备份中步骤S216中记录的InnoDB的备份的LSN和MyISAM的备份时间；
步骤S404，启动后台进程去复制redolog；此步骤同全备份实施例中的步骤S202；
步骤S406，复制修改过的InnoDB表数据(.ibd)；
复制包括复制系统空间(ibdata1)和复制表空间(.ibd)的数据。由于InnoDB每个数据页都有一个LSN版本号，标记该数据页最后更新的版本，所以增量复制过程中，对每个数据页的LSN跟上次备份的LSN做比较，当数据页自上次备份又修改过才复制，复制的数据量大为减少。
可见，这里复制的不是完整的.ibd或者ibdata1文件，而是文件修改的差量。
步骤S408，找出修改过的需要备份的MyISAM表；
跟全备份的步骤S306差不多，不同的是找出MyISAM表之后，需要对比MyISAM文件的最后修改时间，如果修改时间在上次MyISAM的备份时间之后的才复制。譬如之前找出的MyISAM表有a.test1a.test2b.test3，我们对比
/home/database/a/test1.MYD
/home/database/a/test1.MYI
的修改时间都比上次MyISAM的备份时间前，于是就不用处理a.test1，后面只锁住和复制a.test2b.test3好了。
步骤S410，锁住需要备份的MyISAM表；该步骤同全备份实施例中的步骤S208，但只锁住修改过的MyISAM表；
步骤S412，复制MyISAM表数据；此步骤同全备份实施例中的步骤S210，但只复制修改过的MyISAM表；
步骤S414，停止复制log的后台进程；此步骤同全备份实施例中的步骤S212；
步骤S416，解锁；此步骤同全备份实施例中的步骤S214；
步骤S418，记录备份信息(版本号LSN、备份时间)；此步骤同全备份实施例中的步骤S216；
以上就是整个数据库的增量备份流程，可见，整个过程相对全备份更快速，因为只复制了修改过的InnoDB表数据页，只复制了修改过的MyISAM表数据，暖备份阶段也只是部分需要复制的MyISAM表只读，对数据库服务的影响非常少。
图5是根据本发明实施例的InnoDB和MyISAM并存的数据库备份进行恢复的流程图，如图5所示，InnoDB的数据准备好主要包含两个操作，一个是应用redolog，把已提交的事务重做到对应的InnoDB表数据页中，二是应用undolog，把未提交(rollback)了的事务修改在对应的InnoDB表数据页中撤销掉。而MyISAM表数据的恢复就比较简单，.MYD.MYI文件直接复制到对应目录就能用了。具体备份准备好用于恢复的步骤如下：
步骤S502，应用全备份的redolog；在全备份中，根据复制的redolog去把已提交的事务应用到全备份的InnoDB表数据页中。
步骤S504，合并增量备份的InnoDB表数据页；把增量备份中InnoDB差量文件合并到全备份中的InnoDB表数据页，具体的算法实现就不在这里详细介绍了，相关技术中的备份恢复工具都有完备的方案。
步骤S506，应用增量备份的redolog；在全备份中已合并好的InnoDB表数据页中，根据增量备份的redolog去把已提交的事务应用上去。
步骤S508，合并增量备份的MyISAM文件；因为备份MyISAM的时候是整个文件备份的，增量备份只备份有修改的文件，所以准备数据的时候直接把增量备份的MyISAM表文件覆盖到全备份的对应文件中就行了。
步骤S510，判断是否还有增量备份，在判断结果为是的情况下，返回步骤S504，否则进入步骤S512；
步骤S512，把未提交的事务rollback。
根据最后合并后系统空间文件(ibdata)的undolog，去把未提交的事务在对应的InnoDB页数据中撤销掉。其实这个步骤是可以跳过的，因为MySQL启动的时候会自动检测是否异常关闭，并且rollback未提交的事务。
这样，数据库备份数据就完全准备好了，可以直接启动MySQL，这时数据库恢复到InnoDB和MyISAM表数据一致的状态，即备份完成时对应的binlogposition的那一点的状态。
综上，本发明实施例的备份方案适用于InnoDB和MyISAM引擎并存的24小时在线的数据库，通过暖备份过程中只锁住相关的MyISAM表，增量备份时MyISAM修改时间检测等手段，保持InnoDB和MyISAM备份的一致性，减少暖备份过程中对服务的影响。另外，利用分块复制的方法，控制MyISAM大文件复制时的速度，调整对服务器负载和IO的影响。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例的方法。
在本实施例中还提供了一种数据库中数据备份装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。
图6是根据本发明实施例的数据库中数据备份装置的结构框图，如图6所示，该装置包括：备份模块62、查找模块64、锁定模块66和停止模块68，下面对该装置进行说明。
备份模块62，用于启动InnoDB表数据的重做日志同步复制，对数据库的InnoDB表数据进行备份；查找模块64，用于查找数据库中的MyISAM表数据；锁定模块66，连接至上述查找模块64，用于对查找到的MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；备份模块62，连接至上述锁定模块66，还用于对锁定的MyISAM表数据进行备份；停止模块68，连接至上述备份模块62，用于当InnoDB表数据和MyISAM表数据复制完成时，停止InnoDB表数据的重做日志的同步复制。
图7是根据本发明实施例的数据库中数据备份装置的优选结构框图一，如图7所示，该装置除包括图6所示的所有结构外，还包括：恢复模块72，下面对该恢复模块72进行说明。
恢复模块72，连接至上述备份模块62，用于依据停止InnoDB表数据的重做日志时记录的重做日志，将数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
优选地，当将数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
图8是根据本发明实施例的数据库中数据备份装置的优选结构框图二，如图8所示，该装置除包括图6所示的所有结构外，还包括：解锁模块82，下面对该解锁模块82进行说明。
解锁模块82，连接至上述备份模块62，用于在对锁定的MyISAM表数据进行备份完成后，解除对MyISAM表数据的锁定。
图9是根据本发明实施例的数据库中数据备份装置中备份模块62的优选结构框图一，如图9所示，该备份模块62包括：划分单元92、第一确定单元94和第一备份单元96，下面对该备份模块62进行说明。
划分单元92，用于将InnoDB表数据和/或MyISAM表数据划分为预定数目的复制块；第一确定单元94，连接至上述划分单元92，用于确定每块复制块复制完成之后的空闲等待时间；第一备份单元96，连接至上述第一确定单元94，用于依据确定的空闲等待时间，对预定数目的复制块进行复制备份。
图10是根据本发明实施例的数据库中数据备份装置中备份模块62的优选结构框图二，如图10所示，该备份模块62包括：第二确定单元102和第二备份单元104，下面对该备份模块62进行说明。
第二确定单元102，用于确定当前时间点的InnoDB表数据和/或MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；第二备份单元104，连接至上述第二确定单元102，用于依据确定的差量数据对InnoDB表数据和/或MyISAM表数据进行备份。
图11是根据本发明实施例的游戏系统的结构框图，如图11所示，该游戏系统110包括上述任一项的数据库中数据备份装置112。
需要说明的是，上述各个模块是可以通过软件或硬件来实现的，对于后者，可以通过以下方式实现，但不限于此：上述模块均位于同一处理器中；或者，上述模块分别位于多个处理器中。
本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以被设置为存储用于执行以下步骤的程序代码：
S1，启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；
S2，查找所述数据库中的MyISAM表数据；
S3，对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；
S4，对锁定的MyISAM表数据进行备份；
S5，当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
在停止所述InnoDB表数据的重做日志的同步复制之后，依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：
S1，将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；
S2，确定每块复制块复制完成之后的空闲等待时间；
S3，依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
可选地，存储介质还被设置为存储用于执行以下步骤的程序代码：
对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：
S1，确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；
S2，依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
可选地，在本实施例中，上述存储介质可以包括但不限于：U盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；查找所述数据库中的MyISAM表数据；对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；对锁定的MyISAM表数据进行备份；当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在停止所述InnoDB表数据的重做日志的同步复制之后，还包括：依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；确定每块复制块复制完成之后的空闲等待时间；依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
可选地，在本实施例中，处理器根据存储介质中已存储的程序代码执行：对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
可选地，本实施例中的具体示例可以参考上述实施例及可选实施方式中所描述的示例，本实施例在此不再赘述。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (13)

1.一种数据库中数据备份方法，其特征在于，包括：
启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；
查找所述数据库中的MyISAM表数据；
对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；
对锁定的MyISAM表数据进行备份；
当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
2.根据权利要求1所述的方法，其特征在于：在停止所述InnoDB表数据的重做日志的同步复制之后，还包括：
依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
3.根据权利要求2所述的方法，其特征在于：当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
4.根据权利要求1所述的方法，其特征在于：在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
5.根据权利要求1所述的方法，其特征在于：对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：
将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；
确定每块复制块复制完成之后的空闲等待时间；
依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
6.根据权利要求1所述的方法，其特征在于：对所述InnoDB表数据和/或所述MyISAM表数据进行备份包括：
确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；
依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
7.一种数据库中数据备份装置，其特征在于，包括：
备份模块，用于启动InnoDB表数据的重做日志同步复制，对所述数据库的InnoDB表数据进行备份；
查找模块，用于查找所述数据库中的MyISAM表数据；
锁定模块，用于对查找到的所述MyISAM表数据进行锁定，其中，锁定了的MyISAM表数据只允许读操作不允许写操作；
所述备份模块，还用于对锁定的MyISAM表数据进行备份；
停止模块，用于当所述InnoDB表数据和所述MyISAM表数据复制完成时，停止所述InnoDB表数据的重做日志的同步复制。
8.根据权利要求7所述的装置，其特征在于：还包括：
恢复模块，用于依据停止所述InnoDB表数据的重做日志时记录的重做日志，将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态。
9.根据权利要求8所述的装置，其特征在于：当将所述数据库的InnoDB表数据恢复至和MyISAM表数据同步的状态时，以停止所述重做日志的同步复制的时间标记为本次数据库一致性备份的时间。
10.根据权利要求7所述的装置，其特征在于：还包括：解锁模块，用于在对锁定的所述MyISAM表数据进行备份完成后，解除对所述MyISAM表数据的锁定。
11.根据权利要求7所述的装置，其特征在于：所述备份模块包括：
划分单元，用于将所述InnoDB表数据和/或所述MyISAM表数据划分为预定数目的复制块；
第一确定单元，用于确定每块复制块复制完成之后的空闲等待时间；
第一备份单元，用于依据确定的所述空闲等待时间，对所述预定数目的复制块进行复制备份。
12.根据权利要求7所述的装置，其特征在于：所述备份模块包括：
第二确定单元，用于确定当前时间点的所述InnoDB表数据和/或所述MyISAM表数据相比于已备份的InnoDB表数据和/或MyISAM表数据的差量数据；
第二备份单元，用于依据确定的所述差量数据对所述InnoDB表数据和/或所述MyISAM表数据进行备份。
13.一种游戏系统，其特征在于，包括权利要求7至12中任一项所述的数据库中数据备份装置。
CN201610077627.6A 2016-02-03 2016-02-03 数据库中数据备份方法、装置及游戏系统 Active CN105740104B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201610077627.6A CN105740104B (zh) 2016-02-03 2016-02-03 数据库中数据备份方法、装置及游戏系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201610077627.6A CN105740104B (zh) 2016-02-03 2016-02-03 数据库中数据备份方法、装置及游戏系统

Publications (2)

Publication Number Publication Date
CN105740104A true CN105740104A (zh) 2016-07-06
CN105740104B CN105740104B (zh) 2018-10-30

Family

ID=56241861

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201610077627.6A Active CN105740104B (zh) 2016-02-03 2016-02-03 数据库中数据备份方法、装置及游戏系统

Country Status (1)

Country Link
CN (1) CN105740104B (zh)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108573019A (zh) * 2018-01-23 2018-09-25 北京金山云网络技术有限公司 一种数据迁移方法、装置、电子设备及可读存储介质
CN108959548A (zh) * 2018-07-02 2018-12-07 阿里巴巴集团控股有限公司 业务请求的处理方法及装置
CN108958967A (zh) * 2017-05-17 2018-12-07 腾讯科技（深圳）有限公司 一种数据处理的方法以及服务器
CN109240852A (zh) * 2018-08-27 2019-01-18 郑州云海信息技术有限公司 一种数据拷贝的方法和装置
CN109558455A (zh) * 2018-12-03 2019-04-02 上海热璞网络科技有限公司 一种数据库备份方法、装置及服务器
CN110825562A (zh) * 2019-09-16 2020-02-21 北京京东尚科信息技术有限公司 数据备份方法、装置、系统和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102937955A (zh) * 2011-11-29 2013-02-20 Ut斯达康通讯有限公司 一种基于MySQL双存储引擎的内存数据库实现方法
US20140012831A1 (en) * 2012-07-07 2014-01-09 David Whitney Wallen Tile content-based image search
US20150142733A1 (en) * 2013-11-18 2015-05-21 Ori Software Development Ltd. System and method for efficient management of big data in a database using streaming tables
CN104657382A (zh) * 2013-11-21 2015-05-27 阿里巴巴集团控股有限公司 用于MySQL主从服务器数据一致性检测的方法和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102937955A (zh) * 2011-11-29 2013-02-20 Ut斯达康通讯有限公司 一种基于MySQL双存储引擎的内存数据库实现方法
US20140012831A1 (en) * 2012-07-07 2014-01-09 David Whitney Wallen Tile content-based image search
US20150142733A1 (en) * 2013-11-18 2015-05-21 Ori Software Development Ltd. System and method for efficient management of big data in a database using streaming tables
CN104657382A (zh) * 2013-11-21 2015-05-27 阿里巴巴集团控股有限公司 用于MySQL主从服务器数据一致性检测的方法和装置

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108958967A (zh) * 2017-05-17 2018-12-07 腾讯科技（深圳）有限公司 一种数据处理的方法以及服务器
CN108958967B (zh) * 2017-05-17 2023-01-24 腾讯科技（深圳）有限公司 一种数据处理的方法以及服务器
CN108573019A (zh) * 2018-01-23 2018-09-25 北京金山云网络技术有限公司 一种数据迁移方法、装置、电子设备及可读存储介质
CN108959548A (zh) * 2018-07-02 2018-12-07 阿里巴巴集团控股有限公司 业务请求的处理方法及装置
CN108959548B (zh) * 2018-07-02 2023-04-18 创新先进技术有限公司 业务请求的处理方法及装置
CN109240852A (zh) * 2018-08-27 2019-01-18 郑州云海信息技术有限公司 一种数据拷贝的方法和装置
CN109558455A (zh) * 2018-12-03 2019-04-02 上海热璞网络科技有限公司 一种数据库备份方法、装置及服务器
CN110825562A (zh) * 2019-09-16 2020-02-21 北京京东尚科信息技术有限公司 数据备份方法、装置、系统和存储介质

Also Published As

Publication number Publication date
CN105740104B (zh) 2018-10-30

Similar Documents

Publication Publication Date Title
CN105740104A (zh) 数据库中数据备份方法、装置及游戏系统
US5999931A (en) Concurrency control protocols for management of replicated data items in a distributed database system
CN109739935B (zh) 数据读取方法、装置、电子设备以及存储介质
Walborn et al. Supporting semantics-based transaction processing in mobile database applications
US7383293B2 (en) Database backup system using data and user-defined routines replicators for maintaining a copy of database on a secondary server
US7240054B2 (en) Techniques to preserve data constraints and referential integrity in asynchronous transactional replication of relational tables
EP2356560B1 (en) Atomic multiple modification of data in a distributed storage system
US20070088769A1 (en) Reorganization and repair of an icf catalog while open and in-use in a digital data storage system
US20060129618A1 (en) Method and a computer system for synchronising backups of objects and of meta data about the objects
CN102024015A (zh) 用于批量删除数据库系统的数据记录的方法
US8572027B2 (en) Performing synchronization among relational database tables with minimal contention
CA2423153A1 (en) Collision avoidance in database replication systems
CN107025242A (zh) 数据库间数据的复制方法及装置
WO2002093420A2 (en) Method for managing distributed savepoints across multiple dbms's within a distributed transaction
US20100169289A1 (en) Two Phase Commit With Grid Elements
CN109902127B (zh) 历史态数据处理方法、装置、计算机设备及存储介质
US11003550B2 (en) Methods and systems of operating a database management system DBMS in a strong consistency mode
Coan et al. Limitations on database availability when networks partition
CN102937955A (zh) 一种基于MySQL双存储引擎的内存数据库实现方法
CN110188084A (zh) 一种分布式文件存储系统及文件存储方法
CN114003657A (zh) 分布式数据库的数据处理方法、系统、设备和存储介质
US20090132534A1 (en) Remote replication synchronizing/accessing system and method thereof
Mullen et al. On the impossibility of atomic commitment in multidatabase systems
US20070260579A1 (en) Method of designing query classification component for multilevel dbms
US20100082551A1 (en) Data placement transparency for high availability and load balancing

Legal Events

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