WO2019101095A1 - 节点宕机恢复方法、装置、电子设备及存储介质 - Google Patents
节点宕机恢复方法、装置、电子设备及存储介质 Download PDFInfo
- Publication number
- WO2019101095A1 WO2019101095A1 PCT/CN2018/116671 CN2018116671W WO2019101095A1 WO 2019101095 A1 WO2019101095 A1 WO 2019101095A1 CN 2018116671 W CN2018116671 W CN 2018116671W WO 2019101095 A1 WO2019101095 A1 WO 2019101095A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- node
- target
- master
- slave
- contractor
- Prior art date
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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
-
- 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/08—Error detection or correction by redundancy in data representation, e.g. by using checking codes
- G06F11/10—Adding special bits or symbols to the coded information, e.g. parity check, casting out 9's or 11's
-
- 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
-
- 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/1415—Saving, restoring, recovering or retrying at system level
- G06F11/1417—Boot up procedures
-
- 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
-
- 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/1464—Management of the backup or restore process for networked environments
-
- 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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/1658—Data re-synchronization of a redundant component, or initial sync of replacement, additional or spare unit
-
- 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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2046—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share persistent storage
-
- 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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
- G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
-
- 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/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2094—Redundant storage or storage space
-
- 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/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
-
- 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
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0656—Data buffering arrangements
Definitions
- the proxy server can perform real-time monitoring on whether the target primary node and the target secondary node are in a down state, and the proxy server can refer to the technology used for real-time monitoring of whether the node is down.
- the technology of the present application is not described in detail herein.
- the proxy server can determine whether the node has a heartbeat to determine whether it is down. If the node does not have a heartbeat, it indicates that it is down. If the node has a heartbeat, it indicates that it has not been down.
- the foregoing method includes:
- the proxy server can also monitor whether the time taken by the new target to copy the cached data from the node to the local destination node exceeds a preset duration; if it exceeds, an alarm message is generated for the operator to find new The reason why the target is copied from the node to cache the data in the current target primary node to the local time exceeds the preset duration.
- create a node in the newly created node builder configure the created node into the cache database cluster, and obtain the target primary node from the cache database cluster except the target primary node.
- UUID configure the UUID of the target primary node to the created node, and complete the creation of the target primary node;
- control module 140 may be configured to control, when the determination result of the determining module is yes, to control the deployed target node to open the write service of the self cache database.
- the electronic device may be provided with a communication interface for implementing communication between the electronic device and other devices.
- the target slave node is configured with a persistence mechanism for the cached data, so the persistence generated by the target slave node based on the configured persistence mechanism is obtained.
- the file can restore the cached data in the target primary node; after the target primary node and the target secondary node are down, the persistent file can be used to restore the cached data of the master-slave system, thereby restoring the master-slave system to a normal working state.
- the above-mentioned target master node is not configured with a persistence mechanism, which can effectively avoid the problem that the target master node provides data read and write service performance degradation due to the self-configuration persistence mechanism.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Databases & Information Systems (AREA)
- Computational Linguistics (AREA)
- Data Mining & Analysis (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请实施例提供了一种节点宕机恢复方法、装置、电子设备及存储介质,该方法应用于主从***中的代理服务器,主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点,如果目标主节点和目标从节点均宕机,代理服务器从目标从节点获取预存的持久化文件;其中,目标从节点中备份有目标主机点中的缓存数据,持久化文件为基于目标从节点中的缓存数据生成;基于该持久化文件,部署未宕机的目标主节点;最后部署该未宕机的目标主节点对应的目标从节点。本方案中,在目标主节点和目标从节点均宕机后,可以将主从***恢复到正常的工作状态。
Description
本申请要求于2017年11月21日提交中国专利局、申请号为201711164996.X、发明名称为“节点宕机恢复方法、装置、电子设备及存储介质”的中国专利申请的优先权,其全部内容通过引用结合在本申请中。
本申请涉及计算机技术领域,特别是涉及节点宕机恢复方法、装置、电子设备及存储介质。
数据库中的数据可以用单节点进行存储,但对于用于存储缓存数据的缓存数据库而言,如果其采用单节点进行缓存数据的存储,则当单节点发生宕机,不但缓存数据库的读写服务无法继续提供,还会导致缓存数据库中的缓存数据丢失。相关技术中,为保证缓存数据库的高可用性,可以采用主从***提供数据读写服务,例如对于redis数据库(一种开源的Key-Value数据库)。
现有针对于缓存数据库的主从***中,主节点对外提供数据读写服务,从节点可以不提供服务,主节点与各个从节点之间建立有主从复制关系,保证从节点与主节点中存储有相同的缓存数据。当从节点宕机后,重启的从节点或者重启失败后新建的从节点会将当前主节点中所缓存的数据复制到其本地;主节点发生宕机时,从节点被切换为新的主节点,然后由新的节点对外提供数据读写服务。
可以理解,上述主从***中,主节点单独宕机或者从节点单独宕机后,主从***都可以恢复到正常的工作状态;但是,当主从***中的主节点及其对应的从节点均宕机后,主节点和从节点中的缓存数据会均丢失,并导致主从***的数据读写服务不可用。
发明内容
本申请实施例的目的在于提供一种节点宕机恢复方法、装置、电子设备及存储介质,以提高主从***的可用性,保证主从***中的主节点及其对应的从节点均宕机后,主从***可以恢复到正常的工作状态。具体技术方案如下:
为达上述目的,第一方面,本申请实施例提供了一种节点宕机恢复方法,应用于主从***中的代理服务器,该主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点,上述方法包括:如果目标主节点和目标从节点均宕机,从目标从节点获取预存的持久化文件;其中,目标从节点中备份有目标主机点中的缓 存数据,持久化文件为基于目标从节点中的缓存数据生成;基于目标从节点所生成的持久化文件,部署未宕机的目标主节点;部署该未宕机的目标主节点对应的目标从节点。
第二方面,本申请实施例提供了一种节点宕机恢复装置,应用于主从***中的代理服务器,该主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点,上述装置包括:确定模块,配置为如果目标主节点和目标从节点均宕机,从目标从节点获取预存的持久化文件;其中,目标从节点中备份有目标主机点中的缓存数据,持久化文件为基于目标从节点中的缓存数据生成;第一部署模块,配置为基于目标从节点所生成的持久化文件,部署未宕机的目标主节点;第二部署模块,配置为部署该未宕机的目标主节点对应的目标从节点。
第三方面,本申请实施例提供了一种电子设备,包括处理器和存储器,其中:存储器,配置为存放计算机程序;处理器,配置为执行存储器上所存放的程序时,实现上述任一节点宕机恢复方法所述的方法步骤。
第四方面,本申请实施例提供了一种计算机可读存储介质,该计算机可读存储介质内存储有计算机程序,该计算机程序被处理器执行时实现上述任一节点宕机恢复方法所述的方法步骤。
第五方面,本申请实施例提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述任一节点宕机恢复方法所述的方法步骤。
第六方面,本申请实施例提供了一种计算机程序,当其在计算机上运行时,使得计算机执行上述任一节点宕机恢复方法所述的方法步骤。
由以上可知,本申请实施例提供的方案中,该节点宕机恢复方法应用于主从***中的代理服务器,主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点,该目标主节点为缓存数据库的主节点;该目标从节点中被配置有针对于缓存数据的持久化机制,该目标主节点中未配置有持久化机制;代理服务器在检测到目标主节点和目标从节点均宕机时,确定目标从节点基于持久化机制生成的持久化文件;基于该持久化文件,部署未宕机的目标主节点;最后部署该未宕机的目标主节点对应的目标从节点。
与现有技术相比,本申请实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达 到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请一实施例提供的一种节点宕机恢复方法的流程示意图;
图2为本申请另一实施例提供的一种节点宕机恢复方法的流程示意图;
图3为本申请实施例涉及的主从***的结构示意图;
图4为本申请又一实施例提供的一种节点宕机恢复方法的流程示意图;
图5为本申请一实施例提供的一种节点宕机恢复装置的结构示意图;
图6为本申请另一实施例提供的一种节点宕机恢复装置的结构示意图;
图7为本申请实施例提供的一种电子设备的结构示意图。
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。下面,首先对本申请文件中涉及的技术术语进行简单介绍。
持久化机制,是将数据在持久状态和瞬时状态间转换的机制。通俗的讲,就是将瞬时数据,如缓存数据,持久化为持久数据。基于持久化机制所得到的持久数据可被永久保存的存储设备中,即使存储设备宕机,只要该持久数据未被损坏,该持久数据都不会丢失。
对于缓存数据库的数据节点而言,如果数据节点中配置了持久化机制,则数据节点中的缓存数据还会被持久化为持久数据,得到持久化文件。具体的,数据节点基于持久化机制将缓存数据持久化为持久数据的具体方式是多种多样的,可以是将数据节点中针对缓存数据的写操作记录到持久化文件中。上述写操作包括数据的增加操作、删除操作以及修改操作。
例如,对于redis缓存数据节点,其上可以配置AOF(AppendOnly File)持久化机制,redis缓存数据节点的任何写操作都会被记录到持久化文件appendonly.aof中,当redis缓存数据节点宕机时,该持久化文件appendonly.aof不会丢失,重启redis缓存数据节点或者新建redis缓存数据节点时,可以基于该持久化文件appendonly.aof恢复redis缓存数据节点宕机前其中所缓存的缓存数据。
需要注意的是,缓存数据库的数据节点配置了持久化机制后,数据节点需要额外的资源来保证持久化机制的正常运行,所以数据节点提供其他服务的能力势必会受到影响,这也是现有技术中主从***中各个数据节点都不配置持久化机制的原因,尤其是redis节点等对读写性能有高要求的数据节点;例如,数据节点在写入新的缓存数据的时候,还额外需要对缓存数据进行持久化操作,必然影响数据节点的性能。
主从复制机制,是主从***中的主节点与其对应的从节点之间建立的一种机制,该机制使得主节点与其对应的从节点之间建立起主从复制关系,可以保证主节点数据更新时,从节点根据主节点的更新操作同步本地数据,保证主节点和从节点之间存储着相同的数据;另外,当新建或者重启从节点时,从节点可以将主节点中所缓存的数据复制到从节点本地。当然,主从复制机制的具体实现方式属于现有技术,本申请文件在此不做详细介绍。
例如,主节点和从节点中均缓存有数据A,在某一时刻,主节点中缓存的数据A被删除,则从节点基于主从复制机制,在感知到主节点缓存中的数据A被删除的情况下,将本地缓存的数据A删除。再如,从节点宕机后,新建一个节点来代替该宕机的从节点,然后新建的节点基于主从复制机制,将当前主节点中缓存的数据复制到本地,完成从节点的新建。
为了解决现有技术的主从***中,主节点和从节点均宕机导致的主从***不可用的问题,本申请实施例提供了节点宕机恢复方法、装置、电子设备及存储介质。
下面首先对本申请实施例所提供的一种节点宕机恢复方法进行介绍。
本申请实施例提供的一种节点宕机恢复方法,应用于主从***中的代理服务器,该主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点。
该代理服务器是可以控制主从***中的主节点和从节点的设备,所以该代理服务器亦可称为控制器。在实际应用中,该代理服务器、主节点以及从节点可以处于同一物理设备上,还可以处于不同的物理设备上,这都是合理的。
目标主节点为缓存数据库的主节点,所以目标从节点同样为缓存数据库的从节点,其备份有目标主机点中的缓存数据。另外,本申请实施例并不限定缓存数据库的数据 库类型,例如,该缓存数据库可以为redis数据库。
上述目标从节点中被配置有针对于缓存数据的持久化机制,上述目标主节点中未配置有所述持久化机制。
现有技术中,为了避免部署持久化机制对数据节点性能的影响,不会在主从***中的任何数据节点上针对缓存数据部署持久化机制。而与现有技术不同的是,本申请实施例涉及的主从***中的主节点中未配置有针对于缓存数据的持久化机制,但在从节点中配置有针对于缓存数据的持久化机制。
可以理解,在主从***中,主节点提供数据读写服务,当主节点执行写操作时,主节点不需要对缓存数据做持久化操作,所以主节点提供数据读写的服务并不受到影响,而从节点虽然在做了数据写操作后还需要做持久化操作,但是对主从***提供服务的性能并不产生影响。
如图1所示,本申请实施例提供的节点宕机恢复方法包括:
S101:如果目标主节点和目标从节点均宕机,从目标从节点获取预存的持久化文件。
代理服务器作为控制目标主节点和目标从节点的设备,其可以对目标主节点和目标从节点是否处于宕机的状态进行实时监测,代理服务器对于节点是否宕机的实时监测所采用技术可以参照现有技术,本申请实施例在此不再详细介绍。例如,代理服务器可以通过检测节点是否具有心跳来确定其是否宕机,如果节点不具有心跳,则说明其宕机,如果节点具有心跳,则说明其未宕机。
目标主节点和目标从节点均宕机,可以是目标主节点和目标从节点同时宕机;也可以是目标主节点在先宕机后,新的用以替代原目标从节点的从节点完成数据同步之前,新的目标从节点再次宕机,可以理解,此情况下,主从***的目标主节点和目标从节点均宕机;还可以是目标从节点先宕机后,新的目标从节点完成数据同步之前,目标主节点宕机,同样的,此情况下,主从***的目标主节点和目标从节点均宕机。
如前所述,目标从节点中配置有持久化机制,所以目标从节点中的缓存数据还会被持久化为持久数据,得到持久化文件,即上述预存的持久化文件,也就是说,上述持久化文件为基于目标从节点中的缓存数据生成的。例如,目标从节点为redis缓存数据节点,目标从节点上可以配置AOF持久化机制,目标从节点的任何写操作都会被记录到持久化文件appendonly.aof中。
可以理解,该持久化文件为永久存储的文件,即使目标从节点宕机,该持久化文件也不会丢失。所以在目标从节点宕机后,代理服务器还是可以在目标从节点所在的 物理机中查找到目标从节点所生成的持久化文件,即上述步骤S101中确定目标从节点基于持久化机制生成的持久化文件的步骤。
S102:基于目标从节点所生成的持久化文件,部署未宕机的目标主节点。
目标从节点所生成的持久化文件是目标从节点在发生宕机前所生成的,该持久化文件对应着目标从节点发生宕机前目标从节点中所缓存的数据,而由于目标主节点与目标从节点之间所存在的主从复制关系,目标从节点中的缓存数据与目标主节点中所存储的缓存数据相同,即可以利用该持久化文件得到目标主节点宕机前所缓存的数据。
当然,利用持久化文件得到缓存数据的方式可以参照现有技术,本申请实施例仅以下述实例进行示例性说明。示例性的,上述目标主节点以及目标从节点均为redis节点,在目标从节点中配置有AOF持久化机制,由于该AOF持久化机制的存在,目标从节点会将其内所发生的所有数据写操作记录到持久化文件中;则在利用持久化文件获得缓存数据时,可以执行持久化文件所记录的所有数据写操作,得到缓存数据。
本申请实施例中部署未宕机的目标主节点,可以是重启发生宕机的目标主节点;还可以是重新创建一个新的目标主节点。另外,重启或者新建目标主节点,除了需要利用上述持久化文件外,可能还会利用到其他信息,如数据库配置文件等,例如,当目标主节点为redis节点时,重启或新建目标主节点还需要利用redis数据库的配置文件redis.conf。
步骤S102的具体实现方式可以参照现有技术所有可行的技术,而本申请实施例也提供了一种可选的实现方式。具体的,上述主从***中的节点创建在节点承建器上,节点承建器包括LXC(Linux Container)容器或虚拟机,可以理解,主从***中的节点包括主节点和从节点。
数据节点通常是建立在虚拟设备中,本申请实施例中,将上述主从***中的节点所处的虚拟设备称为节点承建器,具体的,节点承建器可以是LXC容器,也可以是虚拟机,或者是其他的可以被用来创建数据节点的虚拟设备。
在图1所示方法实施例的基础上,如图2所示,上述基于目标从节点所生成的持久化文件,部署未宕机的目标主节点的步骤S102,可以包括:
S1021:在第一节点承建器宕机且重启第一节点承建器失败的情况下,在代理服务器所控制的物理机中新建一个节点承建器;基于目标从节点所生成的持久化文件,在所新建的节点承建器中新建目标主节点;其中,第一节点承建器为创建有上述发生宕机的目标主节点的节点承建器。
在目标主节点被创建在第一节点承建器上的情况下,目标主节点发生的宕机可能 是第一节点承建器未发生宕机,但目标主节点自身发生了宕机;还可能是该第一节点承建器发生了宕机,进而导致其上所创建的目标主节点发生宕机。
所以在检测到目标主节点和目标从节点发生宕机后,代理服务器可以检查该第一节点承建器是否发生宕机,如果第一节点承建器发生宕机,则代理服务器首先需要执行重启该第一节点承建器的操作,但是第一节点承建器并不一定可以被成功重启,如果重启该第一节点承建器失败,则代理服务器需要新建一个节点承建器,以在该新建的节点承建器上创建新的目标主节点。
如上所述,节点承建器为虚拟设备,所以节点承建器也是创建在物理机中的,在本申请实施例中,代理服务器可以在第一节点承建器所在的物理机中创建用以代替第一节点承建器的节点承建器,还可以在其所控制的任一物理机中创建用以代替第一节点承建器的节点承建器,本申请实施例在此并不做限定。
在创建了用以代替第一节点承建器的节点承建器后,代理服务器可以利用目标从节点所生成的持久化文件,在所新建的节点承建器中新建目标主节点。
可以理解,在第一节点承建器宕机且重启第一节点承建器失败的情况下,要想新建目标主节点,则需要首先新建一个节点承建器,但是并不是执行了创建节点承建器的操作后,代理服务器就一定可以成功新建节点承建器。所以本申请实施例中为了能够对新建节点承建器失败的情况进行及时把握,在上述在代理服务器所控制的物理机中新建一个节点承建器的步骤之后,上述方法还可以包括:
监测是否成功新建节点承建器;如果不成功,生成失败报警信息;如果成功,执行上述基于目标从节点所生成的持久化文件,在所新建的节点承建器中新建目标主节点的步骤。
可以理解,在新建节点承建器失败的情况下,表明目标主节点无法被新建,所以此时需要及时针对此次新建节点承建器的情况生成失败报警信息,以告知工作人员及时针对此问题做出应对措施。
S1022:在第一节点承建器未宕机或者宕机后被成功重启的情况下,基于目标从节点所生成的持久化文件,重启发生宕机的目标主节点。
如上所述,在检测到目标主节点和目标从节点发生宕机后,代理服务器可以检查该第一节点承建器是否发生宕机。一种情况下,该第一节点承建器未发生宕机,则执行步骤:基于目标从节点所生成的持久化文件,重启发生宕机的目标主节点;再一种情况下,该第一节点承建器发生宕机,代理服务器重启该第一节点承建器,并且重启成功,则代理服务器同样执行步骤:基于目标从节点所生成的持久化文件,重启发生 宕机的目标主节点。
在另一种实施方式中,在第一节点承建器未宕机或者宕机后被成功重启的情况下,代理服务器也可以新建一个节点承建器,并在所新建的节点承建器上新建目标主节点。
缓存数据库中的所有数据可以通过一个主节点及主节点对应的从节点进行缓存,还可以是利用集群来进行缓存,如常见的redis集群。集群所包含的主节点的数量至少为两个,每个主节点负责一部分的缓存数据,每个主节点都对应有一个从节点。
所以,当本申请实施例所涉及的目标主节点以及目标从节点为集群中的节点时,上述主从***可以还包括除目标主节点外该代理服务器所控制的非目标主节点、以及每个非目标主节点所对应非目标从节点。如图3所示,主从服务***中包括代理服务器、目标主节点、目标从节点、非目标主节点1~m以及非目标从节点1~m。
此情况下,本申请实施例所涉及的主从***中所有主节点与从节点构成缓存数据库集群,即,上述目标主节点、目标从节点、非目标主节点1~m以及非目标从节点1~m构成缓存数据库集群。
应该说明的是,在缓存数据库集群中,目标主节点以及目标从节点仅是对当前均宕机的一组主节点和从节点的区别称呼,即,在缓存数据库集群中,某一主节点及其对应的从节点均宕机时,则该主节点及从节点即分别为本申请实施例中所说的目标主节点及目标从节点,而缓存数据库集群中除该主节点及从节点外的所有主节点及从节点即分别为本申请实施例中所说的非目标主节点及非目标从节点。
本申请实施例中,该缓存数据库集群中的每个节点中均可以携带有节点配置文件,节点配置文件中可以包含缓存数据库集群中每个节点的通用唯一识别码UUID(Universally Unique Identifier)。
本领域技术人员公知的是,在缓存数据库集群中,所有的节点之间可以存在信息交互,所有的节点需要知晓缓存数据库集群中除自身外所存在的节点。所以,缓存数据库集群中的每个节点中均可以携带有节点配置文件,该节点配置文件中可以包含有缓存数据库集群中每个节点的IP地址(Internet Protocol Address,互联网协议地址),以及用以标识每个节点的标识信息,即上述通用唯一识别码UUID。
在缓存数据库集群中,通用唯一识别码UUID是各个节点的唯一标识,所以无论是重启发生宕机的目标主节点还是新建目标主节点,所部署的目标主节点必须是配置有发生宕机的目标主节点宕机前所配置的通用唯一识别码UUID,以使得缓存数据库集群中的其他节点能对所部署的目标主节点进行识别。
在此情况下,上述步骤S1021中关于基于目标从节点所生成的持久化文件,在所 新建的节点承建器中新建目标主节点的步骤,可以包括下述步骤a1~a3:
a1:判断发生宕机的目标主节点中的目标节点配置文件是否丢失。
目标节点配置文件即为目标主节点中所存储的节点配置文件,目标主节点发生宕机,则上述目标节点配置文件可能会随着目标主节点的宕机而丢失。对于步骤a1,示例性的,目标主节点创建在LXC容器中,目标主节点发生宕机前,其上的目录X下存储着目标节点配置文件node.conf,在目标主节点发生宕机后,代理服务器在该LXC容器中查找是否存在目标节点配置文件node.conf,如果存在,判定目标节点配置文件未丢失,如果不存在,判定目标节点配置文件未丢失。
如果步骤a1的判断结果为是,则执行步骤a2:基于目标从节点所生成的持久化文件,在所新建的节点承建器中创建一个节点;将所创建节点配置到缓存数据库集群中,并从缓存数据库集群中除目标主节点外的节点中获得目标主节点的UUID,将目标主节点的UUID配置给所创建的节点,完成目标主节点的新建。
基于目标从节点所生成的持久化文件,在所新建的节点承建器中创建一个节点,表明所创建的节点中缓存有利用持久化文件所得到的缓存数据,但是该所创建的节点当前还不是新的目标主节点。可以理解,目标主节点是缓存数据库集群中的一个节点,并且负责着一部分槽(slot),所以为了让所创建的节点成为新的主节点,代理服务器需要使得所创建节点成为缓存数据库集群中的一个节点,并负责宕机的目标主节点所负责的槽。
本申请实施例中,在所新建的节点承建器中创建一个节点后,首先将所创建的节点加入到缓存数据库集群中,使得所创建节点成为缓存数据库集群中一个节点。在缓存数据库集群中加入节点的方式属于现有技术,本领域技术人员可以基于现有技术实现在缓存数据库集群中加入所创建节点的目的。例如,该缓存数据库集群为redis集群,代理服务器可以将所创建节点的IP地址发送给缓存数据库集群的其他节点,并在这些节点中运行cluster_meet命令,使得缓存数据库集群的其他节点知晓该IP地址对应的节点为缓存数据库集群中的节点,完成所创建节点加入到缓存数据库集群的目的。
然后代理服务器可以从缓存数据库集群中除目标主节点外的节点中获得目标主节点的UUID,并将目标主节点的UUID配置给所创建的节点。如前所述,节点的UUID是节点的唯一标识信息,所创建节点被分配了目标主节点的UUID后,缓存数据库集群中的其他节点可以根据目标主节点的UUID,识别出所创建节点为目标主节点,即此时完成目标主节点的新建;相应的,缓存数据库集群中的其他节点也可以知晓所创建节点所负责的槽。
此情况下,新建的目标主节点与前述发生宕机的目标主节点的IP地址不同,所以新建目标主节点后,对于缓存数据库集群中除新建目标主节点外的每个节点,还需更新其节点配置文件中目标主节点的UUID所对应IP地址为:新建目标主节点的IP地址,并为新建的目标主节点配置此处所更新的节点配置文件。
例如,前述发生宕机的目标主节点的IP地址为IP1,新建目标主节点的IP地址为IP2,则此时对于缓存数据库集群中除新建目标主节点外的每个节点,将其节点配置文件中目标主节点的UUID所对应IP地址IP1替换为IP2,并且为新建的目标主节点配置此处所述的替换了IP地址的节点配置文件。
步骤a2的具体实现可以参照现有技术,本申请实施例在此不再详细介绍,仅以下述举例进行示例性说明。
针对步骤a2,示例性的,假设缓存数据库集群为redis集群,代理服务器首先利用数据库配置文件redis.conf以及目标从节点所生成的持久化文件appendonly.aof,在所新建的节点承建器中创建一个节点。然后将所创建节点的IP地址发送给redis集群中的其他节点,并在这些其他节点中运行cluster_meet命令,完成将所创建节点加入到缓存数据库节点的目的。最后,代理服务器从缓存数据库集群中除目标主节点外的节点中获得目标主节点的UUID,并将目标主节点的UUID配置给所创建的节点,完成目标主节点的新建。
如果步骤a1的判断结果为否,则执行步骤a3:基于目标从节点所生成的持久化文件和目标节点配置文件,在所新建的节点承建器中创建一个节点,将所创建节点配置到缓存数据库集群中,完成目标主节点的新建。
在步骤a3中,所创建的节点配置有目标主节点的UUID,同时还具有目标主节点所缓存的数据,但是所创建节点的IP地址与宕机的目标主节点的IP地址不同,所以在此还需要将所创建节点加入到缓存数据库集群,才可以完成目标主节点的新建。
同样的,与步骤a2同理的是,此情况下,新建的目标主节点与前述发生宕机的目标主节点的IP地址不同,所以新建目标主节点后,对于缓存数据库集群中除新建目标主节点外的每个节点,还需更新其节点配置文件中目标主节点的UUID所对应IP地址为:新建目标主节点的IP地址,并为新建的目标主节点配置此处所更新的节点配置文件。
步骤a3的具体实现同样可以参照现有技术,本申请实施例在此不再详细介绍,仅以下述举例进行示例性说明。
针对步骤a3,示例性的,假设缓存数据库集群为redis集群,代理服务器首先利 用数据库配置文件redis.conf、目标节点配置文件node.conf以及目标从节点所生成的持久化文件appendonly.aof,在所新建的节点承建器中创建一个节点;然后将所创建节点的IP地址发送给redis集群中的其他节点,并在这些其他节点中运行cluster_meet命令,完成将所创建节点加入到缓存数据库节点的目的,进而完成目标主节点的新建。
相应的,上述步骤S1022中关于基于目标从节点所生成的持久化文件,重启发生宕机的目标主节点的步骤,可以包括下述步骤b1~b3:
b1:判断发生宕机的目标主节点中的目标节点配置文件是否丢失。
步骤b1与上述步骤a1相同,步骤b1的具体内容和解释说明可以参照上述步骤a1,本申请实施例在此不再详细介绍。
如果步骤b1的判断结果为是,则执行步骤b2:从缓存数据库集群中除目标主节点外的节点中获得节点配置文件,基于目标从节点所生成的持久化文件以及所获得的节点配置文件,重启发生宕机的目标主节点。
可以理解,在发生宕机的目标主节点中的目标节点配置文件丢失的情况下,如果直接基于目标从节点所生成的持久化文件,重启发生宕机的目标主节点,重启得到的节点并不知道缓存数据库集群中其他节点的信息,也不知道自己所负责的槽,所以代理服务器还需要先从缓存数据库集群中除目标主节点外的节点中获得节点配置文件,以使得在重启目标主节点时,将目标主节点的UUID配置给所重启的目标主节点。
如果步骤b1的判断结果为否,则执行步骤b3:基于目标从节点所生成的持久化文件以及目标节点配置文件,重启发生宕机的目标主节点。
在此情况下,直接利用目标节点配置文件以及目标从节点所生成的持久化文件,重启发生宕机的目标主节点即可。
示例性的,假设缓存数据库集群为redis集群,则代理服务器可以直接利用数据库配置文件redis.conf、目标节点配置文件node.conf以及目标从节点所生成的持久化文件appendonly.aof,重启发生发生宕机的目标主节点。
如图1所示,S103:部署该未宕机的目标主节点对应的目标从节点。
同样的,本申请实例中,部署该未宕机的目标主节点对应的目标从节点,可以是重启发生宕机的目标从节点;还可以是重新创建一个新的目标从节点。
作为本申请实施例的一种可选的实现方式,代理服务器部署该未宕机的目标主节点对应的目标从节点,同样可以基于发生宕机的目标从节点所生成的持久化文件,部署该未宕机的目标主节点对应的目标从节点。具体的,基于发生宕机的目标从节点所生成的持久化文件,部署该未宕机的目标主节点对应的目标从节点的原理,与步骤 S102的原理相同,可以参照上述步骤S102的具体内容和相关解释执行步骤S103,本申请实施例在此不再详细介绍。
作为本申请实施例的另一种可选的实现方式,上述部署该未宕机的目标主节点对应的目标从节点的步骤S103,可以包括:
基于主从复制机制,部署该未宕机的目标主节点对应的目标从节点。
可以理解,此实现方式下所部署的目标从节点中缓存的数据是基于主从复制机制所获得的。另外,基于主从复制机制,部署该未宕机的目标主节点对应的目标从节点所对应的具体实现方式可以参照现有技术,本申请实施例在此不做详细介绍。
作为本申请实施例的一种可选实现方式,在上述主从***中的节点创建在节点承建器上的情况下,上述基于主从复制机制,部署该未宕机的目标主节点对应的目标从节点的步骤,可以包括下述步骤c1和c2:
步骤c1:在第二节点承建器宕机且重启第二节点承建器失败的情况下,在代理服务器所控制的物理机中新建一个节点承建器,并基于主从复制机制,在所新建的节点承建器中新建目标从节点。其中,该第二节点承建器为创建有上述发生宕机的目标从节点的节点承建器。
步骤c2:在第二节点承建器未宕机或者宕机后被成功重启的情况下,基于主从复制机制,重启发生宕机的目标从节点。
与前述步骤S1021和S1022不同的是,步骤c1和c2中,所部署目标从节点中的缓存数据是基于主从复制机制所获得的,而步骤S1021和S1022中所部署目标从节点中的缓存数据是基于持久化文件所获得的。除此以外,步骤c1和c2的具体实现原理可以参照前述步骤S1021和S1022,本申请实施例在此不再详细介绍。
另外,无论是在新建的节点承建器中新建目标从节点,还是重启发生宕机的目标从节点,代理服务器都可以监测所部署目标从节点复制所部署目标主节点中缓存数据到本地所消耗的时间是否超过一预设时长。在实际应用中,可以通过检查所部署目标从节点中的字段master_link_status为up还是down,如果为up,表明所部署目标从节点完成主从复制,如果为down,则表明所部署目标从节点未完成主从复制。
如果所部署目标从节点复制所部署目标主节点中缓存数据到本地所消耗的时间超过预设时长,说明所部署目标从节点复制所部署目标主节点中缓存数据所消耗的时间的较长,可能发生异常,则可以针对此生成报警信息,以使得操作人员可以查找所部署目标从节点复制所部署目标主节点中缓存数据到本地所消耗的时间超过预设时长的原因。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
可以理解,上述任一实施例中代理服务器都是在先部署目标主节点的,目标主节点被成功部署后,所部署目标主节点即可对外提供数据读写服务。但是,如果在完成目标从节点的部署之前,目标主节点执行了数据写操作并导致目标主节点中所缓存的数据发生改变,显然的,由于此时目标从节点仍然处于宕机状态,此段时间发生的数据写操作对应的缓存数据无法被记录到目标从节点中的持久化文件中。如果此后,在目标从节点的部署完成之前,刚部署的目标主节点再次发生宕机,则会因为持久化文件中未记录上述时间内的缓存数据,导致发生数据丢失问题。
例如,在redis集群中,目标主节点部署好后,在部署目标从节点的过程中,如果目标主节点中写入了数据a,此时目标从节点还未部署好,如果在完成部署目标从节点之前,所部署的目标主节点再次发生宕机,此时由于数据a仅被写在目标主节点中,则数据a将随着目标主节点的再次宕机而丢失。
本申请实施例中,为了避免上述数据丢失问题的发生,在图1或图2所示任一方法实施例的基础上,在上述部署该未宕机的目标主节点对应的目标从节点的步骤S103之前,上述方法还可以包括:
控制所部署的目标主节点关闭自身缓存数据库的写服务;
相应的,在上述部署该未宕机的目标主节点对应的目标从节点的步骤S103之后,上述方法还可以包括:
控制所部署的目标主节点开启自身缓存数据库的写服务。
即如图4所示,在本申请实施例中,上述方法包括:
S201:如果目标主节点和目标从节点均宕机,从目标从节点获取预存的持久化文件。
S202:基于目标从节点所生成的持久化文件,部署未宕机的目标主节点。
S203:控制所部署的目标主节点关闭自身缓存数据库的写服务。
代理服务器作为目标主节点的控制设备,其完全可以控制目标主节点关闭自身缓存数据库的写服务。具体的实现方式可以是多种多样的,示例性的,代理服务器向所部署的目标主节点发送一个client_pause命令,则目标主节点基于该命令不再处理目标主节点对应的客户端所发送的写请求,保证此后目标主节点不会再执行数据写操作。
S204:部署该未宕机的目标主节点对应的目标从节点。
S205:控制所部署的目标主节点开启自身缓存数据库的写服务。
在完成目标从节点的部署后,代理服务器可以向目标主节点发送一个开启目标主节点缓存数据库写服务的指令,以使得目标主节点开启缓存数据库写服务。
图4所示方法实施例中的步骤S201、步骤S202和步骤S204分别对应与图1所示方法实施例中的步骤S101、步骤S102和步骤S103相同,步骤S201、步骤S202和步骤S204的解释说明和具体实现可以参照图1所示方法实施例,本实施例在此不再赘述。
另外,可以理解,所部署目标从节点中写入的所有缓存数据持久化为持久数据是需要消耗时间的,如果在成功部署目标从节点之后,所部署目标从节点将其中写入的所有缓存数据持久化为持久数据之前,所部署的目标主节点和目标从节点再次发生宕机,此时由于主从***中不再存在所有缓存数据对应的完整的持久化文件,所以代理服务器无法复原所有缓存数据,导致发生数据丢失的问题。本申请实施例中,为了避免此问题,在上述图4所示方法实施例的基础上,在上述控制所部署的目标主节点开启自身缓存数据库的写服务的步骤S205之前,在部署所述未宕机的目标主节点对应的目标从节点的步骤之后,所述方法还可以包括:
判断所部署目标从节点中写入的所有缓存数据是否均被完整持久化为持久数据。如果均被持久化为持久数据,执行上述控制所部署的目标主节点开启自身缓存数据库的写服务的步骤。
在部署该未宕机的目标主节点对应的目标从节点后,判断所部署目标从节点中写入的所有缓存数据是否均被完整持久化为持久数据的具体实现方式可以是多种多样的。示例性的,对于AOF持久化机制,代理服务器可以判断所部署目标从节点中的字段aof_base_size的数值是否为0,如果为0,则表示所部署目标从节点中写入的所有缓存数据没有均被完整持久化为持久数据,如果为非零值,则表示所部署目标从节点中写入的所有缓存数据均被完整持久化为持久数据。
可以理解,如果此判断过程的判断结果为否,则代理服务器不会执行上述控制所部署的目标主节点开启自身缓存数据库的写服务的步骤。另外,在此判断过程的判断结果为否的情况下,代理服务器还可以检测从目标从节点完成部署至所部署目标从节 点完成持久化操作的时间是否超过预设时长,如果超过,则生成持久化操作超过预设时长的报警信息,以使得操作人员可以针对此问题做出应对措施。
可以理解,图1、2和4分别所示的宕机恢复方法实施例中,均是针对主从***中目标主节点和目标从节点均宕机的情况进行说明的,在实际的主从***中,还存在另外两种节点宕机情况。
第一种情况下,目标主节点正常工作,目标从节点宕机,此情况即为上述部署该未宕机的目标主节点对应的目标从节点的情况,恢复主从***的过程参照上述步骤S103实现即可。
另一种情况下,目标主节点宕机,目标从节点正常工作,此时,假设目标主节点和目标从节点为redis集群中的一组主节点和主节点对应的从节点,则恢复主从***的过程可以如下:
当检测到目标主节点宕机时,首先关闭目标从节点的服务,例如向该未宕机的目标从节点发送client_pasue命令,然后,执行切换该目标从节点为新的目标主节点的操作。另外,代理服务器监测从检测到目标主节点宕机至目标从节点成为新的目标主节点所经过的时间是否超过一预设时长,当超过该预设时长时,针对此生成报警信息,以使得操作人员可以及时发现目标从节点无法成为新的目标从节点的原因。
在目标从节点成功切换为新的目标主节点后,主从***中不再存在目标从节点,所以此时需要部署一个新的目标从节点。
首先,代理服务器可以判断宕机的目标主节点所在的节点承建器是否宕机,如果目标主节点所在的节点承建器未宕机,则利用数据库配置文件redis.conf以及宕机的目标主节点中的节点配置文件node.conf重启发生宕机的目标主节点,得到一个节点S。如果目标主节点所在的节点承建器宕机,则重启目标主节点所在的节点承建器,如果成功重启目标主节点所在的节点承建器,则同样利用数据库配置文件redis.conf以及宕机的目标主节点中的节点配置文件node.conf重启发生宕机的目标主节点,得到一个节点S。
如果重启目标主节点所在的节点承建器宕机失败,则代理服务器需要在其所控制的物理机上新建一个节点承建器。如果未能成功创建节点承载器,则生成创建节点承载器失败的报警信息;如果成功创建节点承载器,在所创建节点承载器中创建一个节点,并通过cluster_add_slave命令将所创建节点加入到redis集群中,得到节点S。
在得到节点S后,代理服务器将该节点S配置为当前的目标主节点的目标从节点, 即新的目标从节点。此后,新的目标从节点基于主从复制机制开始复制当前目标主节点中的数据至本地,而代理服务器则可以监测新的目标从节点是否完成主从复制操作。
在实际应用中,可以通过检查目标从节点中的字段master_link_status为up还是down,如果为up,表明新的目标从节点完成主从复制,如果为down,则表明新的目标从节点未完成主从复制。同时,代理服务器还可以监测新的目标从节点复制当前目标主节点中缓存数据到本地所消耗的时间是否超过一预设时长;如果超过,则针对此生成报警信息,以使得操作人员可以查找新的目标从节点复制当前目标主节点中缓存数据到本地所消耗的时间超过预设时长的原因。
在新的目标从节点完成主从复制之前,如果新的目标主节点再次发生宕机,则此时可以看作是主从***中的目标主节点和目标从节点均宕机的情况,而此时持久化文件存在于原目标从节点中,即最新宕机的目标主节点中。
可以理解,该新的目标从节点配置有持久化机制,假设为AOF持久化机制,则代理服务器还应该监测新的目标从节点是否将写入的所有缓存数据持久化为持久数据,如代理服务器可以判断新的目标从节点中的字段aof_base_size的数值是否为0,如果为0,则表示当前新的目标从节点还未将写入的所有缓存数据持久化为持久数据;如果为非零值,当前新的目标从节点已将写入的所有缓存数据持久化为持久数据。
如果新的目标从节点已将写入的所有缓存数据持久化为持久数据,则代理服务器可以开启新的目标主节点的数据库写服务,并关闭新的目标主节点中所部署的持久化机制,删除新的目标主节点中所存储的持久化文件。
另外,在新的目标从节点还未将写入的所有缓存数据持久化为持久数据的情况下,代理服务器还可以检测从新的目标从节点完成主从复制至新的目标从节点完成持久化操作的时间是否超过预设时长,如果超过,则生成持久化操作超过预设时长的报警信息,以使得操作人员可以针对此问题做出应对措施。
相应于图1所示方法实施例,本申请实施例还提供了一种节点宕机恢复装置,应用于主从***中的代理服务器,该主从***还包括代理服务器所控制的目标主节点以及目标主节点对应的目标从节点,如图5所示,上述节点宕机恢复装置包括:
确定模块110,配置为如果目标主节点和目标从节点均宕机,则从目标从节点中获取预存的持久化文件;
其中,所述目标从节点中备份有所述目标主机点中的缓存数据,所述持久化文件为基于所述目标从节点中的缓存数据生成。
第一部署模块120,配置为基于持久化文件,部署未宕机的目标主节点;
第二部署模块130,配置为部署该未宕机的目标主节点对应的目标从节点。
具体的,相应于上述图2所示方法实施例,上述主从***中的节点创建在节点承建器上,节点承建器包括LXC容器或虚拟机;
相应的,上述第一部署模块120,可以配置为:
在第一节点承建器宕机且重启第一节点承建器失败的情况下,在代理服务器所控制的物理机中新建一个节点承建器;基于持久化文件,在所新建的节点承建器中新建目标主节点;其中,该第一节点承建器为创建有上述发生宕机的目标主节点的节点承建器;
在第一节点承建器未宕机或者宕机后被成功重启的情况下,基于持久化文件,重启发生宕机的目标主节点。
作为本申请实施例一种可选的实现方式,上述主从***还包括除目标主节点外代理服务器所控制的非目标主节点、以及每个非目标主节点所对应的非目标从节点;
主从***中所有主节点与从节点构成缓存数据库集群,缓存数据库集群中的每个节点中均携带有节点配置文件,节点配置文件中包含缓存数据库集群中每个节点的通用唯一识别码UUID;
相应于图2所示方法实施例,上述第一部署模块120,可以配置为:
在第一节点承建器宕机且重启第一节点承建器失败的情况下,在代理服务器所控制的物理机中新建一个节点承建器;判断发生宕机的目标主节点中的目标节点配置文件是否丢失;
如果丢失,基于持久化文件,在所新建的节点承建器中创建一个节点;将所创建节点配置到缓存数据库集群中,并从缓存数据库集群中除目标主节点外的节点中获得目标主节点的UUID,将目标主节点的UUID配置给所创建的节点,完成目标主节点的新建;
如果未丢失,基于持久化文件和目标节点配置文件,在所新建的节点承建器中创建一个节点,将所创建节点配置到缓存数据库集群中,完成目标主节点的新建;
在第一节点承建器未宕机或者宕机后被成功重启的情况下,判断发生宕机的目标主节点中的目标节点配置文件是否丢失;
如果丢失,从缓存数据库集群中除目标主节点外的节点中获得节点配置文件,基于持久化文件以及所获得的节点配置文件,重启发生宕机的目标主节点;
如果未丢失,基于持久化文件以及目标节点配置文件,重启发生宕机的目标主节点。
作为本申请实施例一种可选的实现方式,上述装置还可以包括:
监测模块,配置为在代理服务器所控制的物理机中新建节点承建器后,监测是否成功新建节点承建器;
生成模块,配置为在监测模块的监测结果为否的情况下,生成失败报警信息;
相应的,第一部署模块120基于持久化文件,在所新建的节点承建器中新建目标主节点,可以为:
在监测模块的监测结果为是的情况下,基于持久化文件,在所新建的节点承建器中新建目标主节点。
作为本申请实施例一种可选的实现方式,相应于图4所示方法实施例,如图6所示,上述装置还可以包括:
控制模块140,配置为在部署该未宕机的目标主节点对应的目标从节点之前,控制所部署的目标主节点关闭自身缓存数据库的写服务;在部署该未宕机的目标主节点对应的目标从节点之后,控制所部署的目标主节点开启自身缓存数据库的写服务。
作为本申请实施例一种可选的实现方式,上述装置还可以包括:
判断模块,配置为在控制所部署的目标主节点开启自身缓存数据库的写服务之前,在部署该未宕机的目标主节点对应的目标从节点之后,判断所部署目标从节点中写入的所有缓存数据是否均被完整持久化为持久数据;
相应的,上述控制模块140,可以配置为在判断模块的判断结果为是的情况下,控制所部署的目标主节点开启自身缓存数据库的写服务。
作为本申请实施例一种可选的实现方式,上述第二部署模块130,可以配置为:
基于主从复制机制,部署该未宕机的目标主节点对应的目标从节点。
在一实施方式中,在上述主从***中的节点创建在节点承建器上的情况下,上述第二部署模块,可以配置为:
在第二节点承建器宕机且重启第二节点承建器失败的情况下,在代理服务器所控制的物理机中新建一个节点承建器;并基于主从复制机制,在所新建的节点承建器中新建目标从节点;其中,该第二节点承建器为创建有上述发生宕机的目标从节点的节点承建器;
在第二节点承建器未宕机或者宕机后被成功重启的情况下,基于主从复制机制,重启发生宕机的目标从节点。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持 久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
本申请实施例还提供了一种电子设备,如图7所示,包括处理器210和存储器220,其中,
存储器220,配置为存放计算机程序;
处理器210,配置为执行存储器220上所存放的程序时,实现如下步骤:
如果目标主节点和目标从节点均宕机,则从目标从节点获取预存的持久化文件;
其中,所述目标从节点中备份有所述目标主机点中的缓存数据,所述持久化文件为基于所述目标从节点中的缓存数据生成;
基于目标从节点所生成的持久化文件,部署未宕机的目标主节点;
部署该未宕机的目标主节点对应的目标从节点。
关于该方法各个步骤的具体实现以及相关解释内容可以参见上述图1、2和3所示的方法实施例,在此不做赘述。
上述电子设备可以具备有实现上述电子设备与其他设备之间通信的通信接口。
上述的处理器210,通信接口,存储器220通过通信总线完成相互间的通信,此处所提到的通信总线可以是外设部件互连标准(Peripheral Component Interconnect,PCI)总线或扩展工业标准结构(Extended Industry Standard Architecture,EISA)总线等。该通信总线可以分为地址总线、数据总线、控制总线等。
存储器220可以包括随机存取存储器(Random Access Memory,RAM),也可以包括非易失性存储器(Non-Volatile Memory,NVM),例如至少一个磁盘存储器。可选的,存储器还可以是至少一个位于远离前述处理器的存储装置。
上述的处理器210可以是通用处理器,包括中央处理器(Central Processing Unit,CPU)、网络处理器(Network Processor,NP)等;还可以是数字信号处理器(Digital Signal Processing,DSP)、专用集成电路(Application Specific Integrated Circuit,ASIC)、现场可编程门阵列(Field-Programmable Gate Array,FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持 久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
在本申请提供的又一实施例中,还提供了一种计算机可读存储介质,该计算机可读存储介质中存储有指令,当其在计算机上运行时,使得计算机执行上述实施例中任一所述的节点宕机恢复方法。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
在本申请提供的再一实施例中,还提供了一种包含指令的计算机程序产品,当其在计算机上运行时,使得计算机执行上述任一节点宕机恢复方法所述的方法步骤。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
在本申请提供的再一实施例中,还提供了一种计算机程序,当其在计算机上运行时,使得计算机执行上述任一节点宕机恢复方法所述的方法步骤。
由以上可知,与现有技术相比,本实施例提供的方案中,目标从节点中被配置有针对于缓存数据的持久化机制,所以通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,达到提高主从***可用性的目的。此外,上述目标主节点中未配置有持久化机 制,可以有效避免目标主节点因自身配置持久化机制而导致的主从***提供数据读写服务性能降低的问题。
需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
本申请提供一种节点宕机恢复方法、装置、电子设备及存储介质,目标从节点中被配置有针对于缓存数据的持久化机制,通过目标从节点基于所配置持久化机制生成的持久化文件可以复原目标主节点中的缓存数据;在目标主节点和目标从节点均宕机后,可以利用该持久化文件复原主从***的缓存数据,进而将主从***恢复到正常的工作状态,提高主从***的可用性,保证主从***中的主节点及其对应的从节点均宕机后,主从***可以恢复到正常的工作状态。
Claims (18)
- 一种节点宕机恢复方法,其中,应用于主从***中的代理服务器,所述主从***还包括所述代理服务器所控制的目标主节点以及所述目标主节点对应的目标从节点,所述方法包括;如果所述目标主节点和所述目标从节点均宕机,则从所述目标从节点中获取预存的持久化文件;其中,所述目标从节点中备份有所述目标主机点中的缓存数据,所述持久化文件为基于所述目标从节点中的缓存数据生成;基于所述持久化文件,部署未宕机的目标主节点;部署所述未宕机的目标主节点对应的目标从节点。
- 根据权利要求1所述的方法,其中,所述主从***中的节点创建在节点承建器上;所述基于所述持久化文件,部署未宕机的目标主节点的步骤,包括:在第一节点承建器宕机且重启所述第一节点承建器失败的情况下,在所述代理服务器所控制的物理机中新建一个节点承建器;其中,所述第一节点承建器为创建有发生宕机的所述目标主节点的节点承建器;基于所述持久化文件,在所新建的节点承建器中新建目标主节点;在所述第一节点承建器未宕机或者宕机后被成功重启的情况下,基于所述持久化文件,重启发生宕机的目标主节点。
- 根据权利要求2所述的方法,其中,所述主从***还包括除所述目标主节点外所述代理服务器所控制的非目标主节点、以及每个所述非目标主节点所对应的非目标从节点;所述主从***中所有主节点与从节点构成缓存数据库集群,所述缓存数据库集群中的每个节点中均携带有节点配置文件,所述节点配置文件中包含所述缓存数据库集群中每个节点的通用唯一识别码UUID;所述基于所述持久化文件,在所新建的节点承建器中新建目标主节点的步骤,包括:判断发生宕机的目标主节点中的目标节点配置文件是否丢失;如果丢失,基于所述持久化文件,在所新建的节点承建器中创建一个节点;将所创建节点配置到所述缓存数据库集群中,并从所述缓存数据库集群中除所述目标主节点外的节点中获得目标主节点的UUID,将所述目标主节点的UUID配置给所创建的节点,完成目标主节点的新建;如果未丢失,基于所述持久化文件和所述目标节点配置文件,在所新建的节点承建器 中创建一个节点,将所创建节点配置到所述缓存数据库集群中,完成目标主节点的新建;所述基于所述持久化文件,重启发生宕机的目标主节点的步骤,包括:判断发生宕机的目标主节点中的目标节点配置文件是否丢失;如果丢失,从所述缓存数据库集群中除所述目标主节点外的节点中获得节点配置文件,基于所述持久化文件以及所获得的节点配置文件,重启发生宕机的目标主节点;如果未丢失,基于所述持久化文件以及所述目标节点配置文件,重启发生宕机的目标主节点。
- 根据权利要求2所述的方法,其中,在所述在所述代理服务器所控制的物理机中新建一个节点承建器的步骤之后,所述方法还包括:监测是否成功新建节点承建器;如果不成功,生成失败报警信息。
- 根据权利要求1所述的方法,其中,在所述部署所述未宕机的目标主节点对应的目标从节点的步骤之前,所述方法还包括:控制所部署的目标主节点关闭自身缓存数据库的写服务;在所述部署所述未宕机的目标主节点对应的目标从节点的步骤之后,所述方法还包括:控制所部署的目标主节点开启自身缓存数据库的写服务。
- 根据权利要求5所述的方法,其中,在所述控制所部署的目标主节点开启自身缓存数据库的写服务的步骤之前,在部署所述未宕机的目标主节点对应的目标从节点的步骤之后,所述方法还包括:判断所部署目标从节点中写入的所有缓存数据是否均被完整持久化为持久数据;如果均被持久化为持久数据,执行上述控制所部署的目标主节点开启自身缓存数据库的写服务的步骤。
- 根据权利要求1-6任一项所述的方法,其中,所述部署所述未宕机的目标主节点对应的目标从节点的步骤,包括:基于主从复制机制,部署所述未宕机的目标主节点对应的目标从节点。
- 一种节点宕机恢复装置,应用于主从***中的代理服务器,所述主从***还包括所述代理服务器所控制的目标主节点以及所述目标主节点对应的目标从节点,所述装置包括:确定模块,配置为如果所述目标主节点和所述目标从节点均宕机,则从所述目标从节 点中获取预存的持久化文件;其中,所述目标从节点中备份有所述目标主机点中的缓存数据,所述持久化文件为基于所述目标从节点中的缓存数据生成;第一部署模块,配置为基于所述持久化文件,部署未宕机的目标主节点;第二部署模块,配置为部署所述未宕机的目标主节点对应的目标从节点。
- 根据权利要求8所述的装置,其中,所述主从***中的节点创建在节点承建器上;所述第一部署模块,配置为:在第一节点承建器宕机且重启所述第一节点承建器失败的情况下,在所述代理服务器所控制的物理机中新建一个节点承建器;基于所述持久化文件,在所新建的节点承建器中新建目标主节点;其中,所述第一节点承建器为创建有发生宕机的所述目标主节点的节点承建器;在所述第一节点承建器未宕机或者宕机后被成功重启的情况下,基于所述持久化文件,重启发生宕机的目标主节点。
- 根据权利要求9所述的装置,其中,所述主从***还包括除所述目标主节点外所述代理服务器所控制的非目标主节点、以及每个所述非目标主节点所对应的非目标从节点;所述主从***中所有主节点与从节点构成缓存数据库集群,所述缓存数据库集群中的每个节点中均携带有节点配置文件,所述节点配置文件中包含所述缓存数据库集群中每个节点的通用唯一识别码UUID;所述第一部署模块,配置为:在所述第一节点承建器宕机且重启所述第一节点承建器失败的情况下,在所述代理服务器所控制的物理机中新建一个节点承建器;判断发生宕机的目标主节点中的目标节点配置文件是否丢失;如果丢失,基于所述持久化文件,在所新建的节点承建器中创建一个节点;将所创建节点配置到所述缓存数据库集群中,并从所述缓存数据库集群中除所述目标主节点外的节点中获得目标主节点的UUID,将所述目标主节点的UUID配置给所创建的节点,完成目标主节点的新建;如果未丢失,基于所述持久化文件和所述目标节点配置文件,在所新建的节点承建器中创建一个节点,将所创建节点配置到所述缓存数据库集群中,完成目标主节点的新建;在所述第一节点承建器未宕机或者宕机后被成功重启的情况下,判断发生宕机的目标主节点中的目标节点配置文件是否丢失;如果丢失,从所述缓存数据库集群中除所述目标主节点外的节点中获得节点配置文件,基于所述持久化文件以及所获得的节点配置文件,重启发生宕机的目标主节点;如果未丢失,基于所述持久化文件以及所述目标节点配置文件,重启发生宕机的目标主节点。
- 根据权利要求9所述的装置,其中,所述装置还包括:监测模块,配置为在所述代理服务器所控制的物理机中新建节点承建器后,监测是否成功新建节点承建器;生成模块,配置为在所述监测模块的监测结果为否的情况下,生成失败报警信息。
- 根据权利要求8所述的装置,其中,所述装置还包括:控制模块,配置为在部署所述未宕机的目标主节点对应的目标从节点之前,控制所部署的目标主节点关闭自身缓存数据库的写服务;在部署所述未宕机的目标主节点对应的目标从节点之后,控制所部署的目标主节点开启自身缓存数据库的写服务。
- 根据权利要求12所述的装置,其中,所述装置还包括:判断模块,配置为在控制所部署的目标主节点开启自身缓存数据库的写服务之前,在部署所述未宕机的目标主节点对应的目标从节点之后,判断所部署目标从节点中写入的所有缓存数据是否均被完整持久化为持久数据;所述控制模块,配置为在所述判断模块的判断结果为是的情况下,控制所部署的目标主节点开启自身缓存数据库的写服务。
- 根据权利要求8-13任一项所述的装置,其中,所述第二部署模块,配置为:基于主从复制机制,部署所述未宕机的目标主节点对应的目标从节点。
- 一种电子设备,包括处理器和存储器,其中:存储器,配置为存放计算机程序;处理器,配置为执行存储器上所存放的程序时,实现权利要求1-7任一所述的方法步骤。
- 一种计算机可读存储介质,所述计算机可读存储介质内存储有计算机程序,所述计算机程序被处理器执行时实现权利要求1-7任一所述的方法步骤。
- 一种包含指令的计算机程序产品,所述包含指令的计算机程序产品在计算机上运行时,使得计算机执行权利要求1-7任一所述的方法步骤。
- 一种计算机程序,所述计算机程序在计算机上运行时,使得计算机执行权利要求 1-7任一所述的方法步骤。
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
SG11202004763PA SG11202004763PA (en) | 2017-11-21 | 2018-11-21 | Node down recovery method and apparatus, electronic device, and storage medium |
US16/766,031 US11249860B2 (en) | 2017-11-21 | 2018-11-21 | Node down recovery method and apparatus, electronic device, and storage medium |
RU2020119358A RU2751551C1 (ru) | 2017-11-21 | 2018-11-21 | Способ и устройство для восстановления нарушенной работоспособности узла, электронное устройство и носитель данных |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201711164996.X | 2017-11-21 | ||
CN201711164996.XA CN109815049B (zh) | 2017-11-21 | 2017-11-21 | 节点宕机恢复方法、装置、电子设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019101095A1 true WO2019101095A1 (zh) | 2019-05-31 |
Family
ID=66600280
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2018/116671 WO2019101095A1 (zh) | 2017-11-21 | 2018-11-21 | 节点宕机恢复方法、装置、电子设备及存储介质 |
Country Status (5)
Country | Link |
---|---|
US (1) | US11249860B2 (zh) |
CN (1) | CN109815049B (zh) |
RU (1) | RU2751551C1 (zh) |
SG (1) | SG11202004763PA (zh) |
WO (1) | WO2019101095A1 (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112035435A (zh) * | 2020-08-26 | 2020-12-04 | 浪潮云信息技术股份公司 | MySQL主从集群安装部署方法及集群*** |
CN113434515A (zh) * | 2021-07-23 | 2021-09-24 | 深圳智多豚物联技术有限公司 | 基于持久化redis存储服务的分布式高速存储*** |
Families Citing this family (18)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110333986B (zh) * | 2019-06-19 | 2023-12-29 | 上海二三四五网络科技有限公司 | 一种保障redis集群可用性的方法 |
CN112199240B (zh) * | 2019-07-08 | 2024-01-30 | 华为云计算技术有限公司 | 一种节点故障时进行节点切换的方法及相关设备 |
CN111291101A (zh) * | 2019-12-17 | 2020-06-16 | 航天信息股份有限公司 | 集群管理方法及*** |
CN113127557B (zh) * | 2019-12-31 | 2022-12-13 | ***通信集团四川有限公司 | 基于redis性能的数据持久化方法、装置及电子设备 |
CN111708783A (zh) * | 2020-06-18 | 2020-09-25 | 北京金山云网络技术有限公司 | 数据存储和数据恢复方法、装置及电子设备 |
CN111970329A (zh) * | 2020-07-24 | 2020-11-20 | 苏州浪潮智能科技有限公司 | 一种集群服务的部署方法、***、设备以及介质 |
CN112100004A (zh) * | 2020-08-12 | 2020-12-18 | 福建天泉教育科技有限公司 | Redis集群节点的管理方法、存储介质 |
CN112671550A (zh) * | 2020-09-24 | 2021-04-16 | 紫光云技术有限公司 | 一种云计算中防止设备配置丢失的方法 |
CN112231148B (zh) * | 2020-10-23 | 2022-07-05 | 北京思特奇信息技术股份有限公司 | 分布式缓存数据离线传输方法、装置及可读存储介质 |
CN112506713B (zh) * | 2020-12-25 | 2023-11-24 | 北京字跳网络技术有限公司 | 多级容灾***及方法 |
CN112685498A (zh) * | 2020-12-28 | 2021-04-20 | 紫光云技术有限公司 | 一种云平台上Redis数据持久化的方法 |
CN113297173B (zh) * | 2021-05-24 | 2023-10-31 | 阿里巴巴新加坡控股有限公司 | 分布式数据库集群管理方法及装置、电子设备 |
CN114138732A (zh) * | 2021-09-29 | 2022-03-04 | 聚好看科技股份有限公司 | 一种数据处理方法及装置 |
CN114205333B (zh) * | 2021-12-09 | 2024-02-27 | 北京奇妙时光科技有限公司 | Ip配置方法、集群构建方法、计算机设备及存储介质 |
CN114422521B (zh) * | 2022-01-12 | 2024-04-05 | 北京京东振世信息技术有限公司 | 确定主节点的方法、装置、电子设备及存储介质 |
CN114047941B (zh) * | 2022-01-12 | 2022-04-26 | 飞狐信息技术(天津)有限公司 | 一种redis服务节点的配置升级方法及装置 |
CN114915577A (zh) * | 2022-04-22 | 2022-08-16 | 武汉泰铭恒创信息技术股份有限公司 | 基于非阻塞io模型的设备通讯方法 |
CN115238005B (zh) * | 2022-07-25 | 2023-04-28 | 中电金信软件有限公司 | 一种基于消息中间件集群的数据同步方法及*** |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3887130B2 (ja) * | 1999-07-30 | 2007-02-28 | 株式会社東芝 | 高可用性計算機システム及び同システムにおけるデータバックアップ方法 |
CN106557278A (zh) * | 2015-09-30 | 2017-04-05 | 腾讯科技(深圳)有限公司 | 一种缓存数据持久化的方法 |
CN107329708A (zh) * | 2017-07-04 | 2017-11-07 | 郑州云海信息技术有限公司 | 一种分布式存储***实现缓存数据的方法及*** |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS59161771A (ja) * | 1983-03-04 | 1984-09-12 | Fujitsu Ltd | ト−タリゼ−タシステムの自動リカバリ方式 |
AU2001249211A1 (en) * | 2000-03-30 | 2001-10-15 | Intel Corporation | Distributed edge network architecture |
RU2234811C1 (ru) * | 2003-05-26 | 2004-08-20 | Военный университет связи | Способ формирования и восстановления сети синхронизации сети связи |
US8306951B2 (en) * | 2009-09-18 | 2012-11-06 | Oracle International Corporation | Automated integrated high availability of the in-memory database cache and the backend enterprise database |
CN101562543B (zh) * | 2009-05-25 | 2013-07-31 | 阿里巴巴集团控股有限公司 | 一种缓存数据的处理方法、处理***和装置 |
US8856593B2 (en) | 2010-04-12 | 2014-10-07 | Sandisk Enterprise Ip Llc | Failure recovery using consensus replication in a distributed flash memory system |
CN102340407B (zh) | 2010-07-21 | 2015-07-22 | 中兴通讯股份有限公司 | 保护倒换方法及*** |
CN102693324B (zh) | 2012-01-09 | 2015-03-18 | 西安电子科技大学 | 一种分布式数据库同步***、同步方法和节点管理方法 |
US9489434B1 (en) | 2012-01-17 | 2016-11-08 | Amazon Technologies, Inc. | System and method for replication log branching avoidance using post-failover rejoin |
US8832234B1 (en) | 2012-03-29 | 2014-09-09 | Amazon Technologies, Inc. | Distributed data storage controller |
CN104468651B (zh) * | 2013-09-17 | 2019-09-10 | 南京中兴新软件有限责任公司 | 分布式多副本数据存储方法及装置 |
CN105975546A (zh) | 2016-05-03 | 2016-09-28 | 叶江鹏 | 一种新型计算机监管*** |
-
2017
- 2017-11-21 CN CN201711164996.XA patent/CN109815049B/zh active Active
-
2018
- 2018-11-21 US US16/766,031 patent/US11249860B2/en active Active
- 2018-11-21 WO PCT/CN2018/116671 patent/WO2019101095A1/zh active Application Filing
- 2018-11-21 RU RU2020119358A patent/RU2751551C1/ru active
- 2018-11-21 SG SG11202004763PA patent/SG11202004763PA/en unknown
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3887130B2 (ja) * | 1999-07-30 | 2007-02-28 | 株式会社東芝 | 高可用性計算機システム及び同システムにおけるデータバックアップ方法 |
CN106557278A (zh) * | 2015-09-30 | 2017-04-05 | 腾讯科技(深圳)有限公司 | 一种缓存数据持久化的方法 |
CN107329708A (zh) * | 2017-07-04 | 2017-11-07 | 郑州云海信息技术有限公司 | 一种分布式存储***实现缓存数据的方法及*** |
Non-Patent Citations (1)
Title |
---|
ZMF: "Redis master-slave configuration- IT610.com", IT610.COM, 18 June 2015 (2015-06-18), pages 1 - 5, XP055613507, Retrieved from the Internet <URL:http://www.it610.com/article/2698246.htm> * |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112035435A (zh) * | 2020-08-26 | 2020-12-04 | 浪潮云信息技术股份公司 | MySQL主从集群安装部署方法及集群*** |
CN112035435B (zh) * | 2020-08-26 | 2024-04-30 | 浪潮云信息技术股份公司 | MySQL主从集群安装部署方法及集群*** |
CN113434515A (zh) * | 2021-07-23 | 2021-09-24 | 深圳智多豚物联技术有限公司 | 基于持久化redis存储服务的分布式高速存储*** |
CN113434515B (zh) * | 2021-07-23 | 2022-10-14 | 深圳智多豚物联技术有限公司 | 基于持久化redis存储服务的分布式高速存储*** |
Also Published As
Publication number | Publication date |
---|---|
US11249860B2 (en) | 2022-02-15 |
CN109815049A (zh) | 2019-05-28 |
SG11202004763PA (en) | 2020-06-29 |
CN109815049B (zh) | 2021-03-26 |
US20200364114A1 (en) | 2020-11-19 |
RU2751551C1 (ru) | 2021-07-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2019101095A1 (zh) | 节点宕机恢复方法、装置、电子设备及存储介质 | |
CN107870829B (zh) | 一种分布式数据恢复方法、服务器、相关设备及*** | |
JP5714571B2 (ja) | キャッシュクラスタを構成可能モードで用いるキャッシュデータ処理 | |
US8359493B2 (en) | Mechanism to provide assured recovery for distributed application | |
WO2016070375A1 (zh) | 一种分布式存储复制***和方法 | |
CN111427728B (zh) | 状态管理方法、主备切换方法及电子设备 | |
US20120131126A1 (en) | Mirroring Solution in Cloud Storage Environment | |
WO2016045439A1 (zh) | 一种vnfm容灾保护的方法、装置和nfvo、存储介质 | |
CN102394914A (zh) | 集群脑裂处理方法和装置 | |
EP3232609A1 (en) | Locking request processing method and server | |
CN115562911B (zh) | 虚拟机数据备份方法及装置、***、电子设备、存储介质 | |
CN114138732A (zh) | 一种数据处理方法及装置 | |
US10860411B2 (en) | Automatically detecting time-of-fault bugs in cloud systems | |
US20190205227A1 (en) | Replication system with network failover | |
WO2017092539A1 (zh) | 虚拟机修复方法、虚拟机装置、***及业务功能网元 | |
US8812900B2 (en) | Managing storage providers in a clustered appliance environment | |
JP6335336B2 (ja) | ストレージシステムおよびその制御方法 | |
JP5812512B2 (ja) | データベースシステム、マスタースレーブ管理方法およびマスタースレーブ管理プログラム | |
CN114500577A (zh) | 数据访问***及数据访问方法 | |
CN112131201A (zh) | 一种网络附加存储高可用性的方法、***、设备及介质 | |
CN112612652A (zh) | 分布式存储***异常节点重启方法及*** | |
JP5947974B2 (ja) | 情報処理装置及び情報処理装置の交換支援システム並びに交換支援方法 | |
CN112035250A (zh) | 高可用局域网服务管理方法、设备及部署架构 | |
JP6364773B2 (ja) | 情報処理装置、情報処理システム、メモリレプリケーション方法、並びにコンピュータ・プログラム | |
CN117785568B (zh) | 一种双主双机热备方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 18880330 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 18880330 Country of ref document: EP Kind code of ref document: A1 |