一种数据迁移的方法以及相关装置
技术领域
本申请涉及计算机技术领域,尤其涉及一种数据迁移的方法以及相关装置。
背景技术
随着互联网网站的兴起,传统的关系数据库在应付超大规模和高并发的社会性网络服务(social networking serivces,SNS)类型的web 2.0纯动态网站存在很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展,非关系数据库可以解决大规模数据集合带来的挑战,但随着数据量的增加数据库节点的故障率也随之升高,如何应对故障的发生成为难题。
一般,可以停止数据库服务并选择其中的一个从库,作为数据源;然后通过拷贝数据库源文件到新增节点;在拷贝完成后,将源节点与新增节点都启动;进而重新加入集群,源节点和新增节点都继续主从同步过程,以实现数据的迁移。
但是,在大规模数据的读写过程中,停止数据库进行数据迁移一方面影响数据库的服务效率;另一方面停止数据库的进程可能会导致副本集中只有主节点可提供服务,此时主节点为单点,存在严重的数据丢失风险,影响数据库运行的稳定性。
发明内容
有鉴于此,本申请提供一种数据迁移的方法,可以减少数据迁移过程中对于数据库运行状态的影响,提高数据库运行的稳定性。
本申请第一方面提供一种数据迁移的方法,可以应用于包含数据库或需要进行数据读写的***或程序中,具体包括:获取需要进行数据迁移的第一从节点的文件列表,所述第一从节点部署在副本集中的主节点之下,所述文件列表包含所述第一从节点中待迁移的数据的快照;
将所述第一从节点的文件列表备份到备份***;
为待迁移的数据创建第二从节点,所述第二从节点部署于所述主节点之下;
从所述备份***中下载所述第一从节点的文件列表;
根据所述第一从节点中待迁移的数据的快照恢复出所述待迁移的数据;
将所述待迁移的数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述获取需要进行数据迁移的第一从节点的文件列表,包括:
获取所述主节点和所述第一从节点之间的第一主从延迟;
若所述第一主从延迟小于第一阈值,则获取需要进行数据迁移的第一从节点的文件列表。
可选的,在本申请一些可能的实现方式中,所述将所述第一从节点的文件列表备份到备份***,包括:
解析所述文件列表的进程日志,以获取文件状态;
若所述文件状态满足预设条件,则将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述将所述第一从节点的文件列表备份到备份***,包括:
遍历所述第一从节点的续约状态;
根据所述续约状态进行备份,以将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述为待迁移的数据创建第二从节点,包括:
为所述副本集设置全局锁,以获取所述副本集的一致性状态;
在所述一致性状态下的副本集中为待迁移的数据创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述在所述一致性状态下的副本集中为待迁移的数据创建所述第二从节点,包括:
确定所述一致性状态下的副本集的可用区;
在所述可用区中创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述方法还包括:
为所述第一从节点设置租约,所述租约用于指示所述文件列表的备份进程。
可选的,在本申请一些可能的实现方式中,所述根据所述第一从节点中待迁移的数据的快照恢复出所述待迁移的数据,包括:
遍历所述副本集的数据状态,以确定所述待迁移的数据中的增量数据;
所述将所述待迁移的数据存储到所述第二从节点,包括:
根据所述增量数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述遍历所述第一从节点的数据状态,以确定所述待迁移的数据中的增量数据,包括:
遍历所述副本集的数据状态,以确定多个时刻的增量数据;
根据所述多个时刻的增量数据进行所述主节点与所述第二从节点的数据对齐,以确定所述备份元数据中的增量数据。
可选的,在本申请一些可能的实现方式中,所述方法还包括:
获取预设时间段内从所述备份***中下载所述文件列表过程中所述副本集的资源变化情况;
根据所述资源变化情况控制从所述备份***中下载所述文件列表。
可选的,在本申请一些可能的实现方式中,其特征在于,所述将所述待迁移的数据存储到所述第二从节点,包括:
根据所述待迁移的数据对所述第二从节点进行处理,并确定所述第二从节点与所述主节点之间的第二主从延迟;
若所述第二主从延迟小于第二阈值,则更新所述第二从节点的数据。
可选的,在本申请一些可能的实现方式中,其特征在于,所述副本集应用于面向文档的分布式数据库中,所述备份***为分布式文件***,所述文件列表通过网络存储至所述备份***,所述需要进行数据迁移的第一从节点包括故障从节点或负载大于第三阈值的从节点。
本申请第二方面提供一种数据迁移的装置,包括:获取单元,用于获取需要进行数据迁移的第一从节点的文件列表,所述第一从节点部署在副本集中的主节点之下,所述文件列表包含所述第一从节点中待迁移的数据的快照;
备份单元,用于将所述第一从节点的文件列表备份到备份***;
创建单元,用于为待迁移的数据创建第二从节点,所述第二从节点部署于所述主节点之下;
下载单元,用于从所述备份***中下载所述第一从节点的文件列表;
恢复单元,用于根据所述第一从节点中待迁移的数据的快照恢复出所述待迁移的数据;
迁移单元,用于将所述待迁移的数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述获取单元,具体用于获取所述主节点和所述第一从节点之间的第一主从延迟;
所述获取单元,具体用于若所述第一主从延迟小于第一阈值,则获取需要进行数据迁移的第一从节点的文件列表。
可选的,在本申请一些可能的实现方式中,所述备份单元,具体用于解析所述文件列表的进程日志,以获取文件状态;
所述备份单元,具体用于若所述文件状态满足预设条件,则将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述备份单元,具体用于遍历所述第一从节点的续约状态;
所述备份单元,具体用于根据所述续约状态进行备份,以将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述创建单元,具体用于为所述副本集设置全局锁,以获取所述副本集的一致性状态;
所述创建单元,具体用于在所述一致性状态下的副本集中为待迁移的数据创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述创建单元,具体用于确定所述一致性状态下的副本集的可用区;
所述创建单元,具体用于在所述可用区中创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述创建单元,还用于为所述第一从节点设置租约,所述租约用于指示所述文件列表的备份进程。
可选的,在本申请一些可能的实现方式中,所述恢复单元,具体用于遍历所述副本集的数据状态,以确定所述待迁移的数据中的增量数据;
所述恢复单元,具体用于所述将所述待迁移的数据存储到所述第二从节点,包括:
所述恢复单元,具体用于根据所述增量数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述恢复单元,具体用于遍历所述副本集的数据状态,以确定多个时刻的增量数据;
所述恢复单元,具体用于根据所述多个时刻的增量数据进行所述主节点与所述第二从节点的数据对齐,以确定所述备份元数据中的增量数据。
可选的,在本申请一些可能的实现方式中,所述恢复单元,还用于获取预设时间段内从所述备份***中下载所述文件列表过程中所述副本集的资源变化情况;
所述恢复单元,具体用于根据所述资源变化情况控制从所述备份***中下载所述文件列表。
可选的,在本申请一些可能的实现方式中,其特征在于,所述迁移单元,具体用于根据所述待迁移的数据对所述第二从节点进行处理,并确定所述第二从节点与所述主节点之间的第二主从延迟;
所述迁移单元,具体用于若所述第二主从延迟小于第二阈值,则更新所述第二从节点的数据。
本申请第三方面提供一种计算机设备,包括:存储器、处理器以及总线***;所述存储器用于存储程序代码;所述处理器用于根据所述程序代码中的指令执行上述第一方面或第一方面任一项所述的数据迁移的方法。
本申请第四方面提供一种计算机可读存储介质,所述计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述第一方面或第一方面任一项所述的数据迁移的方法。
从以上技术方案可以看出,本申请实施例具有以下优点:
通过获取需要进行数据迁移的第一从节点的文件列表,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;然后将该第一从节点的文件列表备份到备份***;当迁移进程触发时为待迁移的数据创建第二从节点;并从该备份***中下载该第一从节点的文件列表;接下来根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据;进而将该待迁移的数据存储到该第二从节点。从而实现了主从节点在不停止服务下的数据迁移,由于迁移的数据经由备份***处理,不会对主节点或上层节点造成侵入,进而避免了数据丢失的风险,提高了数据库运行的稳定性。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为数据迁移***运行的***架构图;
图2为本申请实施例提供的一种数据迁移的流程架构图;
图3为本申请实施例提供的一种数据迁移的方法的流程图;
图4为本申请实施例提供的一种数据备份过程的流程图;
图5为本申请实施例提供的另一种数据备份过程的流程图;
图6为本申请实施例提供的一种加节点的流程图;
图7为本申请实施例提供的另一种数据迁移的方法的流程图;
图8为本申请实施例提供的一种数据迁移装置的结构示意图;
图9为本申请实施例提供的另一种数据迁移装置的结构示意图。
具体实施方式
本申请实施例提供了一种数据迁移的方法以及相关装置,可以应用于包含数据库或需要进行数据读写的***或程序中,通过获取需要进行数据迁移的第一从节点的文件列表,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;然后将该第一从节点的文件列表备份到备份***;当迁移进程触发时为待迁移的数据创建第二从节点;并从该备份***中下载该第一从节点的文件列表;接下来根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据;进而将该待迁移的数据存储到该第二从节点。从而实现了主从节点在不停止服务下的数据迁移,由于迁移的数据经由备份***处理,不会对主节点或上层节点造成侵入,进而避免了因数据库空间膨胀造成的数据丢失风险,提高了数据库运行的稳定性。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“对应于”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、***、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
首先,对本申请实施例中可能出现的一些名词进行解释。
副本集(replica set,RS):有自动故障恢复功能的主从集群,有一个主节点(Primary)和一个或多个从节点(Secondary)组成。
主从延迟:主节点与从节点之间数据传输的延迟。
全局锁:对整个数据库实例加锁,使得数据库处于只读状态。
元数据:一种数据属性的信息,用来支持如指示存储位置、历史数据、资源查找、文件纪录等功能。
MongoDB:一种面向文档的通用型分布式数据库,属于非关系数据库。
CMongo:Cloud MongoDB Service,基于MongoDB打造的高性能NoSQL数据库管理平台。
WiredTiger:一种针对大数据的嵌入式键值存储(key value,kv)引擎,目前已合并入MongoDB并作为MongoDB官方的默认存储引擎。
Checkpoint:数据库维持一致性的机制,即检查点。
Snapshot:事务开始前的对数据库内正在执行或者将要执行的事务进行的快照。
Oplog:记录数据库的写操作的日志,主要用于主从节点间同步数据。
Raft:一种用来管理日志复制的分布式一致性算法。
Hotbackup:基于checkpoint实现的文件粒度备份方式。
RocksDB:一种kv存储引擎,可作为CMongo的底层存储引擎。
应理解,本申请提供的数据迁移方法可以应用于包含数据库或需要进行数据读写的***或程序中,例如MongoDB数据库或者基于MongoDB运行的相关程序等,具体的,数据迁移***可以运行于如图1所示的***架构中,如图1所示,是数据迁移***运行的***架构图,下面以MongoDB进行说明,MongoDB的副本集中包含多个实例,实例可能为主节点,从节点等身份。数据会通过主写入,然后通过基于Raft实现的复制集协议来主动同步oplog复制到其他节点,如此来保证副本集内所有的节点数据的一致性,相互形成副本;读操作则可以选择性地分布到所有节点上,有效提升数据库查询的性能。可以理解的是,图中示出了包含了1个主节点和2个从节点,但在实际场景中,还可以是更多的主节点或更多的从节点,具体数量因实际场景而定,此处不做限定。另外,图1中示出了一个应用端引擎,但在实际场景中,也可以有多个引擎的参与,例如mongo-driver、mgo driver等;特别是在多数据控制交互的场景中,具体引擎数量因实际场景而定。
可以理解的是,上述数据迁移***可以运行于服务器,例如:作为云端数据存储的应用,也可以运行于终端设备,还可以作为运行于第三方设备以提供数据迁移,以得到数据迁移后的节点分布结果;具体的数据迁移***可以是以一种程序的形式在上述设备中运行,也可以作为上述设备中的***部件进行运行,还可以作为云端服务程序的一种,具体运作模式因实际场景而定,此处不做限定。
本申请实施例可以是云技术(Cloud technology)的一种应用,云技术是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来,实现数据的计算、储存、处理和共享的一种托管技术。
具体的,云技术基于云计算商业模式应用的网络技术、信息技术、整合技术、管理平台技术、应用技术等的总称,可以组成资源池,按需所用,灵活便利。云计算技术将变成重要支撑。技术网络***的后台服务需要大量的计算、存储资源,如视频网站、图片类网站和更多的门户网站。伴随着互联网行业的高度发展和应用,将来每个物品都有可能存在自己的识别标志,都需要传输到后台***进行逻辑处理,不同程度级别的数据将会分开处理,各类行业数据皆需要强大的***后盾支撑,只能通过云计算来实现。
而在云技术中,需要数据库的参与。数据库,简而言之可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、查询、更新、删除等操作。
所谓“数据库”是以一定方式储存在一起、能与多个用户共享、具有尽可能小的冗余度、与应用程序彼此独立的数据集合。
数据库管理***(英语:Database Management System,简称DBMS)是为管理数据库而设计的电脑软件***,一般具有存储、截取、安全保障、备份等基础功能。数据库管理***可以依据它所支持的数据库模型来作分类,例如关系式、XML;或依据所支持的计算机类型来作分类,例如服务器群集、移动电话;或依据所用查询语言来作分类,例如SQL、XQuery;或依据性能冲量重点来作分类,例如最大规模、最高运行速度;亦或其他的分类方式。不论使用哪种分类方式,一些DBMS能够跨类别,例如,同时支持多种查询语言。
而随着互联网网站的兴起,传统的关系数据库在应付超大规模和高并发的社会性网络服务(social networking serivces,SNS)类型的web 2.0纯动态网站存在很多难以克服的问题,而非关系型的数据库则由于其本身的特点得到了非常迅速的发展,非关系数据库可以解决大规模数据集合带来的挑战,但随着数据量的增加数据库节点的故障率也随之升高,如何应对故障的发生成为难题。
一般,可以停止数据库服务并选择其中的一个从库,作为数据源;然后通过拷贝数据库源文件到新增节点;在拷贝完成后,将源节点与新增节点都启动;进而重新加入集群,源节点和新增节点都继续主从同步过程,以实现数据的迁移。
但是,在大规模数据的读写过程中,停止数据库进行数据迁移一方面影响数据库的服务效率;另一方面停止数据库的进程可能会导致副本集中只有主节点可提供服务,此时主节点为单点,存在严重的数据丢失风险,影响数据库运行的稳定性。
为了解决上述问题,本申请提出了一种数据迁移的方法,该方法应用于图2所示的数据迁移的流程框架中,如图2所示,为本申请实施例提供的一种数据迁移的流程架构图,其中备份流程的触发可以是基于副本集中节点状态的判断,即当从节点的负载高时需要进行数据迁移,或从节点发生故障时可以通过本申请提供的数据迁移方法将数据库快照生成的文件列表发送至备份***,例如:腾讯COS备份***;另外,备份过程也可以采用周期性的备份,例如:每24小时进行一次数据迁移并发送至备份***,以便于当扩容或故障需求时及时的下载备份文件,进而通过下载备份***的数据进行新节点的数据更新,即在副本集中加入新的从节点,来替换掉有问题的节点或者分担业务侧的查询请求;从而实现不停止数据库进程情况下的数据迁移。
本实施例中,节点可以是终端设备,其中,终端设备包括但不限于用户设备(UserEquipment,UE)、移动台(Mobile Station,MS)、移动终端(Mobile Terminal)、移动电话(Mobile Telephone)、手机(handset)及便携设备(portable equipment)等,该用户设备可以经无线接入网(Radio Access Network,RAN)与一个或多个核心网进行通信,例如,用户设备可以是移动电话(或称为“蜂窝”电话)、具有无线通信功能的计算机等,用户设备还可以是便携式、袖珍式、手持式、计算机内置的或者车载的移动装置。另外,节点也可以是服务器或其他具有数据交互能力的设备。
应当注意的是,图中示出了两种备份***,具体场景中还可以是更多或单一的备份***,具体的种类因实际场景而定,此处不做限定。另外,本申请中所指示的备份***可以是为数据迁移功能实现专门设置的备份***,也可以是第三方的备份***,例如腾讯云。
可以理解的是,本申请所提供的方法可以为一种程序的写入,以作为硬件***中的一种处理逻辑,也可以作为一种数据迁移装置,采用集成或外接的方式实现上述处理逻辑。作为一种实现方式,该数据迁移装置通过获取需要进行数据迁移的第一从节点的文件列表,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;然后将该第一从节点的文件列表备份到备份***;当迁移进程触发时为待迁移的数据创建第二从节点;并从该备份***中下载该第一从节点的文件列表;接下来根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据;进而将该待迁移的数据存储到该第二从节点。从而实现了主从节点在不停止服务下的数据迁移,由于迁移的数据经由备份***处理,不会对主节点或上层节点造成侵入,进而避免了因数据库空间膨胀造成的数据丢失风险,提高了数据库运行的稳定性。
结合上述流程架构,下面将对本申请中数据迁移的方法进行介绍,请参阅图3,图3为本申请实施例提供的一种数据迁移的方法的流程图,本申请实施例至少包括以下步骤:
301、获取需要进行数据迁移的第一从节点的文件列表。
本实施例中,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;其中快照包含了从节点与主节点的对应关系。
可以理解的是,需要进行数据迁移的第一从节点可以是标记为故障高发点的从节点;也可以是在预设时间段内数据库负载较高的情况下进行的从节点选择;还可以是作为预备的备份过程,以提高数据库的可恢复性。具体的选择过程可以是按照上述逻辑确定的一个或多个从节点,也可以是数据库中所有节点的备份过程。
应当注意的是,主节点与从节点为相对的称谓,在一些多层架构的数据库中,主节点也可能收到控制节点的控制,此时,主节点相当于上述从节点,并可以进行本实施例提供的数据迁移方法。
在一种可能的场景中,对于第一从节点的备份过程可以保持在主从延迟较小的情况下进行,例如主从延迟小于60毫秒;具体的,首先获取该主节点和该第一从节点之间的第一主从延迟;当该第一主从延迟小于第一阈值,则获取需要进行数据迁移的第一从节点的文件列表。
应当注意的是,本实施例中主节点与从节点所属的该副本集可以应用于面向文档的分布式数据库中,对应的备份***为分布式文件***,该文件列表通过网络存储至该备份***,该需要进行数据迁移的第一从节点包括故障从节点或负载大于第三阈值的从节点。上述说明仅为实施例示例说明,具体的数据库因实际场景而定,此处不做限定。
302、将该第一从节点的文件列表备份到备份***。
本实施例中,第一从节点的文件列表的备份过程可以是基于数据库引擎层提供的checkpoint机制保证数据一致性。
应当注意的是,不同引擎对于checkpoint有着不同的实现;例如:对于WireTiger引擎而言,checkpoint其实就是定期刷盘后,将快照持久化到文件,作为一个恢复点,以便数据库重启或者恢复时,可以回到当时的状态;另外,对于rocksDB而言,checkpoint也使得能够在指定目录中生成给定数据库的一致性快照。具体的备份方式因实际引擎的类型而定,此处不做限定。
可选的,为保证备份过程的有效性,在备份时还可以进行从节点进程的判断,即保证文件列表的有效性。具体的,首先解析该文件列表的进程日志,以获取文件状态;当该文件状态满足预设条件,则将该第一从节点的文件列表备份到备份***。其中,预设条件可以是文件列表中的文件是否失效或获取超时。
另外,由于文件列表中指示了多个文件,在备份过程中,需对其逐一遍历是否遍历完成,以保证备份的完整性。具体的,可以遍历该第一从节点的续约状态;然后根据该续约状态进行备份,以将该第一从节点的文件列表备份到备份***。其中,文件遍历的完成伴随着续约状态的失效,即当文件续约状态失效时,可以结束备份流程。
在一种可能的场景中,上述备份过程可以基于图4所示的流程进行,如图4所示,是本申请实施例提供的一种数据备份过程的流程图;图中示出了当备份流程开始时,可以进行如下步骤:
401、根据主从同步情况选择一个备份节点,其中备份几点即为步骤301中指示的一种从节点。
402、判断上述从节点与对应的主节点之间的主从延迟,若主从延迟小于第一阈值,例如:60毫秒,则进行步骤403;若否则结束备份流程。
403、开始备份,得到文件列表。具体的,可以通过客户端发送hotbackup命令的begin阶段信号给从节点,在引擎层生成物理拷贝文件,并返回文件列表。
404、判断备份状态失败或超时,若备份失败或超时,则结束流程;若否则进行步骤405。
405、继续备份,并对文件列表中的文件续约;具体的,可以通过发送hotbackup命令的continue阶段信号不停向该节点续约,保证hotbackupcheckpoint的有效性。
406、判断续约状态;由于续约状态可以反映文件列表的遍历情况,则当续约失败时,结束备份流程;另外,若续约未失败,则进行步骤408。
407、结束备份流程,具体的,可以向备份节点发送hotbackup命令的end阶段信号,停止hotbackup。
408、判断文件列表遍历完成;将文件列表中的文件进行逐一遍历并上传至备份***。
409、上传文件列表到备份***。
上述流程介绍了文件列表的备份流程,可以理解的是,在此期间从节点处于被占用的状态,为保证从节点的后续运行,可以采用如图5所示的文件列表的备份流程,即备份节点接收到hotbackup命令后与引擎层交互过程。如图5所示,为本申请实施例提供的另一种数据备份过程的流程图,图中包括如下流程:
501、开始备份。
502、判断是否有正在进行的流程;为保证备份过程的准确性,备份节点可以在无其他流程的情况下进行;若存在其他流程,则结束备份流程。
503、获取文件列表,即对内存文件刷盘,以得到持久化文件。
504、设置租约,并进行标识。由于备份过程可以是一段时间内的,可以为备份节点设置租约,以指示备份节点备份的时效性。
505、返回结果。
506、启动后台线程,即在备份过程中进行的标识判别过程。
507、判断租约是否失效;若租约时效则结束备份;若否,则继续对文件列表进行备份。
508、结束备份。
通过上述备份节点(从节点)的备份流程,使得数据库文件在不停服的情况下可以持续的写入文件列表,并基于checkpoint机制实现了一致性数据库文件的备份。
303、为待迁移的数据创建第二从节点。
本实施例中,该第二从节点部署于该主节点之下。其中,第二从节点可以是与第一从节点属于同一物理结构下的储存单元;也可以是云端的另一个与主节点设备关联的储存设备。
可选的,为了保证第二从节点中数据的一致性,在创建第二从节点之前,可以为主节点所属的副本集设置全局锁,以获取该副本集的一致性状态;然后在该一致性状态下的副本集中为待迁移的数据创建该第二从节点。由于全局锁会阻塞数据更新语句(增删改)、数据定义语句(建表、修改表结构等)和更新类事务的提交语句,从而实现了数据读写的对应性。
另外,当第二从节点与第一从节点不存在物理结构上的关联时,还应对第二从节点所属的副本集状态进行确认。具体的,首先确定该一致性状态下的副本集的可用区;然后在该可用区中创建该第二从节点。
304、从该备份***中下载该第一从节点的文件列表。
本实施例中,下载的文件列表可以是完整的备份元数据,也可以是用于恢复备份元数据的索引信息,即副本集根据该索引信息可以得到完整的备份元数据。
305、根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据。
本实施例中,待迁移数据的恢复过程可以是基于快照进行的,其中,恢复的数据可以是全量数据,即第一从节点所有数据的转移;也可以是增量数据,即部分数据的迁移。
可选的,对于基于增量数据进行文件恢复的过程可以通过遍历该副本集的数据状态,以确定该待迁移的数据中的增量数据;然后根据该增量数据存储到该第二从节点。其中,为保证增量数据的准确性,增量数据的确定过程还可以包括主从节点的对齐操作,具体的,可以遍历该副本集的数据状态,以确定多个时刻的增量数据;然后根据该多个时刻的增量数据进行该主节点与该第二从节点的数据对齐,以确定该备份元数据中的增量数据。
对于上述数据恢复的过程,由于涉及数据的写入,故可以对副本集进行监控以保证数据写入的正常进行。具体的,可以通过利用CMongo已有的整机资源控制模块,进一步将对副本集的资源变化情况进行动态监控,以控制数据恢复的速度。
306、将该待迁移的数据存储到该第二从节点。
本实施例中,由于数据更新的过程涉及主节点与从节点之间的配合;可以根据该待迁移的数据对该第二从节点进行处理,并确定该第二从节点与该主节点之间的第二主从延迟;当该第二主从延迟小于第二阈值,则更新该第二从节点的数据。
可以理解的是,对于上述步骤305和步骤306的相关特征,可以结合为如图6所示的加节点流程,如图6所示,是本申请实施例提供的一种加节点的流程图,图中包括如下步骤:
601、检测备份元数据。
602、可用区中搜寻空闲机器。
603、创建第二从节点。
604、下载全量备份文件到本地。
605、利用备份文件进行数据恢复。
606、判断是否进行增量备份。具体的,增量备份的确定可以是基于数据迁移的触发条件,例如:若触发条件为从节点故障,则可能是全量数据的备份;若触发条件为从节点负载高,则可能是增量数据的备份。对于确定为增量备份的,则进行步骤607;对于确定位不是增量备份的,则进行步骤611。
607、第二从节点以单机模式启动。
608、下载多次增量备份文件到本地。考虑到主从节点数据的一致性,需要进行多次时序的对照,以确定最终的增量备份。
609、遍历主从节点同步数据,具体的,可以利用oplog的回放功能遍历主从节点同步数据,以进行增量数据恢复。
610、第二从节点还原到位处理模式,加入副本集。
611、等待主从同步延迟小于第二阈值。具体的,第二阈值可以是预先设定的,例如:60毫秒;也可以是根据历史延迟情况确定的。
612、更新副本集数据。
结合上述实施例可知,通过获取需要进行数据迁移的第一从节点的文件列表,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;然后将该第一从节点的文件列表备份到备份***;当迁移进程触发时为待迁移的数据创建第二从节点;并从该备份***中下载该第一从节点的文件列表;接下来根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据;进而将该待迁移的数据存储到该第二从节点。从而实现了主从节点在不停止服务下的数据迁移,由于迁移的数据经由备份***处理,不会对主节点或上层节点造成侵入,进而避免了由于数据库空间膨胀造成的数据丢失风险,提高了数据库运行的稳定性。
上述实施例介绍了一种数据迁移的处理过程,可以理解的是,在数据迁移过程中存在与备份***的交互以及数据迁移的触发,下面将对该场景进行介绍,请参阅图7,图7为本申请实施例提供的另一种数据迁移的方法的流程图,本申请实施例至少包括以下步骤:
701、数据库获取需要进行数据迁移的文件列表。
702、数据库向备份***发送备份数据。
本实施例中,步骤701-步骤702的相关特征与图3所述实施例的步骤301-302类型,相关描述可以进行参考,此处不做赘述。
703、备份***存储备份数据。
本实施例中,备份数据可以是完整的数据文件列表,也可以是用户获取数据文件的索引信息。
704、数据库中数据迁移被触发。
本实施例中,数据迁移被触发可以基于不同的场景而定。一方面,数据迁移可以应用于数据扩容的应用中,即从节点副本集的数据处理量满足不了需求时,例如从节点负载过高,需要对副本集进行扩容,此时选择任意的从节点即可触发数据迁移的进行。
另一方面,数据迁移可以应用于从节点的故障恢复中,即通过加入新的节点代替故障节点的功能,具体的,上述数据备份的过程可以是实时进行的,当数据库中的监控部件检测到节点故障时,立即进行故障节点的确定,并发起对应的数据迁移,即数据迁移被触发。
在一种可能的场景中,数据迁移被触发还可以是周期性的,例如:每间隔24小时进行一次预设从节点的备份过程。
705、数据库向备份***发送下载指令。
706、备份***向数据库发送备份数据。
本实施例中,步骤705和步骤706的相关特征与图3所述实施例的步骤304-305类型,相关描述可以进行参考,此处不做赘述。
707、备份***更新备份日志。
本实施例中,备份***在完成一次备份数据的发送后,可以对相关的数据变化情况进行记录,例如:时间或数据量信息;可选的,记录内容还可以包括数据的备份起止点,以便于下次备份时减少遍历备份起点的时间,提高备份效率。
708、数据库将备份数据写入新节点。
709、数据库更新数据库文件。
本实施例中,步骤708和步骤709的相关特征与图3所述实施例的步骤306类型,相关描述可以进行参考,此处不做赘述。
结合上述实施例可知,通过本申请提供的数据迁移方法可以在保证加节点效率的同时,将对主节点的影响降到最低,适用于新增节点横向扩容的数据同步以及替换故障节点时故障恢复等应用场景,尤其是业务高峰期,副本集群负载已经很高的时候。
为了更好的实施本申请实施例的上述方案,下面还提供用于实施上述方案的相关装置。请参阅图8,图8为本申请实施例提供的一种数据迁移装置的结构示意图,数据迁移装置800包括:
获取单元801,用于获取需要进行数据迁移的第一从节点的文件列表,所述第一从节点部署在副本集中的主节点之下,所述文件列表包含所述第一从节点中待迁移的数据的快照;
备份单元802,用于将所述第一从节点的文件列表备份到备份***;
创建单元803,用于为待迁移的数据创建第二从节点,所述第二从节点部署于所述主节点之下;
下载单元804,用于从所述备份***中下载所述第一从节点的文件列表;
恢复单元805,用于根据所述第一从节点中待迁移的数据的快照恢复出所述待迁移的数据;
迁移单元806,用于将所述待迁移的数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述获取单元801,具体用于获取所述主节点和所述第一从节点之间的第一主从延迟;
所述获取单元801,具体用于若所述第一主从延迟小于第一阈值,则获取需要进行数据迁移的第一从节点的文件列表。
可选的,在本申请一些可能的实现方式中,所述备份单元802,具体用于解析所述文件列表的进程日志,以获取文件状态;
所述备份单元802,具体用于若所述文件状态满足预设条件,则将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述备份单元802,具体用于遍历所述第一从节点的续约状态;
所述备份单元802,具体用于根据所述续约状态进行备份,以将所述第一从节点的文件列表备份到备份***。
可选的,在本申请一些可能的实现方式中,所述创建单元803,具体用于为所述副本集设置全局锁,以获取所述副本集的一致性状态;
所述创建单元803,具体用于在所述一致性状态下的副本集中为待迁移的数据创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述创建单元803,具体用于确定所述一致性状态下的副本集的可用区;
所述创建单元803,具体用于在所述可用区中创建所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述创建单元803,还用于为所述第一从节点设置租约,所述租约用于指示所述文件列表的备份进程。
可选的,在本申请一些可能的实现方式中,所述恢复单元805,具体用于遍历所述副本集的数据状态,以确定所述待迁移的数据中的增量数据;
所述恢复单元805,具体用于所述将所述待迁移的数据存储到所述第二从节点,包括:
所述恢复单元805,具体用于根据所述增量数据存储到所述第二从节点。
可选的,在本申请一些可能的实现方式中,所述恢复单元805,具体用于遍历所述副本集的数据状态,以确定多个时刻的增量数据;
所述恢复单元805,具体用于根据所述多个时刻的增量数据进行所述主节点与所述第二从节点的数据对齐,以确定所述备份元数据中的增量数据。
可选的,在本申请一些可能的实现方式中,所述恢复单元805,还用于获取预设时间段内从所述备份***中下载所述文件列表过程中所述副本集的资源变化情况;
所述恢复单元805,具体用于根据所述资源变化情况控制从所述备份***中下载所述文件列表。
可选的,在本申请一些可能的实现方式中,其特征在于,所述迁移单元806,具体用于根据所述待迁移的数据对所述第二从节点进行处理,并确定所述第二从节点与所述主节点之间的第二主从延迟;
所述迁移单元806,具体用于若所述第二主从延迟小于第二阈值,则更新所述第二从节点的数据。
通过获取需要进行数据迁移的第一从节点的文件列表,该第一从节点部署在副本集中的主节点之下,该文件列表包含该第一从节点中待迁移的数据的快照;然后将该第一从节点的文件列表备份到备份***;当迁移进程触发时为待迁移的数据创建第二从节点;并从该备份***中下载该第一从节点的文件列表;接下来根据该第一从节点中待迁移的数据的快照恢复出该待迁移的数据;进而将该待迁移的数据存储到该第二从节点。从而实现了主从节点在不停止服务下的数据迁移,由于迁移的数据经由备份***处理,不会对主节点或上层节点造成侵入,进而避免了因数据库空间膨胀造成的数据丢失风险,提高了数据库运行的稳定性。
本申请实施例还提供了另一种数据迁移装置,请参阅图9,图9是本申请实施例提供的另一种数据迁移装置的结构示意图,该数据迁移装置900可因配置或性能不同而产生比较大的差异,可以包括一个或一个以***处理器(central processing units,CPU)922(例如,一个或一个以上处理器)和存储器932,一个或一个以上存储应用程序942或数据944的存储介质930(例如一个或一个以上海量存储设备)。其中,存储器932和存储介质930可以是短暂存储或持久存储。存储在存储介质930的程序可以包括一个或一个以上模块(图示没标出),每个模块可以包括对数据迁移装置中的一系列指令操作。更进一步地,中央处理器922可以设置为与存储介质930通信,在数据迁移装置900上执行存储介质930中的一系列指令操作。
数据迁移装置900还可以包括一个或一个以上电源926,一个或一个以上有线或无线网络接口950,一个或一个以上输入输出接口958,和/或,一个或一个以上操作***941,例如Windows ServerTM,Mac OS XTM,UnixTM,LinuxTM,FreeBSDTM等等。
上述实施例中由数据迁移装置所执行的步骤可以基于该图9所示的数据迁移装置结构。
本申请实施例中还提供一种计算机可读存储介质,该计算机可读存储介质中存储有数据迁移指令,当其在计算机上运行时,使得计算机执行如前述图2至图7所示实施例描述的方法中数据迁移装置所执行的步骤。
本申请实施例中还提供一种包括数据迁移指令的计算机程序产品,当其在计算机上运行时,使得计算机执行如前述图2至图7所示实施例描述的方法中数据迁移装置所执行的步骤。
本申请实施例还提供了一种数据迁移***,所述数据迁移***可以包含图8所描述实施例中的数据迁移装置,或者图8所描述的数据迁移装置。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的***,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的***,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个***,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,数据迁移装置,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-onlymemory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述,以上实施例仅用以说明本申请的技术方案,而非对其限制;尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:其依然可以对前述各实施例所记载的技术方案进行修改,或者对其中部分技术特征进行等同替换;而这些修改或者替换,并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。