CN102012944B - 一种提供复制特性的分布式nosql数据库的实现方法 - Google Patents
一种提供复制特性的分布式nosql数据库的实现方法 Download PDFInfo
- Publication number
- CN102012944B CN102012944B CN2010105912369A CN201010591236A CN102012944B CN 102012944 B CN102012944 B CN 102012944B CN 2010105912369 A CN2010105912369 A CN 2010105912369A CN 201010591236 A CN201010591236 A CN 201010591236A CN 102012944 B CN102012944 B CN 102012944B
- Authority
- CN
- China
- Prior art keywords
- repdb
- data
- master
- client
- rep
- 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
Links
Images
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本发明公开了一种提供复制特性的分布式NOSQL数据库。在每台复制组的主机上运行复制***软件RepDB并与编程开发接口库Rep_client通过环回地址localhost实现进程间通信,RepDB在一个固定的端口上监听,RepDBclient使用TCP协议连接这个端口。RepDB与Rep_client之间有控制和数据两条通信链路。复制组中所有主机中RepDB的配置文件相同。主机间通过心跳报文进行信息传递,心跳信息在接收后立即处理。本机数据库有数据更新时将数据传递给组中的每个主机。在所有RepDB中选举一个协调者。用哈希树实现对各个RepDB的数据之间版本比较。本发明实现了多机间数据的复制与数据的一致性,具有较强的容错性,用于高可靠、高性能的环境中。
Description
技术领域
本发明涉及计算机应用领域,尤其涉及分布式***中多机数据的复制。
背景技术
在分布式***中,通常配有多个计算机主机,为了保证***的可靠性和提高***性能,通常要求这些主机存储内容一样的关键性的数据。这样的主机组成了一个复制组,这就要求如果组内的某个服务器上的数据库发生了更新,必须要在很快的时间内将更新传播到组内的其它服务器上;另外,当一个复制组中有服务器出现退出、关闭这样的失效行为,组内的其它服务器仍然可以继续工作,而当失效服务器重新开始工作后,数据需要进行同样的更新。这就需要一种复制***会实时自动将服务器上更新、删除操作复制到***中的其它服务器上,这样当一个服务器退出后,不会影响到整个复制组提供的服务的方法。
发明内容
本发明的目的旨在解决一个复制组中数据复制的问题。
本发明的基本思路是复制***应能支持2至多台主机,这些主机可以在硬件配置、操作***平台上不相同,但要求部署的进程相同(不同操作***同一进程要求功能一致)。具有较强的容错功能。因此,在每台复制组的主机上运行复制***的软件RepDB一个,该软件提供运行于不同操作***平台的版本,这些版本内核完全一致。复制***软件提供编程开发接口Rep_client库,每个需要使用复制***功能的进程使用这个库,并按照接口要求进行调用。复制组中所有主机使用相同的配置文件,配置文件中指定了复制组主机间心跳的时间间隔、版本比较时间、监听端口等信息。在RepDB中存在一个唯一的协调者master,master在担当的协调者同时,也要完成普通RepDB完成的工作。各主机RepDB的数据之间的版本的比较通过哈希树来实现,避免在进行版本比较时,当数据量很大的时候,占用大量的带宽和耗费大量的***资源。
本发明的目的是这样达到的:
一种提供复制特性的分布式NOSQL数据库,其特征在于:在每台复制组的主机上运行复制***软件RepDB。***软件RepDB提供编程开发接口库Rep_client。RepDB与编程开发接口库Rep_client进程间通信通过环回地址localhost(127.0.0.1)实现,RepDB在一个固定的端口上监听,Rep_client使用TCP协议连接这个端口。RepDB与编程开发接口库Rep_client之间的通信有两条链路,一条是控制链路,另一条是数据链路。数据链路用于数据库的更新或删除操作,控制链路用于RepDB与Rep_client之间的消息传送。RepDB只有在稳定以后才允许Rep_client与它通信,在RepDB准备好以后,给使用服务的客户端进程通过接口Rep_client发送一个REPDB_IS_READY消息,表示Rep_client可以进行更新数据的操作,当本机数据发生改变时,RepDB通知Rep_client提醒进程读取。每个RepDB客户端都可以更新数据库中的数据。
复制组中所有主机使用相同的配置文件,配置文件中指定了包括复制组主机间心跳的时间间隔、版本比较时间、监听端口的心跳信息,心跳信息使用UDP或链路层协议进行传输,每隔一段时间发送一次。主机之间通过心跳报文进行信息传递,心跳信息在接收后立即处理。心跳报文除了在每个时间间隔到达时发送心跳包之外,在本机数据库有数据时,还将数据的相关信息传递给组中的每个主机。
在所有RepDB中选举唯一一个协调者master,master在担当的协调者的同时,同样完成普通RepDB能完成的工作。
对于各个RepDB的数据之间的版本的比较通过哈希树来实现;哈希树叶子节点的个数预先确定,计算某个叶子节点的hash值由key值计算得到,方法如下:将key值的每一字节相加得到SUM,将SUM对哈希数叶子节点的个数取模,得到的一个整数Index,将该记录放入哈希树Index节点下。每个哈希树的节点中会有很多记录与之对应,这些记录我们按Key值进行排序,将排序后的Key放入内存,对内存中的数据使用MD5算法计算出数据摘要值。
数据持久存储使用Berkely DB(简称BDB)创建的Key-Value数据库,在存储时,Value使用ver_num+value的方式组成,其中ver_num为版本信息,value为数据的实质部分;在***启动时,将BDB中的除实质数据外的Key和ver_num全部载入到RepDB进程的内存中,在更新数据的时候既要修改BDB中的数据,也要修改内存中的数据。
数据库中的数据同步的方法是:
(1).若master中没有数据,根据master的选举规则,则***中的所有RepDB都没有数据,若新加入节点有数据,将新加入节点的数据全部复制到当前***中。
(2).若master中有数据,则将master的叶子节点的hash值与发起同步节点的叶子节点的hash值比较,若有不同,判断***中是否有在此叶子节点上与master hash值相同的RepDB,如果没有,将不同的叶子节点放入一个等待处理队列中m_mapWaitForDeal;map<int16_t,time_t>m_mapWaitForDeal;其中map的首项为hash值不同的叶子节点在merkle树中的位置,time_t为发现差异时的时间戳。当等够一定的时间后才向master发出同步请求。如果在此叶子节点上存在与master的hash值相同的RepDB,则直接向此RepDB发送同步请求,收到同步请求的RepDB将自己对应的叶子节点的hash取出来和此hash对应的key及版本号,发回给对方。收到回应的RepDB再把收到的版本号与本地的版本号相比较,若本地版本大,则发送刷新报文,若本地版本小,则发送刷新请求报文。
数据更新具体过程:数据的更新在每个Rep_client都可以进行。RepDB对于要更新的数据,每次都是先将更新操作连带数据一起发送给master,先由master给此更新操作分配一个版本号,然后master再按照要求更新master自己的数据。要更新数据的RepDB拿到这个版本号之后,把它作为更新数据的版本号,再将数据发送给组里的其它RepDB,最后在RepDB发送完数据之后,还要给master一个回应,表示数据已经发送完成。
在删除操作中,master为删除操作分配版本号后,master和其它接收删除命令的RepDB都将删除的记录存入数据库的删除表中。
本发明的有益效果是:
1、实现了多机间数据的复制及多机间数据的一致性,可运用于需要高可靠、高可用,高性能的环境中,具有广阔的应用前景和价值。
2、本方法能支持2至多台主机,这些主机可以在硬件配置、操作***平台上不相同,具有较强的容错功能。
3、将哈希树用于数据库版本的比较,通过传递比较hash值来快速的找到不一致的叶子节点,只对不一致的叶子节点中的key进行同步,大大节约***和网络资源。
附图说明
图1是更新某个记录的工作流程图。
图2是更新发起主机在收到某个主机的更新某个记录的工作流程图。
图3是删除某个记录的发起节点的工作流程图。
图4是版本同步工作流程图。
具体实施方式
本发明的关键在于网络通信与算法的实现。
每台复制组的主机上运行复制***的软件RepDB一个,该软件提供不同平台的版本,这些版本内核完全一致。复制***软件提供编程开发接口Rep_client库,每个需要使用复制***功能的进程使用这个库,并按照接口要求进行调用。
复制组中所有主机使用相同的配置文件,给配置文件中指定了复制组主机间心跳的时间间隔、版本比较时间、监听端口等信息。
主机之间通过心跳报文进行信息传递,由于是多机、不使用传统的RS232接口,因为主机一般只配有2个串口,心跳报文使用网络数据包的方式传送,可以使用UDP或链路层协议进行传输,每隔一段时间T1发送一次。心跳信息在处理时不同于一般的网络数据先放入消息队列以后再进行处理,而是在接收后立即处理,心跳信息报文定义如下:
其中:host_index是发送心跳信息的主机的编号,用于接收心跳信息的主机获知此心跳信息的发送者,此编号对复制组中的每个主机都是唯一的;start_time为启动时间;ready_status为主机准备就绪状态;sys_status标识整个复制***是否稳定,只有稳定的复制***才能提供服务;bIsManager标识本机是否为管理机(master);has_data标识本机的数据库中是否有数据;priority为本机的优先级,优先级高的主机在发送数据的能优先发送;stamps本地逻辑基准时间戳。
心跳报文除了在每个时间间隔到达时发送心跳包之外,在本机数据库有数据时,还需要将数据的相关信息传递给组中的每个主机。
复制***由多个RepDB组成(大于等于2个),其中存在一个唯一的协调者master。***刚启动时,所有的RepDB都不是master,master是从所有RepDB中选举出来的。master在担当master的同时,它也是一个RepDB,所以master也需要完成普通RepDB能完成的工作。RepDB需要与***提供的编程开发接口Rep_client库进行通信,这就需要某种进程间通信IPC。在本发明中,为了提高跨平台性,使用操作***提供的环回地址localhost实现这类通信。RepDB在一个固定的端口上监听,Rep_client使用TCP协议连接这个这个端口。每个RepDB客户端都可以更新数据库中的数据,而不受其它限制。为实现较大数据量的存储,对于各个RepDB的数据之间的版本比较通过哈希树来进行。
哈希树(hash tree)是指这样一个树结构:树的每一个叶结点是一条指令加上该指令的哈希值构成、每个父结点下面的所有子结点的哈希值组合到一起再进行hash运算就得到它们的父结点;这个过程一直进行下去直至得到树的根结点。在本发明中,叶子节点的个数是预先确定的;计算某个叶子节点的hash值是由key值计算得到:将key值的每一字节相加,再对叶子节点的个数取模,得到的一个整数就是用此key来计算hash值的叶子节点的索引。例如,哈希树共有100个叶子节点,对于key=“aaa”的一条记录,用此记录来计算hash值的叶子节点的索引是:index=(‘a’+‘a’+‘a’)mod 100=(61+61+61)mod 100=83。这样,每个key对应的叶子节点也就固定了,不会因为某些操作使得一个key与另一个叶子节点对应。
每个哈希树的节点中会有很多记录与之对应,每个记录的版本信息进行排序,将排序后的版本信息放入内存,对内存中的数据使用MD5算法计算出hash值。
使用哈希树的好处:在进行版本比较时,如果直接使用key进行比较,当数据量很大的时候,将占用大量的带宽,同时大量的比较操作也将耗费大量的***资源。使用哈希树,不同的key的集合,计算出来的hash值是不同的,相同的key的集合,用于计算hash值的版本号不一样,计算出来的hash值也不一样,也就是说,如果两个RepDB它们的数据完全一致的话,那么它们的哈希树的顶层值也应该完全一样,相反也成立。所以可以通过传递比较hash值来快速的找到不一致的叶子节点,最后才对不一致的叶子节点中的key进行同步。
在所有的RepDB中要选择一个唯一的RepDB作为master,master用于控制整个更新和同步过程。Master首先是一个普通的RepDB,然后再是一个master,所以master需要能够完成所有其它RepDB所能完成的工作,同时还应有格外管理功能。
协调者master的举选规则是:
1、如所有RepDB的数据库中都没有数据,则按照大IP优先的原则进行选举;
2、如只有一个RepDB的数据库有数据,则选举有数据的RepDB作为master;
3、如果有多个RepDB有数据,则在这些有数据的RepDB中按照1中的规则来进行master选举。
为了减少选举master的次数,只要正确的选出了master,而master又没有出现异常的情况下,不再进行master的选择。
为了正确的选出master,需要在RepDB之间传递一些消息,用于通知别的RepDB自己的状态,这些消息通过同样心跳来传递。
RepDB与Rep_client之间的通信是通过localhost进行的。它们之间的通信共有两条链路,一条是控制链路,另一条是数据链路。RepDB只有在稳定以后才会允许Rep_client与它通信,在RepDB准备好以后,会给它自己的Rep_client发送一个REPDB_IS_READY消息,表示Rep_client可以更新数据了。Rep_client还可以订阅某些感兴趣的数据,即当本机上的这些数据发生改变时,RepDB会通知Rep_client这个改变,同样Rep_client可以退订。所有以上的这些消息都是通过控制链路来传输的;数据链路传输的是对数据库的更新和删除操作的数据。
参见图1.本方法中的每个Rep_client都可以更新数据。RepDB对于要更新的数据,每次都是先将更新操作连带数据一起发送给master,先由master给此更新操作分配一个版本号,然后master再按照要求更新master自己的数据;要更新数据的RepDB拿到这个版本号之后,把它作为更新数据的版本号,再将数据发送给组里的其它RepDB,最后在RepDB发送完数据之后,还要给master一个回应,表示操作完成,数据已经发送完成。
具体实现细节如下:RepDB收到Rep_client的更新请求以后,先给master发一个版本请求报文,master收到此报文后,先给此更新分配一个版本号,版本号总是单调递增的,然后用此版本号先更新自己,最后再将此版本号发送给请求进程,同时master还要保存此更新的相关信息,等待RepDB回应后再删除。RepDB在收到版本请求应答后,先更新自己,再向其它所有没有更新过的RepDB发送此更新,RepDB在发送完此更新后,在给master一个回应表示发送已完成,这样做可以提高一些可靠性:当RepDB在发送更新的过程中失败以后,他就不会给master回应发送完成的消息,这样,当等待一段足够长的时间以后,master就知道发送已经失败,这时master自己再将最新值发送出去。
在图2给出的是更新发起主机在收到某个主机的更新某个记录的工作流程图。对于删除操作来说,还需要将删除的记录存入一个叫删除表的数据库表中。以便在没有完全删除(组内所有RepDB都已经删除完成),而发起删除操作的主机退出又重启的情况下,可以继续进行删除操作;其它接收删除命令的RepDB也要将删除记录存入删除表。删除表的记录的存储格式如下:
|key|ver_num |
其中ver_num为master为删除操作分配的版本号。
在所有的更新过程中,如果在更新时发现有新RepDB加入,主动发起更新的RepDB(可能是master),在更新完自己之后要更新操作保存起来,等新加入RepDB和***都稳定以后再发送这些操作。
保证数据同步时本发明的重点,数据同步的方法:
(1).若master中没有数据,根据master的选举规则,则***中的所有RepDB都没有数据,这样如果新加入节点有数据的话,将新加入节点的数据全部复制到以前的***中。
(2).如果master中有数据,则将master的叶子节点的hash值与发起同步节点的叶子节点的hash值比较,若有不同的,再判断***中是否有在此叶子节点上与master hash值相同的RepDB,如果没有,再将不同的叶子节点放入一个等待处理队列中m_mapWaitForDeal;map<int16_t,time_t>m_mapWaitForDeal;其中map的first为hash值不同的叶子节点在merkle树中的位置,time_t为发现不同时的时间戳。当等够一定的时间后才向master发出同步请求;如果在此叶子节点上存在与master的hash值相同的RepDB,则直接向此RepDB发送同步请求。同步请求的报文类型为:REPDB_VERSION_SYNCH_REQUEST,收到同步请求的RepDB将自己的对应的叶子节点的hash取出来和此hash对应的key及版本号,再发回给对方,消息类型为REPDB_VERSION_LIST_RESPONSE。收到回应的RepDB再把收到的版本号与本地的版本号相比较,若本地版本大,则发送刷新报文,若本地版本小,则发送请求刷新报文。
实施本方法需要注意的是:
1.master的选举必须要在已经收到了所有启动了的RepDB的心跳报文之后才可以进行。
2.在运行过程中,只有在整个复制***都准备好以后,才允许client进行更新操作,***准备好以后,每个RepDB都会给本地的client发送REPDB_IS_READY消息,***准备好的条件是所有RepDB都已经稳定,所有RepDB都已经知道master是哪一台主机。
3.在发送数据时,如果出现发送错误,则说明某个主机出现了失效问题,如果出错的是master,则需要重新设置该主机为失效,同时修改记录设备状态的数据结构,同时通知***其它主机重新选举master,如果是其他的非master主机,只需要修改记录设备状态的数据结构就可以了。
Claims (3)
1.一种提供复制特性的分布式NOSQL数据库的实现方法,其特征在于:在每台复制组的主机上运行复制***软件RepDB ,***软件RepDB提供编程开发接口库Rep_client,RepDB与编程开发接口库 Rep_client进程间通信通过环回地址localhost实现,RepDB在一个固定的端口上监听,Rep_client 使用TCP协议连接这个端口;RepDB与编程开发接口库 Rep_client 之间的通信有两条链路,一条是控制链路,另一条是数据链路;数据链路用于提供复制特性的分布式NOSQL数据库的更新或删除操作,控制链路用于RepDB与Rep_client之间的消息传送;RepDB只有在稳定以后才允许Rep_client与它通信,在RepDB准备好以后,给使用服务的客户端进程通过编程开发接口库Rep_client发送一个REPDB_IS_READY消息,表示Rep_client可以进行更新数据的操作,当本机数据发生改变时,RepDB通知Rep_client提醒进程读取,每个RepDB客户端都可以更新提供复制特性的分布式NOSQL数据库中的数据;
复制组中所有主机使用相同的配置文件,配置文件中指定了包括复制组主机间心跳的时间间隔、版本比较时间、监听端口的心跳信息,心跳信息使用UDP或链路层协议进行传输,每隔一段时间发送一次;主机之间通过心跳报文进行信息传递,心跳信息在接收后立即处理;心跳报文除了在每个时间间隔到达时发送心跳包之外,在本机有数据时,还将本机数据的相关信息传递给组中的每个主机;
提供复制特性的分布式NOSQL数据库中的数据同步的方法是:
(1)若master的数据库中没有数据,根据master的选举规则,则***中的所有RepDB的数据库都没有数据,若新加入节点有数据,将新加入节点的数据全部复制到当前***中;
(2)若master的数据库中有数据,则将master的叶子节点的hash值与发起同步节点的叶子节点的hash值比较,若有不同,判断***中是否有在此叶子节点上与master 的hash值相同的RepDB,如果没有,将不同的叶子节点放入一个等待处理队列m_mapWaitForDeal中;
map<int16_t,time_t> m_mapWaitForDeal;其中map的首项为hash值不同的叶子节点在merkle树中的位置,time_t为发现差异时的时间戳;当等够一定的时间后才向master发出同步请求;如果在此叶子节点上存在与master的hash值相同的RepDB,则直接向此RepDB发送同步请求,收到同步请求的RepDB将自己对应的叶子节点的hash值取出来和此hash值对应的key值及版本号,发回给对方;收到回应的RepDB再把收到的版本号与本地的版本号相比较,若本地版本号大,发送刷新报文,若本地版本号小,则发送刷新请求报文;
数据的更新在每个Rep_client都可以进行,RepDB对于要更新的数据,每次都是先将更新操作连带数据一起发送给master,先由master给此更新操作分配一个版本号,然后master再按照要求更新master自己的数据;要更新数据的RepDB拿到这个版本号之后,把它作为更新数据的版本号,再将数据发送给组里的其它RepDB,最后在RepDB发送完数据之后,还要给master一个回应,表示数据已经发送完成;
在删除操作中,master为删除操作分配版本号后,master和其它接收删除命令的RepDB都将删除的记录存入提供复制特性的分布式NOSQL数据库的删除表中;
在所有RepDB中选举唯一一个协调者master,master在担当协调者的同时,同样完成普通RepDB能完成的工作;
对于各个RepDB的数据之间的版本的比较通过哈希树来实现;哈希树叶子节点的个数预先确定,计算某个叶子节点的hash值由key值计算得到;
数据持久存储使用Berkely DB创建的Key-Value数据库,在存储时,Value使用ver_num + value的方式组成,其中ver_num为版本信息,value为数据的实质部分;在***启动时,将Berkely DB中的除实质数据外的key值和ver_num全部载入到RepDB进程的内存中,在更新数据的时候既要修改Berkely DB中的数据,也要修改内存中的数据。
2.如权利要求1所述的提供复制特性的分布式NOSQL数据库的实现方法,其特征在于:所述计算某个叶子节点的hash值由key值计算得到,方法如下: 将key值的每一字节相加得到SUM,将SUM对哈希树叶子节点的个数取模,得到的一个整数Index,将该整数Index记录放入哈希树Index节点下,每个哈希树的节点中会有很多记录与之对应,这些记录我们按key值进行排序,将排序后的key值放入内存,对内存中的数据使用MD5算法计算出数据摘要值。
3.如权利要求1所述的提供复制特性的分布式NOSQL数据库的实现方法,其特征在于:所述在所有RepDB中选举唯一一个协调者master,其选举的规则:
A)如所有RepDB的数据库中都没有数据,则按照大IP优先或者大设备号优先的原则进行选举;
B)如只有一个RepDB的数据库有数据,则选举有数据的RepDB作为master;
C)如果有多个RepDB的数据库有数据,则在这些有数据的RepDB中按照A)中的规则来进行master选举;
正确的选出了master,而master没有出现异常的情况下,不再进行master的选举;master的选举消息通过心跳在RepDB之间传递;若选举的master失效,除修改记录设备状态的数据结构外,同时通知***其它主机重新选举master。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010105912369A CN102012944B (zh) | 2010-12-16 | 2010-12-16 | 一种提供复制特性的分布式nosql数据库的实现方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2010105912369A CN102012944B (zh) | 2010-12-16 | 2010-12-16 | 一种提供复制特性的分布式nosql数据库的实现方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102012944A CN102012944A (zh) | 2011-04-13 |
CN102012944B true CN102012944B (zh) | 2012-08-22 |
Family
ID=43843117
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2010105912369A Active CN102012944B (zh) | 2010-12-16 | 2010-12-16 | 一种提供复制特性的分布式nosql数据库的实现方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102012944B (zh) |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102982130A (zh) * | 2012-11-16 | 2013-03-20 | 深圳市融创天下科技股份有限公司 | 一种nosql与rdbms的数据库同步方法和*** |
CN103209214A (zh) * | 2013-04-03 | 2013-07-17 | 蓝盾信息安全技术股份有限公司 | 一种基于NoSQL的消息中间件的实现方法 |
CN103823721B (zh) * | 2014-02-26 | 2017-12-22 | 京信通信***(广州)有限公司 | 一种进程间通信的方法及设备 |
CN104967536A (zh) * | 2015-06-29 | 2015-10-07 | 北京奇虎科技有限公司 | 实现多机房数据一致性的方法和装置 |
CN108173688A (zh) * | 2017-12-27 | 2018-06-15 | 中国电子科技集团公司第五十四研究所 | 一种基于树和版本号的组网配置内容的管理方法 |
US10944850B2 (en) * | 2018-10-29 | 2021-03-09 | Wandisco, Inc. | Methods, devices and systems for non-disruptive upgrades to a distributed coordination engine in a distributed computing environment |
CN109492038B (zh) * | 2018-11-02 | 2021-08-03 | 鲁班(北京)电子商务科技有限公司 | 一种基于微内核和异步队列的异构***间数据发布*** |
CN109710190B (zh) * | 2018-12-26 | 2022-03-08 | 百度在线网络技术(北京)有限公司 | 一种数据存储方法、装置、设备及存储介质 |
CN109684307B (zh) * | 2018-12-26 | 2021-06-22 | 百度在线网络技术(北京)有限公司 | 一种数据存储方法、装置、设备及存储介质 |
CN112918406A (zh) * | 2019-12-06 | 2021-06-08 | 中车永济电机有限公司 | 有轨电车的监控***及有轨电车*** |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101814077A (zh) * | 2009-12-04 | 2010-08-25 | 四川川大智胜软件股份有限公司 | 一种基于oci 9的数据库访问中间件 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7277913B2 (en) * | 2002-05-09 | 2007-10-02 | Sun Microsystems, Inc. | Persistent queuing for distributed file systems |
-
2010
- 2010-12-16 CN CN2010105912369A patent/CN102012944B/zh active Active
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101814077A (zh) * | 2009-12-04 | 2010-08-25 | 四川川大智胜软件股份有限公司 | 一种基于oci 9的数据库访问中间件 |
Non-Patent Citations (2)
Title |
---|
刘荣.分布式数据库***数据复制技术的研究.《Computer Knowledge And Technology 电脑知识与技术》.2009,第5卷(第7期), * |
李立功.分布式数据库的数据复制技术研究.《Computer Knowledge And Technology 电脑知识与技术》.2008,第4卷(第2期), * |
Also Published As
Publication number | Publication date |
---|---|
CN102012944A (zh) | 2011-04-13 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102012944B (zh) | 一种提供复制特性的分布式nosql数据库的实现方法 | |
US10185497B2 (en) | Cluster federation and trust in a cloud environment | |
US11893264B1 (en) | Methods and systems to interface between a multi-site distributed storage system and an external mediator to efficiently process events related to continuity | |
US9239767B2 (en) | Selective database replication | |
US9405781B2 (en) | Virtual multi-cluster clouds | |
WO2019154394A1 (zh) | 分布式数据库集群***、数据同步方法及存储介质 | |
US20090157776A1 (en) | Repartitioning live data | |
US7860827B1 (en) | Data synchronization method for an application database available on multiple wirelessly connected platforms | |
CN105607954A (zh) | 一种有状态容器在线迁移的方法和装置 | |
JP5548829B2 (ja) | 計算機システム、データ管理方法及びデータ管理プログラム | |
JP2005316993A (ja) | ネットワーク上においてコンピュータ間でオブジェクトを共有するためのシステムおよび方法 | |
CN102098342A (zh) | 一种基于事务级的数据同步方法、装置及*** | |
CN109639773A (zh) | 一种动态构建的分布式数据集群控制***及其方法 | |
CN111832069B (zh) | 基于云计算的多区块链的链上数据存储***及方法 | |
JP5416490B2 (ja) | 分散データ管理システム、データ管理装置、データ管理方法、およびプログラム | |
KR101748913B1 (ko) | 분산 저장 환경에서 게이트웨이를 선택하기 위한 클러스터 관리 방법 및 데이터 저장 시스템 | |
CN113890875B (zh) | 任务分配方法及装置 | |
KR101748912B1 (ko) | 분산 저장 환경에서 데이터 저장 시스템 및 데이터 저장 시스템이 포함하는 클러스터의 업그레이드, 확장 및 축소를 위한 클러스터 관리 방법 | |
JP7450726B2 (ja) | ハイブリッドクラウド非同期データ同期 | |
US11288148B2 (en) | Global entity distribution | |
US20240168671A1 (en) | Methods and storage nodes to decrease delay in resuming input output (i/o) operations after a non-disruptive event for a storage obect of a distributed storage system by utilizing asynchronous inflight replay of the i/o operations | |
JP2023151992A (ja) | データ収集システム、方法およびプログラム | |
JPWO2012042607A1 (ja) | 分散コンピューティングシステム | |
JP2011257282A (ja) | 時刻同期方式 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |