CN101923498A - 数据库全量自动备份系统及方法 - Google Patents

Abstract

本发明提供了一种数据库全量自动备份系统，其特征在于，包括一个单独的数据库模块，数据库全量自动备份系统，表结构存储模块，备份状态信息模块，数据临时存储模块，全局锁模块，打包压缩模块，管理模块，以及目标存储模块。所述全量自动备份系统架设在所述数据库模块内，与管理模块信号连接，并由管理模块控制；各种数据或信号命令传输至打包压缩模块，并通过打包压缩模块将备份文件传输至目标存储模块。本发明的数据库自动全量备份系统及方法能够通过各种不同方法的系统的整合，达到数据库表结构、数据内容、环境变量、数据库参数等全面合理地进行备份存储，并且能够更有效地利用空间，且对于各种错误的容错率高。

Description

数据库全量自动备份系统及方法

技术领域

本发明涉及一种数据库备份系统，尤其涉及一种数据库全量自动备份系统及其方法。

背景技术

数据丢失对大小企业来说都是个恶梦，业务数据与企业日常业务运作唇齿相依，损失这些数据，即使是暂时性，亦会威胁到企业辛苦赚来的竞争优势，更可能摧毁你公司的声誉，或可能引致昂贵的诉讼和索偿费用。

在震惊世界的美国“9·11”恐怖事件发生后，许多人将目光投向金融界巨头摩根士丹利公司。这家金融机构在世贸大厦租有25层，惨剧发生时有2000多名员工正在楼内办公，公司受到重创。可是正当大家扼腕痛惜时，该公司宣布，全球营业部第二天可以照常工作。其主要原因是它在新泽西州建立了灾备中心，并保留着数据备份，从而保障公司全球业务的不间断运行。灾备的重要性和巨大价值由此可见一斑。

所谓数据灾备，就是指建立一个异地的数据系统，该系统是本地关键应用数据的一个可用复制。在本地数据及整个应用系统出现灾难时，系统至少在本地或者异地保存有一份可用的关键业务的数据。该数据可以是与本地生产数据的完全实时复制，也可以比本地数据略微落后，但一定是可用的。采用的主要技术是数据复制，数据传输以及数据存储等技术。

传统的灾备体系(数据备份系统)，其体系庞大，结构复杂，且对设备的要求较为严苛，因而费用昂贵。同时，这些传统的灾备体系均根据各自的数据库设置方式设有专门的控制系统，且难以与其他现有系统兼容。

随着越来越多的传统企业开始考虑使用开源产品降低成本，数据库方面尤其以MySQL突出，而利用MySQL在企业级的数据库灾备体系中的应用还未能得到充分开发。

提到备份，众所周知的利用MySQL所提供的一些工具能够完成简单的备份，但在涉及到企业级的数据库的灾备体系的建设的问题，却没有任何现有的较为成功的实践先例。因此，对于利用MySQL的基础，建设企业级数据库备份体系，存在了如下的需求：

■当你只有几台数据库的时候你只需要一个备份命令或者一个备份工具就可以完成，

■当你有百台左右的数据库时候，你会不得不写脚本来自动帮你完成，

■当你有更多数据库，你会发现每天维护这个备份列表，开启和关闭，调整某些备份将会成为一个瓶颈，此时你需要一个web系统能更简易的系统完成这些日常维护工作，

■当业务体系越来越复杂的时候，不同存储引擎，不同的逻辑，不同的备份保留间隔等各式各样的需求都会使得我们不断在备份系统上扩充功能

■当同时维护MySQL和Oracle的备份工作时，此时你需要一个平台能容纳不同的数据库备份需求，

■当这些底层的备份细节都实现后，如何保障本地，本市的灾难发生后依然有备份的数据可恢复，这就涉及到如何把本地备份的数据保留倒同城异地，异城，甚至是银行保存，一整套策略

■最后解决灾难的最终依据是灾难后的数据恢复，所以如何制定数据恢复，灾难演习的策略，并记录经验，

上述这些都是普通数据库运行和维护人员在实践过程中所能够普遍遇到的问题，而将这些普遍的需求进行整合，并有针对性地加以解决，一步步升华，这样从简单的命令行备份到最终得到一套完整的灾备体系。以上这些从最底层的备份实现细节，到满足各种备份需求的功能，到容灾恢复策略，一起就构成了灾备体系。

发明内容

本发明的目的在于提供一种安全、高效的企业级数据库备份系统和方法，其主要利用现有的MySQL数据库管理系统，并且兼容于Oracle数据库管理系统中。采用多种数据库备份模式，包括InnoDB，MyISAM，TAR等多种备份工具或备份系统，并分别包括对主设备以及从设备，以及对多种备份数据工具或系统的功能整合以及混合运用。

本发明所提供的企业级数据库备份系统所采取的技术方案如下：

提供了一种数据库全量自动备份系统，其中，包括一个单独的数据库模块(1000)，数据库全量自动备份系统(1100)，表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)，打包压缩模块(1105)，管理模块(1109)，以及目标存储模块(1200)；

所述全量自动备份系统(1100)架设在所述数据库模块(1000)内，与管理模块(1109)信号连接，并由管理模块(1109)控制；其内部的表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)相互连接，且均与打包压缩模块(1105)信号连接，将各种数据或信号命令传输至打包压缩模块(1105)，并通过打包压缩模块(1105)将备份文件传输至目标存储模块(1200)。

上述的数据库全量自动备份系统，其中，所述的表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)，打包压缩模块(1105)均为可读写的数据存储设备。

上述的数据库全量自动备份系统，其中，所述目标存储模块(1200)为一任意服务器或主机，用于存储备份资料或临时存放备份数据。

上述的数据库全量自动备份系统，其中，还包括：同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)，离线磁带机(20)，财务/银行保管系统(30)，本地电信机房(41)，本地网通机房(42)；

所述的本地电信机房(41)以及本地网通机房(42)与同城数据库(11)连接，备份本地数据；

所述的同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)依次连接，互相备份异地数据；

所述的同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)均与离线磁带机(20)连接，定期备份离线数据；

所述数据库全量自动备份系统(1100)设置在任意一台进行备份的数据库或机房中，所述的目标存储模块(1200)为任意一台接受传输数据的设备。

上述的数据库全量自动备份系统，其中，所述离线数据存储于离线磁带机(20)的离线磁带中，所述离线磁带存放于所述财务/银行保管系统中。

上述的数据库全量自动备份系统，其中，所述的本地电信机房(41)与本地网通机房(42)均与同城数据库(11)分别设立在不同地点。

上述的数据库全量自动备份系统，其中，所述的同城数据库(11)通过网络将备份数据传输至第一异城数据库(12)；第一异城数据库(12)通过网络将备份数据传输至第一异城数据库(13)；第二异城数据库(13)通过网络将备份数据传输至同城数据库(11)，形成循环异地数据备份体系。

本发明还提供了一种数据库全量自动备份系统的备份方法，其具体包括MySQL备份流程；采用Master InnoDB DUMP策略的备份流程图，用于备份主设备；采用STRUCTURE DUMP策略的备份流程图，用于备份表结构。

本发明的数据库自动全量备份系统及方法能够通过各种不同方法的系统的整合，达到数据库表结构、数据内容、环境变量、数据库参数等全面合理地进行备份存储，并且能够更有效地利用空间，且对于各种错误的容错率高。本发明所提供的是一种宏观的数据库备份体系的实现方法，具有广泛的兼容性，能够应用于各种数据库备份系统中，并且通过其多层分级的备份系统的建立，能够有效地提高整个数据库系统的容灾强度，即使在发生各种灾害事件的情况下，也能保障数据库可以恢复到一定时间之前的状态，保障了数据的安全性和稳定性。

附图说明

图1为本发明的数据库全量自动备份系统的网络架构模块图；

图2为本发明的数据库全量自动备份系统的主要流程图；

图3为本发明的数据库全量自动备份系统的MySQL备份流程图；

图4为本发明的数据库全量自动备份系统的Oracle备份流程图；

图5为本发明具体采用Master InnoDB DUMP的备份流程图；

图6为本发明具体采用Master ARCHIVE TAR的备份流程图；

图7为本发明具体采用Slave InnoDB DUMP的备份流程图；

图8为本发明具体采用Slave MyISAM DUMP的备份流程图；

图9为本发明具体采用Slave MyISAM TAR的备份流程图；

图10为本发明具体采用STRUCTURE DUMP的备份流程图；

图11为本发明的数据库全量自动备份系统的结构模块图。

具体实施方式

如图1所示，为本发明的数据库全量自动备份系统的一种优选的网络架构模块图。本发明的数据库备份系统包括同城数据库11，异城数据库12，异城数据库13，离线磁带机20，财务/银行保管系统30，本地机房41(本地电信机房)，本地机房42(本地网通机房)。其中，同城数据库11与本地备份机房41和本地备份机房42相互网络连接，将数据库上的备份数据传输至本地备份机房，即完成本地备份流程。本地备份可以定制备份周期间隔，例如设定每隔半小时、1小时或2小时等进行增量备份，每天或者每隔一天进行全量备份，将备份数据储存在本地机房上。所述备份采用交叉备份策略，即例如，第一次数据备份在本地备份机房41上，则第二次数据备份在另一个本地备份机房42上，第三次再备份至本地备份机房41上，如此循环交叉，以最大限度地利用备份机房的存储能力。

由于本地服务器的数据交换频繁，其需存储的数据量随着时间推移会不断增长，因此需要采取上述的本地备份流程，将同城本地数据库机房11上的备份数据传输至一个同城的本地备份机房41或42，优选的该数据库机房11与本地备份机房41、42架设在不同的地方，即所谓的“同城异地”，主要是为了便于放置数据库机房与本地备份机房不受同样的外在条件影响，如：网络故障、供电故障、通讯电缆损坏等各种天灾人祸，从而提高了备份机房的容灾强度，不会因为本地数据库机房的故障而导致所有备份机房的数据受到损害而失去了备份的价值。

此外，在异城异地的数据库机房之间，也需要进行异地备份，例如：将同城数据库机房11的备份数据，设定一定周期，传输至异城异地数据库机房12。同样，异城异地数据库机房12也能够在其所在的城市实现本地备份，传输备份数据值数据库机房12所在城市的本地备份机房(图中未示出)，其结构运行模式与同城数据库机房11和本地服务器41，42之间相类似。所述的备份周期，应大于本地全量备份的周期，如每周1次或2次实施异地备份。同时，异城异地数据库机房12也可设置按照一定周期向另一个异城异地数据库机房13进行备份数据传输，从而动态地形成了数据异地备份。同理，已成异地数据库机房13也可将其备份数据再传送至同城异地数据库机房11，构成一个循环。

同时，各个数据库机房11，12，13，按照一定的周期，将其备份数据集中传输给离线磁带机20进行离线备份。该周期需大于异地备份周期，可设定为每2周或每隔1个月进行一次离线备份。离线备份后的数据存储于离线磁带上，所述离线磁带可托付财务/银行保管系统存放。

在上述的架构中，各数据库机房的数量并不限定于三个，可根据实际情况架设在多个城市的数据库机房之间，如五个或者更多。且本地服务器在图1中仅根据现有的两种主要的网络供应商分为本地电信机房41和本地网通机房42，但在实际应用中还可以针对每个供应商提供更多的本地机房，并且在提供网络资源共享的企业级的数据库中，每个机房所提供的主机的数量较多，常常达到几十台甚至上百台，并且根据实际情况与各种网络供应商均设置有特定的服务器以供其使用。

如图2所示，为本发明的数据库备份系统所采用的备份步骤的详细流程图，包括如下各个步骤：

步骤100，备份流程开始。

步骤101，初始参数设定，包括MySQL备份参数及Oracle备份参数。

步骤102，备份控制文件生成备份进程。

步骤103，生成备份控制文件共有参数。

步骤104，查询备份控制文件的共有参数是否存在。如不存在，即共有参数生成失败，则进入步骤160，备份流程结束；如存在，则进入下一步骤105。

步骤105，查询MySQL及Oracle备份命令是否存在。若不存在，即所述参数初始化失败或有其他故障，则进入步骤160；若存在，则执行备份命令，并进入下一步骤106。

步骤106，去除备份文件中的空格。

步骤107，读取一行控制文件记录。

步骤108，生成备份参数。

步骤109，获取远程主机名。如未能成功获取，则进入步骤160；获取成功后进入步骤110。

步骤110，获取该远程主机机器的当前ROLE(任务)。

步骤120，执行ROLE(任务)。随后分别进入MySQL进程和Oracle进程。

步骤121，MySQL进程第一步，获取MySQL备份参数。

步骤122，导入MySQL备份脚本。

步骤123，执行MySQL备份脚本。

步骤131，Oracle进程第一步，获取Oracle备份参数。

步骤132，导入Oracle备份脚本。

步骤133，执行Oracle备份脚本。

步骤140，当MySQL和Oracle进程都完成后，读取下一行配置信息。

步骤150，判断是否为最后一行。如为最后一行，则进入步骤160；如不是最后一行，则回到步骤107并继续执行后续操作。

步骤160，备份流程结束。

如图3所示，为本发明的数据库备份系统的MySQL备份流程图，其具体包括如下步骤：

步骤200，MySQL备份流程开始。

步骤201，初始参数设定。

步骤202，遍历服务器上的实例。

步骤203，根据SOCK(端口)到监控机取得备份信息，可包括相应的第一备份地址和第二备份地址。

步骤204，判断第二备份地址是否设定。假如已设定，则进入步骤205；否则，进入步骤208。

步骤205，由于第二备份地址已设定，对比上次备份地址与第一备份地址是否一致。如不一致，则进入步骤206；如一致，则进入步骤207。

步骤206，经判断上次备份地址与第一备份地址不一致，则将此次备份地址仍设为第一备份地址，然后进入步骤209。

步骤207，经判断上次备份地址与第一备份地址一致，则将此次备份地址设为第二备份地址，然后进入步骤209。

步骤208，经判断第二备份地址未设定，则将备份地址设为第一备份地址。

步骤209，生成此次备份信息。

步骤210，备份目录是否存在。若备份目录不存在，则进入步骤211；若备份目录存在，则进入步骤213。

步骤211，创建备份目录。若备份目录创建失败，进入步骤212；否则，进入步骤213。

步骤212，备份目录创建失败，输出错误信息，停止此次备份，进入步骤240。

步骤213，判断执行MySQL备份管理命令，如：MySQL，MySQLadmin以及MySQLdump等工具。如无法执行则进入步骤214；否则，进入步骤215。

步骤214，由于判断MySQL备份管理命令无法执行，输出错误信息停止此次备份，并进入步骤240。

步骤215，当MySQL管理命令执行后，选择备份方式、备份数据库、目的地址、放置目录等信息，可由备份管理系统直接指定默认信息或者通过外部输入信息确定。

步骤216，判断是否备份所有数据库。根据实际输入情况，判断进入何种备份模式，当输入--databases命令时，进入步骤217；当输入-A命令时，进入步骤218。

步骤217，根据选定的数据库，进行各个数据库的数据备份。随后进入步骤220。

步骤218，对所有数据库进行备份，之后进入步骤220。

步骤220，选择具体备份方式。同时列出各分支供选择，包括步骤221-226供6中具体备份方式可平等选择。

步骤221，S_INNODB_DUMP模式，为采用INNODB工具及MySQL SlaveInnoDB DUMP策略的备份流程。完成备份后进入步骤230。

步骤222，M_INNODB_DUMP模式，为采用INNODB工具及MySQL MasterInnoDB DUMP策略，完成备份后进入步骤230。

步骤223，T_STRUCTURE_DUMP模式，为采用MySQL STRUCTUREDUMP策略的备份流程。完成备份后进入步骤230。

步骤224，S_MYISAM_TAR模式，为采用MYISAM工具及MySQL SlaveMyISAM TAR策略的备份流程。完成备份后进入步骤230。

步骤225，S_MYISAM_DUMP模式，为采用MYISAM工具及MySQL SlaveMyISAM DUMP策略的备份流程。完成备份后进入步骤230。

步骤226，M_ARCHIVE_TAR模式，为采用MySQL Master ARCHIVE TAR策略的备份流程。完成备份后进入步骤230。

步骤230，判断是否存在未遍历的SOCK，若存在，则返回步骤203继续操作；若不存在，则进入步骤240。

步骤240，流程结束。

如图4所示，为本发明的数据库备份系统的Oracle备份流程图，具体包括如下步骤。

步骤300，Oracle备份流程开始。对应于Oracle备份命令。

步骤301，获取环境变量。

步骤302，判断第二备份地址是否存在。若存在，则进入步骤303；若不存在，进入步骤307。

步骤303，当判断第二备份地址存在，则将上次备份地址与第一备份地址进行比较。当上次备份地址等于第一备份地址时，进入步骤304；当上次备份地址不等于第一备份地址时，进入步骤305。

步骤304，由于上次备份地址与第一备份地址相等且第二备份地址存在，根据交叉备份的原则，将备份存至第二备份地址。随后进入步骤306。

步骤305，由于上次备份地址与第一次备份地址不同，则将备份存入第一备份地址。随后进入步骤306。

步骤306，将此次备份地址存为“上次备份地址”，供后续循环比较之用。进入步骤307。

步骤307，当第二备份地址不存在或者已根据第二备份地址完成备份之后，即执行获取变量步骤。

步骤308，判断远程备份目录是否存在。若不存在，则进入步骤309；若存在，则进入步骤312。

步骤309，由于远程备份目录不存在，则创建所述远程备份目录。进入步骤310。

步骤310，判断目录创建是否正常。若异常，则进入步骤311；若正常，则进入步骤312。

步骤311，当判断目录创建异常，则输出错误信息，并进入步骤330。

步骤312，输入参数，包括备份方式、备份数据库、目的地址，放置目录等，并检查参数有效性。若输入参数无效，则进入步骤313。若输入参数有效，则进入步骤314。

步骤313，由于输入参数检查无效，故输出错误信息后，进入步骤330。

步骤314，输入参数有效，则根据输入参数开始进行备份，生成备份文件。

步骤315，传输所述的备份文件。

步骤316，传输情况判断。若传输情况发生异常，则进入步骤317；若传输情况正常，则继续进入步骤318。

步骤317，当判断传输情况异常，产生错误报告信息，并输出该错误信息。随后进入步骤330。

步骤318，检查备份文件是否存在。若备份文件不存在，则进入步骤319；若备份文件存在，继续进入步骤320。

步骤319，备份文件不存在，则生成相应错误报告信息，并传输该错误信息。随后进入步骤330。

步骤320，计算备份大小。

步骤321，显示计算出的备份大小，并选择采用何种方式进行备份。若选择“自动”备份，则进入步骤322；若选择“手动”备份，则进入步骤323。

步骤322，执行自动备份操作，更新自动备份信息。进入步骤324。

步骤323，进入手动备份操作等待过程，根据相应的后续命令执行操作。更新自动备份信息。进入步骤324。

步骤324，完成备份，清楚备份文件。

步骤325，备份过程结束。

如图5所示，为本发明具体采用Master InnoDB DUMP策略的备份流程图，用于备份主设备。包括如下步骤：

步骤400，备份过程开始。即通过步骤222，M_INNODB_DUMP模式进入。

步骤401，备份数据库表结构。

步骤402，备份数据。

步骤403，执行备份过程，并判断备份过程是否异常。如异常，则进入步骤408；如正常，则进入步骤404。

步骤404，打包压缩备份文件。

步骤405，判断压缩过程是否异常。如存在异常，则进入步骤407；如正常，则进入步骤406。

步骤406，将备份文件传送至目标地址后，清除临时的备份文件，进入步骤408。

步骤407，清除压缩文件，并将错误信息返回至管理端，进入步骤408。

步骤408，备份过程结束。

如图6所示，为本发明具体采用MasterARCHIVETAR策略的备份流程图，包括如下步骤：

步骤500，备份过程开始，即通过步骤226，M_ARCHIVE_TAR模式进入。

步骤501，判断备份库的备份方案，如进行全备份则进入步骤503，如不需要进行全备份，则进入步骤502。

步骤502，通过选择得到不需要进行全备份，则根据环境变量设定备份库，获取备份库大小，随后进入步骤504。

步骤503，通过选择得到需要进行全备份，则查找(Find)所有库。随后进入步骤504。

步骤504，刷新所列的数据表(Flush tables)。

步骤505，利用TAR备份系统备份数据库。

步骤506，判断TAR备份系统过程是否异常，如异常，则进入步骤507，如正常，则进入步骤509。

步骤507，清除备份文件，进入步骤508。

步骤508，输出错误信息至管理端。进入步骤510。

步骤509，根据主IP(master_ip)命名备份，清除临时(temp)文件。

步骤510，备份过程结束。

如图7所示，为本发明具体采用Slave InnoDB DUMP策略的备份流程图，用于从设备的数据备份。其具体包括如下步骤：

步骤600，开始步骤，即通过步骤221，S_INNODB_DUMP模式进入。

步骤601，查验从设备(Slave)运行是否正常，如运行正常，则进入步骤602；如发现从服务器(Slave)运行异常，则直接进入步骤612。

步骤602，停止从设备(Slave)，获取当前从设备(Slave)信息。

步骤603，刷新数据表(Flush tables)。

步骤604，备份表结构。

步骤605，备份数据。

步骤606，开启备份，清理错误文件(.err_bak文件)。

步骤607，等待。当符合等待条件，如外部输入或指定时间之后，进入下一步骤608。

步骤608，压缩备份文件。

步骤609，判断压缩过程是否异常。如压缩过程异常，则进入步骤610；如压缩过程正常，则进入步骤611。

步骤610，删除表结构、数据备份文件。进入步骤612。

步骤611，清除临时文件，包括：已打包的打包文件，以及其他临时文件。

步骤612，备份过程结束。

如图8所示，为本发明具体采用Slave MyISAM DUMP策略的备份流程图，用于从设备的数据备份，其具体包括如下步骤：

步骤700，开始步骤，即通过步骤225，S_MYISAM_DUMP模式进入。

步骤701，判断从设备(Slave)运行状态是否异常，如异常，则进入步骤702；如正常，则进入步骤703。

步骤702，输出错误信息至管理端，并进入步骤716。

步骤703，加全局锁，锁定所有表结构。

步骤704，备份表结构。

步骤705，备份数据。

步骤706，释放全局锁，解除对表结构的锁定状态。

步骤707，查验备份情况是否异常，如异常，则进入步骤708；备份情况正常则进入步骤709。

步骤708，输出错误信息至管理端，并进入步骤716。

步骤709，取主库IP，日志地址(log_pos)以及日志文件(log_file)。

步骤710，提取生成全局锁时，从设备Slave的信息。

步骤711，利用Tar系统备份数据。

步骤712，判断TAR系统运行过程中是否异常。如异常，则进入步骤713；如正常，则进入步骤715。

步骤713，清除备份文件。

步骤714，输出错误信息至管理端。直接进入步骤716。

步骤715，计算备份文件大小，清除非TAR备份文件。

步骤716，备份过程结束。

如图9所示，为本发明具体采用Slave MyISAM TAR策略的备份流程图，运用于从设备(Slave)中。其具体包括如下步骤：

步骤800，过程开始，即通过步骤224，S_MYISAM_TAR模式进入。

步骤801，判断从设备(Slave)运行状态是否异常，如异常，则进入步骤802；如正常，则进入步骤803。

步骤802，由于从设备运行状态异常，则输出错误信息至管理端，并结束所有过程，直接进入步骤815。

步骤803，判断是否需要进行所有库的备份，即全备份。如不需要进行全备份，则进入步骤804；如需要进行全备份，则进入步骤805。

步骤804，获取非全备份所需备份的数据以及备份大小，进入步骤806。

步骤805，获取全备所需备份的的数据以及备份大小，进入步骤806。

步骤806，加全局锁，锁住所有表。

步骤807，生成当前时间点的从设备(salve)信息。

步骤808，采用TAR系统备份数据。

步骤809，释放全局锁，解开表锁定。

步骤810，判断备份过程是否异常。如有异常，则进入步骤811；如正常，则进入步骤813。

步骤811，清除备份的文件。

步骤812，输出错误信息，进入步骤815。

步骤813，获取主库IP，将生成的备份文件，重命名为含主库IP的备份文件。

步骤814，清楚临时文件(tmp_file)

步骤815，备份过程结束。

如图10所示，为本发明具体采用STRUCTURE DUMP策略的备份流程图，用于备份表结构。其具体包括如下步骤：

步骤900，开始步骤，即通过步骤223，T_STRUCTURE_DUMP模式进入。

步骤901，备份表结构。

步骤902，判断备份情况。如备份情况异常，则进入步骤903；如备份情况正常，则进入步骤904。

步骤903，输出备份情况异常的错误信息至管理端。

步骤904，判断是否为主设备(master)，如不是，则进入步骤905；如是主设备，则进入步骤906。

步骤905，获取主设备(master)的IP，进入步骤907。

步骤906，使用本机IP。

步骤907，压缩备份文件。

步骤908，检查压缩过程是否正常，如压缩过程异常，则进入步骤909；如压缩步骤征程，则进入步骤911。

步骤909，清除压缩文件，如：“.tgz文件”。

步骤910，输出错误信息至管理端。

步骤911，清除SQL文件(.sql files)。

步骤912，备份过程结束。

如上所述，附图5-10表示了如图3所示的MySQL备份配置的具体备份方式。分别采用INNODB工具及MyISAM工具。并包括了具体的表结构的备份，使数据库自动全量备份得以实现。

图11为本发明的数据库全量自动备份系统的结构模块图。包括一个单独的数据库模块1000，数据库全量自动备份系统1100，表结构存储模块1101，备份状态信息模块1102，数据临时存储模块1103，全局锁模块1104，打包压缩模块1105，管理模块1109，以及目标存储模块1200。其中，全量自动备份系统1100架设在一个数据库模块1000内，分别通过表结构存储模块1101存储全备份的表结构或非全备份的表结构；通过备份状态信息模块1102存储备份状态信息、备份大小、环境变量运算等；通过数据临时存储模块1103执行备份打包过程中临时文件的存储；全局锁模块1104用于执行全局锁和解锁功能；所述表结构存储模块1101，备份状态信息模块1102，数据临时存储模块1103，全局锁模块1104互相连接，并最终通过信号连接至打包压缩模块1105用以存储打包后以及压缩后的存储文件，并由此直接传输至目标存储模块1200。目标存储地址为一任意服务器或主机，用于存储备份资料或临时存放数据，以供转移至离线磁带等。

上述，仅为本发明的优选的实施方式，并不用于限定本发明的保护范围，根据本领域的技术常识，结合本领域现有的技术，对上述内容所做的显而易见的修改和变化，其也应当落入本发明的保护范围。

Claims (10)

1.一种数据库全量自动备份系统，其特征在于，包括一个单独的数据库模块(1000)，数据库全量自动备份系统(1100)，表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)，打包压缩模块(1105)，管理模块(1109)，以及目标存储模块(1200)；

所述全量自动备份系统(1100)架设在所述数据库模块(1000)内，与管理模块(1109)信号连接，并由管理模块(1109)控制；其内部的表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)相互连接，且均与打包压缩模块(1105)信号连接，将各种数据或信号命令传输至打包压缩模块(1105)，并通过打包压缩模块(1105)将备份文件传输至目标存储模块(1200)。

2.如权利要求1所述的数据库全量自动备份系统，其特征在于，所述的表结构存储模块(1101)，备份状态信息模块(1102)，数据临时存储模块(1103)，全局锁模块(1104)，打包压缩模块(1105)均为可读写的数据存储设备。

3.如权利要求1所述的数据库全量自动备份系统，其特征在于，所述目标存储模块(1200)为一任意服务器或主机，用于存储备份资料或临时存放备份数据。

4.如权利要求1所述的数据库全量自动备份系统，其特征在于，还包括：同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)，离线磁带机(20)，财务/银行保管系统(30)，本地电信机房(41)，本地网通机房(42)；

所述的本地电信机房(41)以及本地网通机房(42)与同城数据库(11)连接，备份本地数据；

所述的同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)依次连接，互相备份异地数据；

所述的同城数据库(11)，第一异城数据库(12)，第二异城数据库(13)均与离线磁带机(20)连接，定期备份离线数据；

所述数据库全量自动备份系统(1100)设置在任意一台进行备份的数据库或机房中，所述的目标存储模块(1200)为任意一台接受传输数据的设备。

5.如权利要求1所述的数据库全量自动备份系统，其特征在于，所述离线数据存储于离线磁带机(20)的离线磁带中，所述离线磁带存放于所述财务/银行保管系统中。

6.如权利要求1所述的数据库全量自动备份系统，其特征在于，所述的本地电信机房(41)与本地网通机房(42)均与同城数据库(11)分别设立在不同地点。

7.如权利要求1所述的数据库全量自动备份系统，其特征在于，所述的同城数据库(11)通过网络将备份数据传输至第一异城数据库(12)；第一异城数据库(12)通过网络将备份数据传输至第一异城数据库(13)；第二异城数据库(13)通过网络将备份数据传输至同城数据库(11)，形成循环异地数据备份体系。

8.如权利要求4所述的数据库全量自动备份系统的备份方法，其特征在于，具体包括如下步骤：

步骤200，MySQL备份流程开始；

步骤201，设定初始参数；

步骤202，遍历服务器上的实例；

步骤203，根据端口到监控机取得备份信息，可包括相应的第一备份地址和第二备份地址；

步骤204，判断第二备份地址是否设定；如已设定，则进入步骤205；否则，进入步骤208；

步骤205，由于第二备份地址已设定，对比上次备份地址与第一备份地址是否一致；如不一致，则进入步骤206；如一致，则进入步骤207；

步骤206，将此次备份地址仍设为第一备份地址，然后进入步骤209；

步骤207，将此次备份地址设为第二备份地址，然后进入步骤209；

步骤208，经判断第二备份地址未设定，则将备份地址设为第一备份地址；

步骤209，生成此次备份信息；

步骤210，判断备份目录是否存在；若备份目录不存在，则进入步骤211；若备份目录存在，则进入步骤213；

步骤211，创建备份目录；若备份目录创建失败，进入步骤212；否则，进入步骤213；

步骤212，备份目录创建失败，输出错误信息，停止此次备份，进入步骤240；

步骤213，判断执行MySQL备份管理命令，如无法执行则进入步骤214；否则，进入步骤215；

步骤214，输出错误信息，并进入步骤240。

步骤215，选择备份方式、备份数据库、目的地址、放置目录信息，由备份管理系统直接指定默认信息或者通过外部输入信息确定；

步骤216，判断是否备份所有数据库；根据实际输入情况，判进入步骤217或进入步骤218。

步骤217，根据选定的数据库，进行各个数据库的数据备份；

步骤218，对所有数据库进行备份；

步骤220，进入步骤221-226选择备份方式；

步骤221，MySQL Slave InnoDB DUMP策略的备份流程；

步骤222，MySQL Master InnoDB DUMP策略的备份流程；

步骤223，MySQL STRUCTURE DUMP策略的备份流程；

步骤224，MySQL Slave MyISAM TAR策略的备份流程；

步骤225，MySQL Slave MyISAM DUMP策略的备份流程；

步骤226，MySQL MasterARCHIVE TAR策略的备份流程；

步骤230，判断是否存在未遍历的SOCK，若存在，则返回步骤203继续操作；若不存在，则进入步骤240；

步骤240，流程结束。

9.如权利要求4所述的数据库全量自动备份系统的备份方法，其特征在于，还包括如下步骤：

步骤400，开始；

步骤401，备份数据库表结构；

步骤402，备份数据；

步骤403，执行备份过程，并判断备份过程是否异常；如异常，则进入步骤408；如正常，则进入步骤404；

步骤404，打包压缩备份文件；

步骤405，判断压缩过程是否异常；如存在异常，则进入步骤407；如正常，则进入步骤406；

步骤406，将备份文件传送至目标地址后，清除临时的备份文件；

步骤407，清除压缩文件，并将错误信息返回至管理端；

步骤408，备份过程结束。

10.如权利要求4所述的数据库全量自动备份系统的备份方法，其特征在于，还包括如下步骤：

步骤900，开始；

步骤901，备份表结构；

步骤902，判断备份情况；如备份情况异常，则进入步骤903；如备份情况正常，则进入步骤904；

步骤903，输出备份情况异常的错误信息至管理模块；

步骤904，判断是否为主设备，如不是，则进入步骤905；如是主设备，则进入步骤906；

步骤905，获取主设备的IP，进入步骤907；

步骤906，使用本机IP；

步骤907，压缩备份文件；

步骤908，检查压缩过程是否正常，如压缩过程异常，则进入步骤909；如压缩步骤征程，则进入步骤911；

步骤909，清除压缩文件；

步骤910，输出错误信息至管理模块；

步骤911，清除SQL文件；

步骤912，结束。

Images