WO2018059032A1

WO2018059032A1 - Data migration method for virtual node, and virtual node

Info

Publication number: WO2018059032A1
Application number: PCT/CN2017/090613
Authority: WO
Inventors: 陶维忠; 吴刚
Original assignee: 华为技术有限公司
Priority date: 2016-09-30
Filing date: 2017-06-28
Publication date: 2018-04-05
Also published as: CN107885758B; CN107885758A

Abstract

A data migration method for a virtual node, comprising: a source physical node receives a migration indication message; the source physical node determines, according to the migration indication message, a target physical node and at least one virtual node to be migrated on the source physical node; obtain data structure information of the source physical node, and obtain all service objects to which the at least one virtual node belongs according to the data structure information; the source physical node migrates all the service objects to the target physical node by using the service objects as granularity. Also provided is a physical node which can achieve the migration of relational data.

Description

Data migration method and virtual node of virtual node

This application claims priority to Chinese Patent Application No. 201610877920.0, filed on Sep. 30, 2016, entitled "A Data Transfer Method and Virtual Node of a Virtual Node", the entire contents of which are incorporated by reference. In this application.

Technical field

The present invention relates to the field of computer technologies, and in particular, to a data migration method and a virtual node of a virtual node.

Background technique

At present, distributed database technology is a distributed technology commonly used in the field of IT technology. It is mainly applied to webpage page caching, database caching, etc. to meet the requirements of users for the response speed of network systems.

In a distributed database system based on a consistent hash algorithm, a physical node can virtualize multiple virtual nodes, and then map multiple virtual nodes to the ring through a hash algorithm, so that the physical nodes can be mapped on the ring. The range of hash values. In a distributed database system, when multiple physical nodes do not meet the load balancing conditions, the virtual nodes on the physical nodes need to be migrated; for example, when a physical node is added to a distributed database system or a physical node is deleted, the physical node association is adjusted. The number of virtual nodes is such that the number of virtual nodes associated with each physical node tends to be equal, so that all physical nodes of the distributed database system implement load balancing of the virtual nodes. In the current virtual node migration scheme, the MVCC (Mult i-Version Concurrency Control) mechanism performs migration on data in a distributed database, and the migration process avoids the use of locks, thereby having the advantage of low overhead, but This migration mechanism is only applicable to non-relational databases.

Summary of the invention

The embodiment of the invention discloses a data migration method and a physical node of a virtual node, which can implement data migration of a relational database on a physical node.

In a first aspect, the present application provides a data migration method for a virtual node, where the source physical node and the target physical node include but are not limited to a minicomputer, an x86 server, a personal workstation, or another type of hardware server, a source physical node, and a target physical node. In the distributed database system, the distributed database system includes multiple physical nodes, and the method of triggering data migration may be: the metadata node detects multiple physical nodes in the distributed database system. The data migration is triggered when the load balancing condition is not met during the running of the service; or the metadata node detects the addition of a new physical node in the distributed database system, triggers data migration; or deletes a certain physical in the distributed database system. When a node is triggered, data migration is triggered; or data migration of a virtual node on a physical node in a distributed database system is manually triggered. When the metadata node detects that a virtual node of a physical node on multiple physical nodes needs to perform data migration, the metadata node determines the source physical node and the target physical node, and at least one virtual node to be migrated on the source physical node, and metadata. The node may send a migration indication message to the source physical node, where the migration indication message may carry the identifier of the target physical node and the identifier of the at least one virtual node to be migrated on the source physical node, where the migration indication message may be sent by the metadata node, Can be sent by other nodes in the distributed database system. The source physical node first receives the migration indication message, and determines at least one virtual node and the target physical node to be migrated according to the migration indication message, where the organization of the data on the virtual node may be a relational database, the virtual node includes multiple service objects, and the data structure The information indicates the association relationship of the service tables to which the multiple service objects belong, and the source physical node obtains the to-be-migrated according to the data structure information. One business object belongs to one virtual machine node, and the source physical node migrates all business objects to the target physical node in turn. In the foregoing embodiment, the data structure information of the virtual node to be migrated by the source physical node acquires the service object to be migrated according to the data structure information, and all the service objects are migrated to the target physical node, thereby implementing logical migration of the relational data.

In a possible implementation manner of the present application, the data structure information of the source physical node is obtained, and the service object to which the at least one virtual node to be migrated belongs according to the data structure information includes: the data structure information includes the data fragment table and the service. The object sub-table, the data fragment table is used to store the mapping relationship between the virtual node and the business object, for example, the mapping between the identifier of the virtual node and the identifier of the business object, and the identifier of the business object may be a hash value. The source physical node obtains the virtual node identifier of each virtual node in the at least one virtual node, and the source physical node queries the virtual node identifier as an index to query one or more service objects to which the at least one virtual node belongs according to the preset data fragmentation table. Obtaining all the business objects on the at least one virtual node. For any one of the business objects, the source physical node obtains the business object identifier of the business object, and queries the business object identifier according to the preset business object subsidiary table. The business table, the business table stores a plurality of business records, and the business records can be retrieved in the business table according to the identification of the business object.

In a possible implementation manner of the present application, before the source physical node performs the route switching, the source physical node receives the service access request of the client, and the source physical node performs the service access request according to the service object indicated by the service request, and the source physical node The service access request is recorded in the service log, and the service log is sent to the target physical node. The source physical node adds a timestamp or a version number to the service log, so that the target physical node can distinguish the order of the service logs. In the above embodiment, the source physical node receives the service access request sent by the client during the migration process of the service object, processes the service access request normally, does not affect the user service, implements online migration, and further passes the source physical node and the target physics. The synchronization of the service logs of the nodes keeps the data of the source physical node and the target physical node synchronized.

In a possible implementation manner of the present application, the method includes: the source physical node sends a migration completion message to the metadata node, where the migration of all the service objects corresponding to the at least one virtual node to be migrated is completed, and the migration is performed. The completion message is used to notify the metadata node that all the service objects to be migrated have been successfully migrated to the target physical node. After receiving the migration completion message, the metadata node sends a handover indication message to the source physical node, and the source physical node receives the handover indication message. Blocking client-initiated transactions, the transaction includes multiple business access requests, the transaction has the characteristics of integrity, and the transaction execution is completed under the condition that each service access request in multiple service accesses must be successfully executed, if multiple service access requests If any one or more of the business access requests are not successfully executed, the transaction is rolled back to re-execute the transaction. When the source physical node receives the handover indication message, if there is a started transaction, and the source physical node waits for the started transaction to be successfully executed, the source physical node returns a handover preparation message to the metadata node, and the handover preparation message indicates that the source physical node is used as the route. After the handover is prepared, the metadata node may send a route switch message to the client after receiving the handover preparation message, where the route switch message may include mapping relationship information between the at least one virtual node to be switched and the target physical node, and the client switches the message according to the route. Update routing information. In the above embodiment, the integrity of the data between the source physical node and the target physical node is effectively ensured, and the reliability is high.

In a possible implementation manner of the present application, the source physical node migrating all the service objects to the target physical node at the granularity of the service object includes: the source physical node selects a service object to be migrated from all the service objects, and The service object to be migrated is locked, and the service object to be migrated after the lock processing can only be read, and the write operation cannot be performed to prevent the business object to be migrated from being modified. The source physical node sends the service object to be migrated to the service object. On the target physical node, the source physical node deletes the service object to be migrated when the service object to be migrated is successfully migrated to the target physical node. In the foregoing embodiment, the service access request is transferred during the process of migrating the business object, and the occupied resources are small.

In a possible implementation manner of the present application, the method further includes: when the source physical node receives the service access request sent by the client for the service object to be accessed, the source physical node determines to be accessed. Whether the business object has been migrated to the target physical node. If yes, the source physical node returns a routing update message to the client, where the routing update message carries the identifier of the service object to be accessed and the identifier of the target physical node, and the client The physical node where the service object to be accessed is located may be updated according to the routing update message, so that when the client initiates a service access request for the service object to be accessed, the client directly sends a service access request to the target physical node according to the updated routing information.

In a possible implementation manner of the present application, the method further includes: when the business object migration is completed, the source physical node sends a migration completion message to the metadata node, where the migration completion message is used to notify the metadata node to migrate at least one virtual node. After the migration of all the service objects is completed, the metadata node receives the migration completion message and sends a route switch message to the client. The route switch message is used to instruct the client to update the physical node where the at least one virtual node to be migrated is located. The handover message carries at least one identifier of the virtual node and an identifier of the target physical node, and the client receives the routing switch message to update the routing information.

In a second aspect, the application provides a method for migrating a virtual node, including: receiving, by the target physical node, a migration indication message; wherein the migration indication message carries an identifier of the source physical node, and the target physical node receives the service sent by the source physical node. The target physical node determines that the data object to be migrated by the source physical node is complete, acquires the data structure information of all the received service objects, and reconstructs at least one virtual node according to the data structure information. In the above embodiment, the target physical node acquires the data structure information of the migrated business object, reconstructs the virtual node according to the data structure information, and implements data recovery.

In a possible implementation manner of the present application, the method further includes: the target physical node receives the service log sent by the source physical node, and performs service replay according to the service access request included in the log file. For example, the service replay is performed according to the time stamp of the service log or the version number.

In a possible implementation manner of the present application, the method further includes: when the target physical node determines that the service log transmission on the source physical node is completed, acquiring the target replica physical node allocated by the at least one virtual node, storing the service log and the All the business objects included in the at least one virtual node are migrated to the target replica physical node, the target replica service node receives the service object, reorganizes the virtual node according to the received service object, and performs service replay according to the received service log, and performs the virtual node for the virtual node. Backup. It should be noted that two or more virtual nodes that are mutually backed up are configured to meet the reverse affinity rules of the physical nodes, that is, at least two virtual nodes are located at different physical nodes, and the metadata nodes are based on The anti-affinity rule deploys the target physical node of the target physical node to improve the reliability of the virtual node.

In a third aspect, the application provides a physical node, where the physical node is a source physical node, and the source physical node includes:

a receiving module, configured to receive a migration indication message;

a determining module, configured to determine, according to the migration indication message, at least one virtual node to be migrated on the target physical node and the source physical node;

An obtaining module, configured to obtain data structure information of the source physical node itself, and obtain all service objects to which at least one virtual node belongs according to the data structure information;

A migration module for migrating all business objects to a target physical node at a granularity of business objects.

In a possible implementation manner, the data structure information includes a data fragment table and a data attachment table;

The get module is used to:

Querying one or more business objects to which at least one virtual node belongs according to the data fragmentation table, and querying a business table to which each of the plurality of business objects belongs according to the business object attachment table.

In a possible implementation manner, the method further includes:

a first access processing module, configured to receive a client to send a service access request;

Performing a business access request and returning a business access response to the client;

Log the service access request to the service log and send the service log to the target physical node.

In a possible implementation manner, the method further includes:

a transaction processing module, configured to send a migration completion message to the metadata node when the business object migration is completed;

Receiving a handover indication message returned by the metadata node according to the migration completion message;

Blocking the transaction initiated by the client when receiving the handover indication message;

In the case that the initiated transaction is successfully executed, a handover preparation message is returned to the metadata node; wherein the handover preparation message is used to indicate that the source physical node completes the route switching preparation.

In a possible implementation, the migration module is used to:

Select a business object to be migrated from all the business objects, and lock the business object to be migrated;

When the business object to be migrated is successfully migrated to the target physical node, the business object to be migrated is deleted.

In a possible implementation manner, the method further includes:

a second access processing module, configured to receive, during a migration process of the service object, a service access request sent by the client for the service object to be accessed;

Determining whether the business object to be accessed has been migrated to the target physical node;

If yes, return a routing update message to the client; where the routing update message is used to instruct the client to update the physical node where the business object to be accessed is located.

In a possible implementation manner, the method further includes:

The notification module is configured to send a migration completion message to the metadata node when the business object migration is completed; wherein the migration completion message is used to indicate that all the business objects to which the at least one virtual node belongs are migrated.

In a fourth aspect, the application provides a physical node, where the physical node is a target physical node, and the target physical node includes:

a determining module, configured to receive a migration indication message, and determine a source physical node according to the migration indication message;

a receiving module, configured to receive a service object sent by a source physical node;

The reconstruction module is configured to acquire data structure information of the received service object when the migration of the business object of the source physical node is completed, and reconstruct the virtual node according to the data structure information.

In a possible implementation manner, the method further includes:

The service recovery module is configured to receive a service log sent by the source physical node, and perform service replay according to the service log. The service log includes a service access request.

In a possible implementation manner, the method further includes:

The data backup module is configured to determine the physical node of the target replica in the case that the service log transmission on the source physical node is completed, and migrate the stored service log and the virtual node to the physical node of the target replica.

DRAWINGS

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are Some embodiments of the present invention may also be used to obtain other drawings based on these drawings without departing from the art.

1 is a schematic structural diagram of a distributed database system according to an embodiment of the present invention;

2 is a schematic flowchart of a data migration method of a virtual node according to an embodiment of the present invention;

3 is a schematic flowchart of still another method for data migration of a virtual node according to an embodiment of the present invention;

4a is a schematic flowchart of a method for acquiring a service object of a virtual node according to an embodiment of the present invention;

4b is a schematic diagram of a data structure of a physical node according to an embodiment of the present invention;

4c is a schematic diagram of a principle of a data migration method for a virtual node according to an embodiment of the present invention;

FIG. 5 is a schematic structural diagram of a physical node according to an embodiment of the present disclosure;

FIG. 6 is a schematic structural diagram of still another physical node according to an embodiment of the present disclosure;

FIG. 7 is a schematic structural diagram of still another physical node according to an embodiment of the present disclosure;

FIG. 8 is a schematic structural diagram of still another physical node according to an embodiment of the present invention.

detailed description

The technical solutions in the embodiments of the present invention are clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the present invention. It is obvious that the described embodiments are a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative efforts are within the scope of the present invention.

FIG. 1 is a schematic structural diagram of a hash-based distributed database system according to an embodiment of the present invention. In the embodiment of the present invention, a distributed database system includes at least one client, a metadata node, a physical node cluster, and Storage network. At least one client communicates with the metadata node and the physical node cluster through the IP network, wherein the communication interface between the client and the metadata node or the physical node cluster may be a TCP (Transmission Control Protocol) interface or UDP. (User Datagram Protocol) interface. The metadata node includes a data equalization device, and the metadata node may be deployed in an independent manner, for example, may be deployed by using a minicomputer, an X86 computer, a personal computer server PC server, or may be combined with a physical node cluster. The physical node cluster includes a plurality of physical nodes, and the physical node may be a minicomputer, an X86 computer, or a personal computer server PC server. The data of the plurality of physical nodes may be stored in a storage medium of the storage network, and the plurality of physical nodes and the storage network are The block is read and written by Block IO (block IO), that is, the storage medium is read and written by Block. The storage medium can be HDD (Hard Disk Drive), SSD (Solid State Drives), or memory. .

Among them, the metadata node mainly stores the metadata (Metadata) of the database system, and the metadata is information about the organization of the data, the data domain and the relationship thereof. In short, the metadata is the data used to describe the data. The data equalization device is responsible for the distributed management capabilities of the distributed database system as a whole. In addition to being deployed in a metadata node, the data equalization device can also be built into various physical nodes. The highly reliable deployment mode of the distributed database system may adopt a dual-machine or a cluster mode, and the present invention is not limited. The data equalization device mainly involves the following functions:

Metadata definition: store and update the mapping relationship between virtual nodes and physical nodes, copy definition of virtual nodes, load degree and weight coefficient calculation method of weight factors, configuration and storage of deviation coefficients, and fission strategy of virtual nodes.

Route management: Manage the routing data of the business object, and call the metadata definition unit interface according to the mapping relationship between the virtual node and the physical node.

Replication management: store and update the primary copy relationship of the virtual node, and is responsible for the management of replication integrity, calling the metadata definition unit interface.

Node monitoring: monitoring service information and node resource information, calling communication service unit, and acquiring each data service node Information and issue monitoring instructions.

Online migration: Provides online migration capability in units of data sharding, which has no impact on the business and ensures high availability of migration. The metadata definition interface is used to complete the routing and replication relationship changes.

Data equalization: Data balancing between physical nodes is achieved according to data equalization conditions.

Metadata Synchronization/Persistence: Synchronize metadata definition information to each physical node, the driver of the client, and the slave node of the data equalization device. When the metadata is changed, the change information needs to be notified to the above node, and the metadata is persisted to ensure high reliability of the data.

Communication service: Provides network communication capabilities with peripheral network elements (each physical node, the driver of the client, and the slaver node of the data equalization device).

A plurality of physical nodes may deploy an agent agent, and the agent is responsible for information interaction with the data equalization device (for example, reporting node health information, receiving instructions of the data equalization device, and providing self-management of node high availability, for example, domain degradation when the network is abnormal) .

In addition, the driver is also deployed on the client, and the routing information is cached in the driver. In this way, the client can complete the route judgment through the cached routing information and access the corresponding physical node, thereby preventing the data balancing device from becoming a bottleneck of the routing query during service access.

Referring to FIG. 2, FIG. 2 is a schematic flowchart of a data migration method of a virtual node according to an embodiment of the present invention, where the method includes but is not limited to the following steps.

S201. The metadata node detects that the migration condition is met.

Specifically, when the metadata node detects that multiple physical nodes in the distributed database system need to perform data migration, the source physical node, the target physical node, and the at least one virtual node to be migrated on the source physical node are determined. The distributed database system includes multiple physical nodes. The migration conditions include, but are not limited to, adding physical nodes to multiple physical nodes, deleting one physical node of multiple physical nodes, or multiple physical nodes that do not meet load balancing conditions. The equilibrium condition includes the equalization of the number of nodes on each physical node and the balance of traffic on each physical node; at this time, the distributed database system needs to perform data migration, so that the distributed database system satisfies the load balancing condition, and the metadata node determines the source physics. At least one virtual node to be migrated on the node, the target physical node, and the source physical node.

Exemplarily, the distributed database system includes three physical nodes, three physical nodes are physical node a, physical node b, and physical node c, and each of the three physical nodes includes four virtual nodes, when distributed When a physical node d is added to the database system, the metadata node detects that the distributed database system does not satisfy the load balancing condition (the load balancing condition is the number of virtual nodes), and the metadata node needs to be separately from the physical node a and the physical node. b. Select a virtual node in the physical node c and migrate the selected virtual node to the physical node d. The metadata node determines that the source physical node is the physical node a, the physical node b, and the physical node c, and the target physical node is the physical node d. The metadata node determines that the virtual node to be migrated on the physical node a is any one of the four virtual nodes to be migrated, and the virtual node to be migrated on the physical node b is any one of the four virtual nodes that belong to the physical node c. The virtual node to be migrated is any one of the physical nodes to be migrated.

S202. The metadata node sends a migration indication message to the source physical node.

Specifically, the migration indication message is used to indicate that the source physical node performs the migration operation, and the migration indication message may include the identifier of the target physical node and the identifier of the at least one virtual node to be migrated on the source physical node, where the source physical node may determine according to the migration indication message. At least one virtual node to be migrated on the target physical node and the source physical node.

S203. The source physical node acquires data structure information of at least one virtual node to be migrated.

Specifically, the virtual node includes multiple service objects, and the service object is an object that is divided according to a preset division rule. The data set; for example, the object is divided by the client, and the data set of each client is a business object; the data structure information represents the structure of the data on the physical node, and the data structure information specifically includes the mapping relationship between the physical node and the virtual node, and the virtual node The mapping relationship with the business object, the mapping relationship between the business object and the business table, and the data structure information can be maintained by the metadata node. The source physical node obtains all the service objects corresponding to the at least one virtual node to be migrated according to the data structure information, and the source physical node may acquire the data structure information of the at least one virtual node to be migrated to the metadata node.

Referring to FIG. 4a, in a possible implementation manner of this embodiment, the source physical node acquires data structure information of each virtual node in the at least one virtual node, and obtains all service objects according to the data structure information. include:

S401. Obtain a virtual node identifier of at least one virtual node to be migrated.

Specifically, the data on the physical node can be divided into four levels, from top to bottom, respectively, a virtual node, a business object, a service table, and a business record, one virtual node is associated with multiple business objects, and one business object is associated with multiple business tables. a business table stores a plurality of business records; the business object represents a data set to which the objects are divided according to a predefined rule, for example, the objects are divided according to different customers, and each customer is a business object; the objects are divided according to the service type, each The business object is a business object; the business objects are divided according to different orders, each order is a business object; the business table is used to store specific business records. The data structure information can be maintained on the metadata node, and the data structure information represents the data structure of the physical node. The data structure information includes a data fragmentation table, a business object root table, and a business object subsidiary table; the data fragmentation table storage represents the virtual node and the business object. A record of the mapping relationship between the virtual node identifier and the identifier of the business object; the business object root table stores basic information of the business object, for example, when the business object is a data set of a customer, The business object root table stores the customer's personal information; the business object subsidiary table storage represents the mapping relationship between the business object and the business table.

S402. Retrieve the preset data fragment table according to the virtual node identifier to obtain a service object identifier of all the corresponding service objects.

Specifically, the source physical node obtains the data fragmentation table from the metadata node, and retrieves the data fragmentation table by using the virtual node identifier to obtain the business object identifier of all the business objects to which the at least one virtual node to be migrated belongs.

S403. Retrieve a preset business object subsidiary table according to the business object identifier to obtain a business table.

Specifically, the business object subsidiary table defines a mapping relationship between the business object and the business table, and the source physical node retrieves the preset business object subsidiary table according to the business object identifier to obtain the business table.

S404. Retrieve the business record in the business table according to the business object identifier.

For example, as shown in FIG. 4b, it is assumed that at least one virtual node to be migrated is a virtual node 1, and the source physical node acquires a virtual node identifier of the virtual node 1, and retrieves a preset data fragment table according to the virtual node identifier to obtain a virtual The node 1 associates the business object identifier of the business object 11, the business object 12, ..., the business object 1m, and then the source physical node retrieves the preset business object subsidiary table according to the business object identifier to obtain a plurality of related business tables, and the business object 11 is For example, the business object identifier of the searched business object 11 is associated with the business table 111, the business table 112, ..., the business table 11k; then the source physical node can retrieve the corresponding business record in the business table according to the business object identifier of the business object. Taking the service table 111 as an example, the business record 1111, the business record 1112, ..., the business record 111h stored in the service table 111.

S204. The source physical node sends the first service object C1 to the target physical node.

Specifically, after the source physical node determines all the service objects to which the at least one virtual node belongs to be migrated, one of the service objects is selected and sent to the target physical node. The source physical node sets a record table for recording the migration status of the service object. In the initial state, the migration status of all service objects is not migrated. When a service object is successfully migrated to the target physical node, the source physical node will The migration status of the business object is changed to migrated.

S205. The source physical node receives the service access request sent by the client.

Specifically, the operation object of the service access request is one of all the service objects in S203, and the operation type of the service access request may be a read operation or a write operation.

S206. The source physical node generates a service log.

Specifically, the service log includes a service access request, and the source physical node may further add a timestamp or a version number to the service log, so that the target physical node can distinguish the order of service access requests.

S207. The source physical node returns a service access response to the client.

Specifically, the source physical node performs a corresponding operation according to the service access request, and returns a service access response to the client, for example, the operation type of the service access request is a read operation, the service access response carries the read data, and the service access request is operated. When the type is a write operation, the service access response carries write status information, and the write status information is used to indicate whether the write operation is successful.

S208. The source physical node sends a service log to the target physical node.

Specifically, the source physical node sends a service log to the target physical node, and the target physical node caches the received service log. It should be noted that the source physical node may generate a service log every time a service access request is received, and send the service log to the target physical node, or the source physical node receives a service access request to generate a service log, and the generated service is generated. The log is cached. After all the business objects are migrated, all the cached service logs are sent to the target physical node.

S209. The source physical node sends the last service object to the target physical node.

Specifically, the number of the service objects corresponding to the at least one virtual node to be migrated is n, and the source physical node may count the migrated service objects, and the value of each service object is incremented by one, and the count value is equal to all the service objects. When the quantity is n, it indicates that all business objects migrate successfully.

S210, virtual node reconstruction and service replay.

Specifically, the target physical node receives the service object sent by the source physical node, and after the source physical node sends all the service objects to be migrated, the source physical node may send a migration completion message to the target physical node, and the migration completion message indicates that the source physical node is to be migrated. All the service objects are sent; after the target physical node determines that all the service objects to be migrated on the source physical node are sent, the data structure information of the source physical node can be obtained from the metadata node, and the target physical node receives the data according to the data structure information. All the business objects that arrive are reorganized to obtain the at least one virtual node. At the same time, the target physical node may perform service replay according to the cached service log after the indication of the source physical node or the indication of the metadata node, and the target physical node performs log replay according to the timestamp or version number carried in the log file to make the target physical node The execution order of the upper service access request is consistent with the source physical node. In the process of performing service replay, if the operation type of the service access request is a read operation, the service access request may be skipped. For example, the service log cached by the target physical node includes: service log 1, service log 2, service log 3, and service log 4. The service access request recorded in service log 1 is modified user information, and the version number of the record is 1.0; The service access request recorded in 2 is the modified charging type, and the recorded version number is 1.1; the service access request recorded in the service log 3 is the read consumption record, and the recorded version number is 1.2; the service access request recorded in the service log 4 To modify the user balance, the version number of the record is 1.3. It is assumed that the record number of the version number is incremented according to the sequence, and the service log with a larger version number is newer than the service log with a smaller version number. When the target physical node performs service replay according to the above four service logs, the service log 1 and the service log are used. 2. The service replay is performed in the order of service log 3 and service log 4.

S211. The source physical node sends a migration complete message to the metadata node.

Specifically, when the source physical node migrates all the service objects to which the at least one virtual node to be migrated belongs, A migration completion message is sent to the metadata node. The migration completion message indicates that all the business objects to be migrated on the source physical node are migrated.

S212. The metadata node sends a handover indication message to the source physical node.

The handover indication message is used to indicate that the source physical node performs route switching.

S213. The source physical node blocks the requested transaction, and waits for the started transaction to complete.

Specifically, after receiving the handover indication message, the source physical node blocks the transaction requested by the client, and the transaction includes multiple service access requests, and the transaction has the characteristics of integrity. After all the service access requests included in the transaction are successfully executed, the transaction is completed. It is considered that the execution is successful. When any one or more business operation requests included in the transaction are not successfully executed, the transaction needs to be rolled back, and multiple service access requests included in the transaction are re-executed; the source physical node determines that there is a startup. A transaction, and a transaction that has started is not successfully executed, waiting for the execution of the started transaction to complete.

S214. The source physical node returns a handover preparation message to the metadata node.

Specifically, after the execution of the started transaction is completed, the source physical node returns a handover preparation message to the metadata node, where the handover preparation message indicates that the source physical node has completed the route switching preparation.

In a possible implementation manner of the present application, the source physical node may block the transaction requested by the client after all the service nodes to which the at least one virtual node to be migrated is sent, and the source physical node determines to perform the executed transaction. After completion, the handover preparation message is sent to the metadata node, and the handover preparation message is used to indicate that the source physical node is ready for route switching to ensure the integrity of the transaction.

The source physical node may send a handover preparation message to the target physical node, and after receiving the handover preparation message, the target physical node performs service replay according to the cached service log, and the target physical node may obtain the information from the metadata node after the service replay is completed. A physical node of the source physical node, the target physical node sends the cached service log to the physical node of the replica, and the physical node of the replica performs service replay on at least one virtual node according to the service log.

S215. The metadata node sends a route switching message to the client.

Specifically, when receiving the handover preparation message, the metadata node confirms that the source physical node is prepared as a route switch, and the metadata node acquires the identifier of the target physical node and the identifier of the at least one virtual node to be migrated, and the metadata node sends a route to the client. The switching message is used to indicate that the client updates the physical node where the at least one virtual node is located, and the routing switch message carries the identifier of the at least one virtual node to be migrated and the identifier of the target physical node.

S216. The client sends a service access request to the target physical node.

Specifically, the client receives the routing switch message, and changes the mapping relationship between the at least one virtual node and the source physical node to the mapping relationship between the at least one virtual node and the target physical node, and the client sends the service object to the service object to which the at least one virtual node belongs. When requested, the service access request is sent to the target physical node according to the changed mapping relationship.

S217. The target physical node returns a service access response to the client.

Specifically, the target physical node receives the service access request, performs a corresponding operation according to the service access request, and returns a service access response to the client.

S218. The metadata node sends an offline notification message to the source physical node.

Specifically, the offline notification message is used to clean at least one virtual node in the source physical node, and the offline notification message may carry the identifier of the at least one virtual node.

Referring to FIG. 4c, a data migration method of a virtual node is described below in a specific embodiment:

Under the initial conditions, the distributed database system includes four physical nodes, which are physical node 1, physical node 2, physical node 3, and physical node 4. Each physical node includes 12 virtual nodes, and each virtual node has 1 deployed. Copy, the number in the brackets below is the table of the virtual node, the two virtual nodes of the same number are the master and the copy, which can also be called The primary node and the standby node (or primary or backup fragment), the mapping relationship between the physical node and the virtual node is as follows:

Physical node 1: (1, 2, 3, 4, 5, 6), (9, 12, 14, 17, 19, 22)

Physical node 2: (7, 8, 9, 10, 11, 12), (1, 4, 15, 18, 20, 23)

Physical node 3: (13,14,15,16,17,18), (2,5,7,10,21,24)

Physical node 4: (19, 20, 21, 22, 23, 24), (3, 6, 8, 11, 13, 16)

As the business develops, the current four physical nodes are overloaded and plans to expand a new physical node5. The data equalization subsystem of the metadata node calculates that it is necessary to separately migrate the physical node 1. virtual node 1, physical node 2. virtual node 7, physical node 3. virtual node 13, physical node 4. virtual node 19 to physical node 5. The physical node 1. virtual node 1, physical node 2. virtual node 7, physical node 3. virtual node 13, physical node 4. virtual node 19 are sequentially traversed. Physical nodes 1-4 are source physical nodes, and physical nodes 5 are target physical nodes.

The structure of the data fragmentation table is defined as

{

Data_node_id int, / / physical node ID

Vnode_id int, / / virtual node ID

startHashkey int, / / record the starting hash value of the virtual node

endHashkey int, / / record the end hash value of the virtual node

Is_primary bool// whether this is the main

}

Taking the migration of the virtual node 1 for the physical node 1 as an example: the physical node 1 performs conditional retrieval by using the virtual node identifier Vnode_id=1 in the data fragmentation table as an index, and obtains the identifier of all the business objects under the virtual node 1, and the business object The identifier can be represented by a hash value. The identifier of all business objects is a list of hash value ranges. It is assumed that the hash value range of all business objects is (O1, O2, O3, O4, O5); then physical node 1 is for each business object. The Hash value traverses the root table of the business object, obtains the root table information of the business object, and retrieves the associated business table by using the hash value of the business object according to the preset business object subsidiary table, where the business table stores multiple business records and physical nodes. After the service object to which the virtual node 1 to be migrated belongs is determined, the service object of the virtual node 1 is migrated to the physical node 5 to form a baseline replication. During the migration process, if an exception occurs, re-migrate and clean the physical node 5. Virtual node 1 is re-migrated by physical node 1. Virtual node 1. During the migration of the business object, the client can continue to access the physical node 1. Virtual node 1, physical node node 1. Virtual node 1 performs a service access request and returns a service access response, physical node 1. The service that virtual node 1 will generate The log is sent to the physical node 5, and the physical node 5 caches the service log. The physical node 1. After the migration of all the business objects is completed, the physical node 5 replays the service according to the cached service log. After determining that all the service objects are sent, the physical node 1 blocks the transaction initiated by the client. Due to the characteristics of the transaction integrity, the physical node 1 waits for the started transaction to complete, and then sends a handover preparation message to the metadata node. After receiving the handover preparation message, the node sends a routing switch message to the client, where the routing switch message is used to instruct the client to update the mapping relationship between the virtual node 1 and the physical node 1 to the mapping relationship between the virtual node 1 and the physical node 5. For the migration process of the finder node 7 of the physical node 2, the virtual node 13 of the physical node 3, and the virtual node 19 of the physical node 4, reference may be made to the above description, and details are not described herein again. The gray squares in Figure 4c represent migrated virtual nodes. When

virtual nodes

1, 7, 13, and 19 are migrated to physical node 5, replicas need to be deployed on physical nodes 5, and the rules for anti-affinity are followed when deploying replicas. That is, the master and the copy cannot be on the same physical node.

In the method described in FIG. 2, the data structure information of the virtual node to be migrated by the source physical node acquires the business object to be migrated according to the data structure information, migrates all the business objects to the target physical node, and implements relational data. Logical migration.

Referring to FIG. 3, FIG. 3 is a schematic flowchart of still another method for data migration of a virtual node according to an embodiment of the present invention, where the method includes but is not limited to the following steps.

S301. The metadata node detects that the migration condition is met.

Specifically, the distributed database system includes multiple physical nodes, and the migration conditions include, but are not limited to, adding a physical node, deleting a physical node, not satisfying a load balancing condition, or failing to satisfy a data balancing condition.

S302: Synchronize metadata between the metadata node and the client.

The metadata synchronization parameter is required between the metadata node and the client. The metadata includes but is not limited to the mapping relationship between the physical node and the virtual node, the storage location of the virtual node and the copy, and the data balancing condition.

S303. The metadata node sends a migration indication message.

Specifically, the metadata node sends the migration indication message to the source physical node and the target physical node, and triggers migration of the service object on the source physical node. At the same time, the metadata node sends a migration indication message to each replica physical node of the source physical node.

S304. The source physical node acquires data structure information of at least one virtual node to be migrated.

Specifically, the virtual node includes multiple service objects, and the business object is a data set of objects divided according to a preset division rule. For example, the object is divided by a client, and each customer's data set is a business object; the data structure information is represented. The structure of the data on the physical node, the data structure information specifically includes the mapping relationship between the physical node and the virtual node, the mapping relationship between the virtual node and the business object, the mapping relationship between the business object and the service table, and the data structure information can be maintained by the metadata node. The source physical node obtains all the service objects corresponding to the at least one virtual node to be migrated according to the data structure information, and the source physical node may acquire the data structure information of the at least one virtual node to be migrated to the metadata node.

Among them, during the migration, the master-slave replication between the source physical node and the replica physical node is suspended. The reason for suspending master-slave replication is that during the migration process, online service concurrency is still supported. The service data before and after the migration of the same virtual node accesses different physical nodes (source physical node and target physical node). During the migration, the replica data and It is more difficult to keep the master data consistent.

S305. The source physical node performs locking processing on the service object to be migrated.

Specifically, the source physical node selects a business object to be migrated from all the business objects, and locks the business object to be migrated. After the lock processing, the business object to be migrated cannot be modified, that is, the business object to be migrated. The operation can only be a read operation and cannot be a write operation.

S306. The source physical node sends the service object to be migrated to the target physical node.

Specifically, the source physical node selects one business object from all the business objects to be migrated to migrate to the target physical node.

S307. The source physical node deletes the service object to be migrated.

Specifically, the source physical node deletes the service object to be migrated after the service object to be migrated is sent to the target physical node.

S308. The client sends a service access request to the source physical node.

Specifically, in the migration process of the business object, the client sends a service access request to the source physical node for the business object to be accessed, and the business object accessed by the service access request is one of all the business objects.

S309. The source physical node determines whether the service object to be accessed has been migrated.

Specifically, the source physical node maintains a state table of a business object, and the state table stores a service object for representing the business object. The state of the service object is classified as migrated and not migrated. The source physical node can query whether the status of the service object to be accessed is migrated or not migrated according to the pre-stored state table. If the source physical node directly responds to the service access request, the service access response is returned to the client. If the status of the service object to be accessed is migrated, S310 is performed.

S310. The source physical node returns a route change message to the client.

Specifically, the source physical node returns a route change message to the client when the to-be-accessed service object has been migrated, and the route change message indicates that the physical node where the service object to be accessed is changed, and the route update message may carry the target physical node. Logo.

S311. The client sends a service access request to the target physical node again.

Specifically, the client receives the routing update message, obtains the identifier of the target physical node according to the routing update message, and sends a service access request to the target physical node again.

S312. The client receives a service access response returned by the target physical node.

Specifically, the target physical node receives the service access request sent by the client for the service object to be accessed, and the target physical node performs the service access request and returns the service to the client because the service object to be accessed has been successfully migrated to the target physical node. In response to the response, the client receives the service access response returned by the target physical node.

S313. The source physical node sends a migration complete message to the metadata node.

Specifically, the source physical node determines that all the service objects to be migrated are migrated, and sends a migration completion message to the metadata node, where the source physical node can count the successfully transferred business objects, and each time the service object is migrated, the count value is increased by one. When the count value is equal to the number of all business objects to be migrated, it is determined that all the business objects to be migrated are migrated.

S314. The metadata node sends a route switching message to the client.

Specifically, the routing switch message indicates that the physical node where the virtual node is located is updated, and the routing switch message may carry the identifier of the at least one virtual node and the identifier of the target physical node, and the client receives the routing update message, and at least one virtual according to the routing update message The node is mapped to the target physical node.

S315. The metadata node sends an offline notification message to the source physical node.

Specifically, the offline notification message is used to notify the virtual node to go offline. The offline notification message may carry the identifier of the at least one virtual node, and the source physical node receives the offline notification message, and the at least one virtual node may be deleted according to the message notification message.

Under the initial conditions, the distributed database system includes four physical nodes, which are physical node 1, physical node 2, physical node 3, and physical node 4. Each physical node includes 12 virtual nodes, and each virtual node has 1 deployed. A copy of the virtual node is numbered in the parentheses below. The two virtual nodes of the same number are the master and the copy. They can also be called the primary node and the standby node (or the primary or backup slice) physical node. The mapping relationship with the virtual node is as follows:

Physical node 1: (1, 2, 3, 4, 5, 6), (9, 12, 14, 17, 19, 22)

Physical node 2: (7, 8, 9, 10, 11, 12), (1, 4, 15, 18, 20, 23)

Physical node 3: (13,14,15,16,17,18), (2,5,7,10,21,24)

Physical node 4: (19, 20, 21, 22, 23, 24), (3, 6, 8, 11, 13, 16)

As the business develops, the current four physical nodes are overloaded and plans to expand a new physical node5. The data equalization subsystem of the metadata node calculates that it is necessary to separately migrate the physical node 1. virtual node 1, physical node 2. virtual node 7, physical node 3. virtual node 13, physical node 4. virtual node 19 to physical node 5. Traverse the physical node in turn. 1. Virtual Node 1, physical node 2. Virtual node 7, physical node 3. Virtual node 13, physical node 4. Virtual node 19. Physical nodes 1-4 are source physical nodes, and physical nodes 5 are target physical nodes.

For example, the physical node 1. The migration of the virtual node 1 is taken as an example. For the method for obtaining the service object to which the virtual node 1 belongs, reference may be made to the description of the embodiment of FIG. 2, and details are not described herein again.

The migration process is: traversing the physical node 1. All the business objects under the virtual node 1: business object 1, business object 2, business object 3, business object 4, and business object 5, assuming that the order of migration is one for each of the business objects 1-5 Migration, suspend physical node 1. Master-slave replication between virtual node 1 and replica physical node; physical node 1 locks business object 1 and migrates physical node 1. virtual node 1. business object 1 to physical node 5. virtual Node 1, then cleans up the physical node 1. Virtual node 1. Business object 1; loop processing, and then relocate business object 2, business object 3, business object 4, and business object 5 to physical node 5. virtual node 1.

During the migration of the business object, the client initiates a service access request to the physical node 1. virtual node 1. business object 1, and the physical node 1 (the source physical node) determines that the business object 1 has been migrated, and returns a routing update message to the client; The client update routing update message re-initiates a service access request to the physical node 5. virtual node 1. For the migration process of the virtual node 7 of the physical node 2, the virtual node 13 of the physical node 3, and the virtual node 19 of the physical node 4, reference may be made to the above description, and details are not described herein again. The gray squares in Figure 4c represent migrated virtual nodes. When

virtual nodes

In the method described in FIG. 3, the data structure information of the virtual node to be migrated by the source physical node acquires the business object to be migrated according to the data structure information, migrates all the business objects to the target physical node, and implements the logic of the relational data. migrate.

FIG. 5 is a schematic structural diagram of a physical node according to an embodiment of the present invention. The physical node used in the embodiment of the present invention is used to perform the data migration method of the virtual node in FIG. 2, and the terminology and process involved may refer to the diagram. 2 Description of the embodiment. The physical node 5 includes a receiving module 501, a determining module 502, an obtaining module 503, and a migration module 504.

a receiving module, configured to receive a migration indication message;

a determining module, configured to determine, according to the migration indication message, a target physical node and at least one virtual node to be migrated on the source physical node;

An acquiring module, configured to acquire data structure information of the source physical node itself, and obtain, according to the data structure information, all service objects to which the at least one virtual node belongs;

And a migration module, configured to migrate the all business objects to the target physical node at a granularity of the business object.

Optionally, the data structure information includes a data fragment table and a data attachment table;

The obtaining module is used to:

Querying, according to the data fragmentation table, one or more business objects to which the at least one virtual node belongs, and querying, according to the business object auxiliary table, a service table to which each of the plurality of business objects belongs.

Optionally, it also includes:

Recording the service access request into a service log, and transmitting the service log to the target physical node.

Optionally, it also includes:

And in the case that the initiated transaction is successfully executed, returning a handover preparation message to the metadata node; wherein the handover preparation message is used to indicate that the source physical node completes route switching preparation.

Optionally, the migration module is configured to:

Selecting a business object to be migrated from all the business objects, and locking the business object to be migrated;

Optionally, the physical node further includes:

a second access processing module, configured to receive, during a migration process of the business object, a service access request sent by the client for the service object to be accessed;

Determining whether the to-be-accessed business object has migrated to the target physical node;

If yes, returning a routing update message to the client, where the routing update message is used to instruct the client to update the physical node where the to-be-accessed business object is located.

Optionally, it also includes:

And a notification module, configured to send a migration completion message to the metadata node when the business object migration is completed; wherein the migration completion message is used to indicate that all the business objects to which the at least one virtual node belongs are migrated.

The embodiment of the present invention and the embodiment of FIG. 2 are based on the same concept, and the technical effects thereof are also the same. For the specific process, reference may be made to the description of the embodiment of FIG. 2, and details are not described herein again.

FIG. 6 is a schematic structural diagram of a physical node according to an embodiment of the present invention. In the embodiment of the present invention, the physical node 6 includes a processor 601, a memory 602, and a transceiver 603. The transceiver 603 is configured to transmit and receive data with and from an external device. The number of processors 601 in the physical node 6 may be one or more. In some embodiments of the invention, processor 601, memory 602, and transceiver 603 may be connected by a bus system or other means. The physical node 6 can be used to perform the method shown in FIG. 2. For the meaning and examples of the terms involved in the embodiment, reference may be made to the corresponding embodiment of FIG. 2. I will not repeat them here.

The program code is stored in the memory 602. The processor 601 is configured to call the program code stored in the memory 602 for performing the following operations:

Receiving a migration indication message;

Determining, according to the migration indication message, the target physical node and the at least one virtual node to be migrated on the source physical node;

Obtaining data structure information of the source physical node, and obtaining, according to the data structure information, all service objects to which the at least one virtual node belongs;

All of the business objects are migrated to the target physical node at a granularity of business objects.

The processor 601 performs, according to the data structure information, all the service objects to which the at least one virtual node to be migrated belongs:

Querying, according to the data fragmentation table, one or more business objects to which the at least one virtual node belongs, and a root And querying, according to the business object subsidiary table, a service table to which each of the plurality of business objects belongs.

In a possible implementation, the processor 601 is further configured to:

Receiving a client to send a service access request;

In a possible implementation, the processor 601 is further configured to:

Sending a migration completion message to the metadata node when the business object migration is completed;

Receiving, by the source physical node, a handover indication message returned by the metadata node according to the migration completion message;

Upon receiving the handover indication message, the source physical node blocks a transaction initiated by the client;

And the source physical node returns a handover preparation message to the metadata node, where the handover preparation message is used to indicate that the source physical node completes route switching preparation.

In a possible implementation manner, the processor 601 performing the migrating the all service objects to the target physical node at a granularity of a service object includes:

In a possible implementation, the processor 601 further includes:

Receiving a service access request sent by the client for a service object to be accessed during a migration process of the business object;

In a possible implementation, the processor 601 is further configured to:

When the migration of the business object is completed, the migration completion message is sent to the metadata node, where the migration completion message is used to indicate that all the business objects to which the at least one virtual node belongs are migrated.

FIG. 7 is a schematic structural diagram of a physical node according to an embodiment of the present invention. The physical node in the embodiment of the present invention is used to perform the data migration method of the virtual node in FIG. 3, and the terminology and process may refer to FIG. 3 . Description of the embodiments. The physical node 7 includes a determination module 701, a receiving module 702, and a reconstruction module 703.

a determining module 701, configured to receive a migration indication message, and determine a source physical node according to the migration indication message;

The receiving module 702 is configured to receive a service object sent by the source physical node.

The reconstruction module 703 is configured to acquire data structure information of the received service object when the migration of the service object of the source physical node is completed, and reconstruct the virtual node according to the data structure information.

Optionally, the physical node 7 further includes:

a data backup module, configured to determine a target when the service log transmission on the source physical node is completed The replica physical node migrates the stored service log and the virtual node to the target replica physical node.

The embodiment of the present invention and the embodiment of FIG. 3 are based on the same concept, and the technical effects thereof are also the same. For the specific process, reference may be made to the description of the embodiment of FIG. 3, and details are not described herein again.

FIG. 8 is a schematic structural diagram of a physical node according to an embodiment of the present invention. In the embodiment of the present invention, the physical node 8 includes a processor 801, a memory 802, and a transceiver 803. The transceiver 803 is configured to transmit and receive data with and from an external device. The number of processors 801 in the physical node 7 may be one or more. In some embodiments of the invention, processor 801, memory 802, and transceiver 803 may be coupled by a bus system or other means. The physical node 8 can be used to perform the method shown in FIG. For the meaning and examples of the terms involved in the embodiment, reference may be made to the corresponding embodiment of FIG. 3. I will not repeat them here.

The program code is stored in the memory 802. The processor 801 is configured to call program code stored in the memory 802 for performing the following operations:

Receiving a migration indication message, and determining a source physical node according to the migration indication message;

Receiving a service object sent by the source physical node;

After determining that the migration of the service object of the source physical node is completed, acquiring data structure information of the received service object, and reconstructing the virtual node according to the data structure information.

In a possible implementation, the processor 801 is further configured to:

The target physical node receives the service log sent by the source physical node, and performs service replay according to the service log. The service log includes a service access request.

In a possible implementation, the processor 801 is further configured to:

When it is determined that the service log transmission on the source physical node is completed, the target replica physical node is determined, and the stored service log and the virtual node are migrated to the target replica physical node.

A person skilled in the art can understand that all or part of the process of implementing the above embodiment method can be completed by a computer program to instruct related hardware, and the program can be stored in a computer readable storage medium. When executed, the flow of an embodiment of the methods as described above may be included. The foregoing storage medium includes various media that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

The above embodiments are only illustrative of the preferred embodiments of the present invention, and the scope of the present invention is not limited thereto, and those skilled in the art can understand all or part of the processes for implementing the above embodiments, and according to the claims of the present invention. Equivalent changes are still within the scope of the invention.

Claims

A data migration method for a virtual node, comprising:

The source physical node receives the migration indication message;

Determining, by the source physical node, the target physical node and the at least one virtual node to be migrated on the source physical node according to the migration indication message;

Obtaining data structure information of the source physical node itself, and obtaining, according to the data structure information, all service objects to which the at least one virtual node belongs;

The source physical node migrates all the business objects to the target physical node at a granularity of the business object.
The method of claim 1 wherein said data structure information comprises a data fragmentation table and a data attachment table;

And obtaining, according to the data structure information, all the service objects to which the at least one virtual node to be migrated belongs:

Querying, by the source physical node, one or more business objects to which the at least one virtual node belongs according to the data fragmentation table, and querying, according to the business object auxiliary table, each of the plurality of business objects Business table.
The method of claim 1 or 2, further comprising:

Receiving, by the source physical node, a client to send a service access request;

The source physical node performs a service access request, and returns a service access response to the client;

The source physical node records the service access request into a service log, and sends the service log to the target physical node.
The method of claim 3, further comprising:

In the case that the business object migration is completed, the source physical node sends a migration completion message to the metadata node;

Receiving, by the source physical node, a handover indication message returned by the metadata node;

Upon receiving the handover indication message, the source physical node blocks a transaction initiated by the client;

And the source physical node returns a handover preparation message to the metadata node, where the handover preparation message is used to indicate that the source physical node completes route switching preparation.
The method of claim 1, wherein the migrating the all the business objects to the target physical node by the source physical node at a granularity of the business object comprises:

The source physical node selects a business object to be migrated from all the service objects, and performs locking processing on the business object to be migrated;

When the source physical node confirms that the service object to be migrated is successfully migrated to the target physical node, the service object to be migrated is deleted.
The method of claim 5, further comprising:

During the migration of the business object, the source physical node receives a service access request sent by the client for the service object to be accessed;

Determining, by the source physical node, whether the to-be-accessed service object has migrated to the target physical node;

If yes, the source physical node returns a route update message to the client, where the route update message is used to instruct the client to update the physical node where the to-be-accessed service object is located.
The method of claim 6 further comprising:

When the business object migration is completed, the source physical node sends a migration completion message to the metadata node; The migration completion message is used to indicate that all the business objects to which the at least one virtual node belongs are migrated.
A data migration method for a virtual node, comprising:

Receiving, by the target physical node, a migration indication message, and determining a source physical node according to the migration indication message;

Receiving, by the target physical node, a service object sent by the source physical node;

After determining that the migration of the service object of the source physical node is completed, acquiring data structure information of the received service object, and reconstructing the virtual node according to the data structure information.
The method of claim 8 further comprising:

The target physical node receives the service log sent by the source physical node, and performs service replay according to the service log. The service log includes a service access request.
The method of claim 9 further comprising:

When the target physical node determines that the service log transmission on the source physical node is complete, the target replica physical node is determined, and the stored service log and the virtual node are migrated to the target replica physical node.
A physical node, wherein the physical node is a source physical node, and the source physical node includes:

a receiving module, configured to receive a migration indication message;

a determining module, configured to determine, according to the migration indication message, a target physical node and at least one virtual node to be migrated on the source physical node;

An acquiring module, configured to acquire data structure information of the source physical node itself, and obtain, according to the data structure information, all service objects to which the at least one virtual node belongs;

And a migration module, configured to migrate the all business objects to the target physical node at a granularity of the business object.
The physical node according to claim 11, wherein the data structure information comprises a data fragmentation table and a data attachment table;

The obtaining module is used to:

Querying, according to the data fragmentation table, one or more business objects to which the at least one virtual node belongs, and querying, according to the business object auxiliary table, a service table to which each of the plurality of business objects belongs.
The physical node according to claim 11 or 12, further comprising:

a first access processing module, configured to receive a client to send a service access request;

Performing a business access request and returning a business access response to the client;

Recording the service access request into a service log, and transmitting the service log to the target physical node.
The physical node of claim 13, further comprising:

a transaction processing module, configured to send a migration completion message to the metadata node when the business object migration is completed;

Receiving a handover indication message returned by the metadata node according to the migration completion message;

Blocking the transaction initiated by the client when receiving the handover indication message;

And in the case that the initiated transaction is successfully executed, returning a handover preparation message to the metadata node; wherein the handover preparation message is used to indicate that the source physical node completes route switching preparation.
The physical node according to claim 11, wherein the migration module is configured to:

Selecting a business object to be migrated from all the business objects, and locking the business object to be migrated;

When the business object to be migrated is successfully migrated to the target physical node, the business object to be migrated is deleted.
The physical node of claim 15 further comprising:

a second access processing module, configured to receive, during a migration process of the business object, a service access request sent by the client for the service object to be accessed;

Determining whether the to-be-accessed business object has migrated to the target physical node;

If yes, returning a routing update message to the client, where the routing update message is used to instruct the client to update the physical node where the to-be-accessed business object is located.
The physical node according to claim 16, further comprising:

And a notification module, configured to send a migration completion message to the metadata node when the business object migration is completed; wherein the migration completion message is used to indicate that all the business objects to which the at least one virtual node belongs are migrated.
A physical node, wherein the physical node is a target physical node, and the target physical node includes:

a determining module, configured to receive a migration indication message, and determine a source physical node according to the migration indication message;

a receiving module, configured to receive a service object sent by the source physical node;

And a reconstruction module, configured to acquire data structure information of the received service object when the migration of the business object of the source physical node is completed, and reconstruct the virtual node according to the data structure information.
The physical node of claim 18, further comprising:

The service recovery module is configured to receive a service log sent by the source physical node, and perform service replay according to the service log. The service log includes a service access request.
The physical node of claim 19, further comprising:

And a data backup module, configured to determine that the target replica physical node is complete, and the stored service log and the virtual node are migrated to the target replica physical node.