Dynamic library splitting method for data system and device thereof

Abstract

The application provides a dynamic database splitting method and device of a data system, comprising the following steps: synchronizing data of an old cluster to a new cluster according to an event trace source mode; judging whether the data is synchronized; if yes, sending a data synchronization completion message to a coordinator; the coordinator sending a database splitting command to the old cluster according to the data synchronization completion message; executing the database splitting command and updating configurations of the old cluster and the new cluster; judging whether the old cluster and the new cluster complete the database splitting; if yes, feeding back the result to the coordinator respectively. The application can reduce the long system downtime caused by database splitting, so that the whole database splitting process does not affect the business system and reduces the business loss.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a dynamic database partitioning method and apparatus for a data system. Background Technology

[0002] With the explosive growth of business data, the performance of a single database can no longer meet the demand, requiring the splitting of multiple databases to share the load. However, the existing database sharding method first suspends the business to avoid the impact of human operation on the system, then backs up the system database to prevent the rollback of all operations in case of operational errors, and finally distributes the data to various machines according to the predetermined logic and restarts the system. However, this database sharding method will cause the system to be suspended for a long time, resulting in significant business losses. Summary of the Invention

[0003] This invention aims to solve the problem that the existing database sharding methods cause long system downtime and significant business losses, and provides a dynamic database sharding method and apparatus for a data system.

[0004] This invention provides a dynamic database sharding method for a data system, comprising the following steps:

[0005] Synchronize data from the old cluster to the new cluster based on the event tracing pattern;

[0006] Determine whether the data synchronization is complete;

[0007] If so, a data synchronization completion message is sent to the coordinator, and the coordinator sends a database sharding command to the old cluster based on the data synchronization completion message;

[0008] Execute the database sharding command and update the configuration of the old cluster and the new cluster;

[0009] Determine whether the old cluster and the new cluster have completed database sharding;

[0010] If so, the results will be fed back to the coordinator respectively.

[0011] Furthermore, the step of synchronizing data from the old cluster to the new cluster based on the event sourcing pattern includes:

[0012] Send a synchronization data command to the new cluster;

[0013] The timestamp is obtained by retrieving snapshot files from the old cluster.

[0014] Furthermore, the step of determining whether the data synchronization is complete includes:

[0015] The timestamp is compared with the local time to obtain the time difference;

[0016] When the time difference is within the range of 1s-9s, the data synchronization is considered complete.

[0017] Furthermore, the step of executing the database sharding command and updating the configurations of the old cluster and the new cluster includes:

[0018] Insert the database sharding command into the command queue of the old cluster;

[0019] The database sharding command is sent to the first automaton using a consensus algorithm;

[0020] The first automaton executes the database splitting command and obtains a first output program and a second output program. The first output program does not process non-class messages, and the second output program sends the database splitting completion message to the coordinator.

[0021] The completed database segmentation message is recorded in the local database.

[0022] Furthermore, after the step of storing the completed database message to the local database, the following steps are included:

[0023] Determine whether the old cluster has received the non-class message;

[0024] If so, an error status message and redirection prompt are sent to the user to obtain the location of the old cluster.

[0025] Furthermore, the step of executing the database sharding command and updating the configuration of the new cluster includes:

[0026] The database splitting command is executed by the second automaton, and a first processing program and a second processing program are obtained. The first processing program processes the class-related messages and sends the non-class-related messages to the user terminal. The second processing program sends the database splitting completion message to the coordinator.

[0027] Update the local database.

[0028] Furthermore, after the step of updating the local database, the following steps are included:

[0029] Determine whether the new cluster has received the non-class message;

[0030] If so, an error status message and a redirection prompt are sent to the user terminal to obtain the new cluster location.

[0031] Furthermore, if so, the step of feeding back the result to the coordinator further includes:

[0032] The database sharding command is analyzed to obtain database sharding information, wherein the database sharding information includes new database data;

[0033] The database partitioning information is sent to the server to obtain the location of the new database.

[0034] The present invention also provides a dynamic database sharding device for a data system, comprising:

[0035] The data synchronization module is used to synchronize data from the old cluster to the new cluster based on the event sourcing mode;

[0036] The first judgment module is used to determine whether the data synchronization is complete;

[0037] The first transmission module is used to send a data synchronization completion message to the coordinator, and the coordinator sends a database splitting command to the old cluster according to the data synchronization completion message.

[0038] The execution module is used to execute the database sharding command and update the configuration of the old cluster and the new cluster;

[0039] The second judgment module is used to determine whether the old cluster and the new cluster have completed database sharding.

[0040] The first feedback module is used to feed back the results to the coordinator if the condition is met.

[0041] This invention provides a dynamic database sharding method and apparatus for a data system, which has the following beneficial effects:

[0042] It can reduce system downtime caused by database sharding while distributing database pressure, so that the entire sharding process will not affect the business system and reduce business losses. Attached Figure Description

[0043] Figure 1 This is a schematic diagram illustrating the method steps of a dynamic database partitioning method for a data system according to the present invention;

[0044] Figure 2 This is a structural block diagram of a dynamic database partitioning device for a data system according to the present invention;

[0045] Figure 3 This is a schematic diagram illustrating the steps before database partitioning in one embodiment of a dynamic database partitioning method for a data system according to the present invention;

[0046] Figure 4 This is a schematic diagram of the old cluster database sharding process in one embodiment of a dynamic database sharding method for a data system according to the present invention;

[0047] Figure 5This is a schematic diagram of the new cluster database sharding process in one embodiment of a dynamic database sharding method for a data system according to the present invention.

[0048] Explanation of markings: Data synchronization module 10, first judgment module 20, first transmission module 30, execution module 40, second judgment module 50, first feedback module 60. Detailed Implementation

[0049] It should be understood that the specific embodiments described herein are merely for explaining the invention and are not intended to limit the invention.

[0050] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0051] Reference Appendix Figure 1 A dynamic database sharding method for a data system according to one embodiment of the present invention includes:

[0052] S1, synchronize the data from the old cluster to the new cluster according to the event sourcing mode;

[0053] S2, determine whether data synchronization is complete;

[0054] S3, if so, then send a data synchronization complete message to the coordinator, and the coordinator sends a database sharding command to the old cluster based on the data synchronization complete message;

[0055] S4 executes the database sharding command and updates the configurations of the old and new clusters;

[0056] S5 determines whether the old and new clusters have completed database sharding;

[0057] S6, if so, then the results will be fed back to the coordinator respectively.

[0058] In the above steps, before database sharding, this invention includes three nodes: an old cluster, a new cluster, and a coordinator. Data from the old cluster is synchronized to the new cluster using an event sourcing mode. This event sourcing mode records defined events in the order they occur. In one specific embodiment, data from the old cluster is synchronized to the new cluster in the order of event occurrence. Then, it is determined whether data synchronization is complete in the new cluster. If synchronization is complete, the new cluster sends a data synchronization completion message to the coordinator, which then sends a database sharding command to the old cluster. Specifically, the coordinator sends a start database sharding message to the old cluster. During data synchronization, the coordinator continuously queries the new cluster to check if data synchronization is complete. During database sharding, the old cluster executes the sharding command upon receiving it and updates its internal configuration. The new cluster updates its internal configuration upon receiving the sharding command. In one specific embodiment, the old cluster updates its internal configuration by not processing non-class messages. It then determines whether the old and new clusters have completed database sharding. After the old cluster completes sharding, it sends the sharding result back to the coordinator. Similarly, after the new cluster completes sharding, it sends the result back to the coordinator. The entire sharding process is initiated by the coordinator, with the old cluster as the sender. During the sharding process, the coordinator does not actively send commands to the new cluster. The old cluster remains online throughout the sharding process, thus continuously processing business logic in real time. The entire process is uninterrupted, ensuring that the sharding process does not impact the business system. The coordinator only sends sharding commands to the old cluster and then waits for feedback from both the new and old clusters. This process has minimal business-related impact, reducing business losses.

[0059] Reference Appendix Figure 3 In one embodiment, the step of synchronizing data from the old cluster to the new cluster according to the event sourcing pattern includes:

[0060] Send a data synchronization command to the new cluster;

[0061] The timestamp is obtained by retrieving snapshot files from the old cluster.

[0062] In practical implementation, the event sourcing mode records the defined events in the order they occur. In one specific embodiment, the data of the old cluster is synchronized to the new cluster in the order of the events. After sending a data synchronization command to the new cluster, the new cluster obtains a snapshot file from the old cluster. The snapshot file is a usable copy file of a specified data set, including the time point at which the copy begins. The timestamp is the time point. In one specific embodiment, the copy start time point of the snapshot file is 9:40:23, so the timestamp is 9:40:23, that is, 9:40:23.

[0063] Reference Appendix Figure 3In one embodiment, the step of determining whether data synchronization is complete includes:

[0064] Compare the timestamp with the local time to obtain the time difference;

[0065] When the time difference is within the range of 1s-9s, the data synchronization is considered complete.

[0066] In practice, the timestamp and local time are compared to determine whether the new cluster has completed data synchronization. Since the old cluster is continuously processing new business, the new cluster will always experience data synchronization delays, meaning complete synchronization is not always possible. The allowable error for data synchronization time is 1-9 seconds. When the difference between the timestamp and local time is within this range, it can be determined that the new cluster has completed data synchronization. In one specific embodiment, the timestamp is 10:45:18 (10:45:18), and the local time is 10:45:20 (10:45:20). At this point, the timestamp and local time... If the time difference is 2 seconds, it can be determined that the new cluster has completed data synchronization. In another specific embodiment, the timestamp is 10:45:20, which is 10:45:20, while the local time is 10:45:50, which is 10:45:50. At this time, the time difference between the timestamp and the local time is 30 seconds. Since 30 seconds is not within the range of 1s-9s, it is determined that the data synchronization is not complete. In another specific embodiment, the way to determine whether the new cluster has completed synchronization is to compare the local time with the time point of the consensus algorithm heartbeat mechanism set in the old cluster. If the difference between the local time and the local time is within 1s-9s, it is determined that the new cluster has completed synchronization.

[0067] Reference Appendix Figure 4 In one embodiment, the step of executing the database sharding command and updating the configurations of the old and new clusters includes:

[0068] Insert the database sharding command into the command queue of the old cluster;

[0069] The database sharding command is sent to the first automaton using a consensus algorithm;

[0070] The first automaton executes the database splitting command and obtains a first output program and a second output program. The first output program does not process non-class messages, and the second output program sends the database splitting completion message to the coordinator.

[0071] Store the database sharding completion message in the local database.

[0072] In practical implementation, after the data synchronization of the new cluster is completed, the new cluster sends a data synchronization completion message to the coordinator, and the coordinator sends a database sharding command to the old cluster, inserting the database sharding command into the command queue of the old cluster. Then, the database sharding command is sent to the first automaton through a consensus algorithm to ensure that the database sharding command can be continuously executed. The consensus algorithm is the Raft consensus algorithm, which is a distributed consensus algorithm. In order to ensure the consistency of the entire distributed system, it is necessary to ensure that each node executes the same command sequence, that is, the logs of each node must be consistent. Therefore, the Raft consensus algorithm is used to send the database sharding command to the first automaton set up in the old cluster. Then, the first automaton starts to execute the database sharding command. After execution, the first output program and the second output program are obtained. The first output program does not process non-category messages, that is, it does not process messages belonging to the new cluster. The second output program sends the database sharding completion message to the coordinator. Then, the coordinator stores the database sharding completion message in the local database.

[0073] In one embodiment, after the step of storing the database sharding completion message to the local database, the following steps are included:

[0074] Determine if the old cluster has received non-class messages;

[0075] If so, an error status message and redirection prompt are sent to the user to obtain the location of the old cluster.

[0076] In practical implementation, after the old cluster processes the sharding command, it can determine whether the received message is a class-specific message or a non-class-specific message. Class-specific information indicates content that the old cluster can process, while non-class-specific information indicates content that the old cluster cannot process. A routing layer is added between the user terminal and the event sourcing mode. This routing layer can dynamically update its internal routing information based on the cluster's error status information. If non-class-specific information is received, the old cluster will return error status information to the user terminal and provide a redirection prompt. In this invention, it is determined whether the old cluster has received a non-class-specific message. If so, error status information and a redirection prompt are sent to the user terminal so that the user terminal can obtain the location of the cluster to be accessed next, i.e., the location of the old cluster.

[0077] In one embodiment, the step of executing the database sharding command and updating the configurations of the old and new clusters includes:

[0078] The second automaton executes the database splitting command and obtains a first processing program and a second processing program. The first processing program processes the messages of the class to which the data belongs and sends the messages of the non-class to the user terminal. The second processing program sends the database splitting completion message to the coordinator.

[0079] Update the local database.

[0080] In practice, after the old cluster executes the sharding command, the new cluster is still in the data synchronization phase from the old cluster. Therefore, the new cluster will also read the sharding command recorded by the old cluster. After reading the sharding command, the new cluster executes the sharding command through the second automaton and obtains the first processing program and the second processing program. The first processing program processes the messages of the class to which it belongs, that is, it processes the messages that the new cluster is responsible for. The second processing result is to send the sharding completion message to the coordinator, that is, to notify the coordinator that the sharding operation has been completed. After receiving the sharding completion message, the coordinator updates the local database.

[0081] In one embodiment, after the step of updating the local database, the following steps are included:

[0082] Determine if the new cluster has received non-class messages;

[0083] If so, an error status message and redirection prompt are sent to the user to obtain the new cluster location.

[0084] In practical implementation, after processing the database sharding command, the new cluster can determine whether the received message is a class-specific message or a non-class-specific message. Class-specific information indicates content that the new cluster can process, while non-class-specific information indicates content that the new cluster cannot process. A route is established between the user terminal and the event sourcing mode. This route can dynamically update its internal routing information based on the error status information of the new cluster. Therefore, for content that the new cluster cannot process, it will return error status information to the user terminal and provide a redirection prompt. In this invention, it is determined whether the new cluster has received a non-class-specific message. If it has, it sends error status information and a redirection prompt to the upstream so that the user terminal can obtain the location of the new cluster for the next access.

[0085] In one embodiment, if so, the step of feeding back the result to the coordinator further includes:

[0086] The database sharding command is analyzed to obtain sharding information, which includes data in the new database.

[0087] Send the database sharding information to the server to obtain the location of the new database.

[0088] In practical implementation, the sharding command is analyzed to obtain sharding information, which includes new database data and the location of the new database. Since the server needs to process all messages, including those belonging to the same category and those not belonging to the same category, the server needs to obtain the locations of all clusters and all new databases. Furthermore, the server cannot know whether new and old clusters have undergone sharding. Therefore, a coordinator needs to send the sharding information to the server in real time so that the server can obtain the location of the new database from the sharding information. In another specific embodiment, since sharding commands exist during the sharding process, when the server processes new and old clusters, it will process the sharding information, thus allowing the server to directly obtain the location of the new database from the sharding information.

[0089] In summary, during implementation, firstly, data from the old cluster is synchronized to the new cluster using an event sourcing model. During synchronization, a data synchronization command is sent to the new cluster. Next, it's determined whether data synchronization is complete. This determination involves retrieving a snapshot file from the old cluster to obtain a timestamp, then comparing the timestamp with the local time to determine the time difference. If the time difference is within the range of 1-9 seconds, data synchronization is considered complete, and a data synchronization completion message is sent to the coordinator. The coordinator then sends a database sharding command to the old cluster based on this message, executes the sharding command, and updates the old cluster's configuration. The sharding command is inserted into the command queue of the old cluster, and then sent to the first automaton via a consensus algorithm. The first automaton executes the sharding command and obtains a first output program and a second output program. The first output program does not process non-class messages, while the second output program sends a sharding completion message to the coordinator and stores the sharding completion message in the local database. It then checks whether the old cluster has received non-class information; if so, it sends an error status message and redirection prompt to the user to obtain the location of the old cluster, executes the sharding command, and updates the cluster configuration. In other words, the sharding is performed via the second automaton. The command is executed, and a first and a second processing procedure are obtained. The first processing procedure processes messages of the relevant category and sends non-category messages to the user. The second processing procedure sends a sharding completion message to the coordinator, updates the local database, then checks if the new cluster has received non-category messages. If so, it sends an error status message and redirection prompt to the user to determine the new cluster's location. Next, it checks if the old and new clusters have completed sharding; if so, it sends the results back to the coordinator. Finally, the sharding command is analyzed to obtain sharding information. The process includes creating new database data and then sending the sharding information to the server to determine the new database location. The entire sharding process is initiated by a coordinator, with the old cluster as the sender. During the sharding process, the coordinator does not actively send commands to the new cluster, while the old cluster remains online throughout the process, continuously processing business logic in real time. The entire process is uninterrupted, ensuring that the sharding process does not impact the business system. The coordinator simply sends sharding commands to the old cluster and then waits for feedback from both the new and old clusters. This process has minimal business-related impact, minimizing business losses.

[0090] Reference Appendix Figure 2 A dynamic database sharding device for a data system, comprising:

[0091] Data synchronization module 10 is used to synchronize data from the old cluster to the new cluster according to the event tracing mode;

[0092] The first judgment module 20 is used to determine whether data synchronization is complete;

[0093] The first transmission module 30 is used to send a data synchronization completion message to the coordinator, and the coordinator sends a database splitting command to the old cluster based on the data synchronization completion message.

[0094] Execution module 40 is used to execute database sharding commands and update the configurations of the old and new clusters;

[0095] The second judgment module 50 is used to determine whether the old cluster and the new cluster have completed database sharding.

[0096] The first feedback module 60 is used to feed back the results to the coordinator if the condition is met.

[0097] The first transmission unit is used to send synchronization data commands to the new cluster;

[0098] The acquisition unit is used to obtain a timestamp by retrieving a snapshot file from the old cluster;

[0099] The comparison unit is used to compare the timestamp with the local time to obtain the time difference;

[0100] The determination unit is used to determine whether data synchronization is complete when the time difference is within the range of 1s-9s.

[0101] The insertion unit is used to insert the database sharding command into the command queue of the old cluster;

[0102] The second transmission unit is used to send the database sharding command to the first automaton through a consensus algorithm;

[0103] The storage unit is used to store the database sharding completion message to the local database;

[0104] The first judgment unit is used to determine whether the old cluster has received non-class messages;

[0105] The third transmission unit is used to send error status information and redirection prompts to the user terminal if the condition is met, so as to obtain the location of the old cluster.

[0106] The data update unit is used to update the local database;

[0107] The second judgment unit is used to determine whether the new cluster has received a non-class message;

[0108] The fourth transmission unit is used to send an error status and redirection prompt to the user terminal if the error is found, in order to obtain the new cluster location.

[0109] The analysis module is used to analyze the database sharding commands to obtain database sharding information;

[0110] The second transmission module is used to send the database information to the server.

[0111] In specific implementation, firstly, the data synchronization module 10 synchronizes the data from the old cluster to the new cluster according to the event tracing mode. The first judgment module 20 judges whether the data synchronization is complete. If so, the first transmission module 30 sends a data synchronization completion message to the coordinator. The coordinator sends a database sharding command to the old cluster based on the data synchronization completion message. Then, the execution module 40 executes the database sharding command and updates the configuration of the old and new clusters. The second judgment module 50 judges whether the old and new clusters have completed database sharding. If so, the first feedback module 60 feeds back the result to the coordinator. Next, the first transmission unit sends a data synchronization command to the new cluster. The acquisition unit obtains the timestamp by retrieving a snapshot file from the old cluster. Then, the comparison unit compares the timestamp with the local time to obtain the time difference. When the time difference is within the range of 1s-9s, the judgment unit determines that the data synchronization is complete. The insertion unit inserts the database sharding command into the command queue of the old cluster. Then, the second transmission unit sends the database sharding command to the first automaton through a consensus algorithm. The first automaton executes the database sharding command and... The system obtains a first output program and a second output program. The first output program does not process non-class messages, while the second output program sends a sharding completion message to the coordinator. The storage unit stores the sharding completion message in the local database. Then, the first judgment unit determines whether the old cluster has received non-class messages. If so, the third transmission unit sends an error status message and a redirection prompt to the user terminal to obtain the location of the old cluster. The second automaton executes the sharding command and obtains a first processing program and a second processing program. The first processing program processes class messages and sends non-class messages to the user terminal. The second processing program sends the sharding completion message to the coordinator. The data update unit updates the local database. The second judgment unit determines whether the new cluster has received non-class messages. If so, the fourth transmission unit sends an error status message and a redirection prompt to the user terminal to obtain the location of the new cluster. Then, the analysis module analyzes the sharding command to obtain sharding information. Finally, the second transmission module sends the sharding information to the server.

[0112] In summary, during implementation, before database sharding, the data synchronization module 10 synchronizes the data from the old cluster to the new cluster according to the event sourcing mode. The first judgment module 20 determines whether the data synchronization is complete. If synchronization is complete, the first transmission module 30 sends a data synchronization completion message to the coordinator. The coordinator then sends a sharding command to the old cluster based on the data synchronization completion message. During sharding, the execution module 40 executes the sharding command and updates the configurations of the old and new clusters. The second judgment module 50 determines whether the old and new clusters have completed sharding. If so, the first feedback module 60 feeds back the results to the coordinator. After sharding, the first judgment unit determines whether the old cluster has received non-class messages. If so, the third transmission unit sends error status information and redirection prompts to the user terminal to obtain the location of the old cluster. The data update unit updates the local database. The update process involves the second judgment unit determining whether the new cluster has received non-class messages. If so, the fourth transmission unit sends an error status and redirection prompt to the user terminal to obtain the location of the new cluster. The analysis module analyzes the sharding command to obtain sharding information, and the second transmission module sends the sharding information to the server. The entire sharding process is initiated by the coordinator, with the old cluster as the sender. During the sharding process, the coordinator does not actively send commands to the new cluster, while the old cluster remains online throughout the process, thus continuously processing business logic in real time. The entire process is uninterrupted, ensuring that the sharding process does not affect the business system. The coordinator only sends sharding commands to the old cluster and then waits for feedback messages from both the new and old clusters. This process has minimal business-related impact, reducing business losses.

[0113] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, apparatus, article, or method. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0114] The above description is only a preferred embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural changes made based on the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A dynamic database sharding method for a data system, characterized in that, Includes the following steps: The data from the old cluster is synchronized to the new cluster according to the event sourcing mode. The event sourcing mode records the defined events in the order in which they occur, and the data from the old cluster is synchronized to the new cluster in the order in which the events occur. Determine whether the data synchronization is complete; If so, a data synchronization completion message is sent to the coordinator, which then sends a database sharding command to the old cluster based on the data synchronization completion message. Execute the database sharding command and update the configuration of the old cluster and the new cluster; Determine whether the old cluster and the new cluster have completed database sharding; If so, the results will be fed back to the coordinator respectively; The step of synchronizing data from the old cluster to the new cluster based on the event sourcing model includes: Send a synchronization data command to the new cluster; The timestamp is obtained by retrieving snapshot files from the old cluster; The step of determining whether the data synchronization is complete includes: Compare the timestamp with the local time to obtain the time difference; When the time difference is within the range of 1s-9s, the data synchronization is considered complete. The step of executing the database sharding command and updating the configuration of the old cluster and the new cluster includes: Insert the database sharding command into the command queue of the old cluster; The database sharding command is sent to the first automaton using a consensus algorithm; The first automaton executes the database splitting command and obtains a first output program and a second output program. The first output program does not process non-class messages, and the second output program sends the database splitting completion message to the coordinator. The database sharding completion message is stored in the local database.

2. The method of claim 1, wherein, After the step of storing the completed database message to the local database, the following steps are included: Determine whether the old cluster has received the non-class message; If so, an error status message and redirection prompt are sent to the user to obtain the location of the old cluster.

3. The method of claim 1, wherein, The step of executing the database sharding command and updating the configuration of the new cluster includes: The database splitting command is executed by the second automaton, and a first processing program and a second processing program are obtained. The first processing program processes the messages of the class to which the database belongs and sends the messages of the non-class to the user terminal. The second processing program sends the database splitting completion message to the coordinator. Update the local database.

4. The method of claim 3, wherein, After the step of updating the local database, the following steps are included: Determine whether the new cluster has received the non-class message; If so, an error status message and a redirection prompt are sent to the user terminal to obtain the new cluster location.

5. The method of claim 1, wherein, If so, then after the step of feeding back the results to the coordinator, the method further includes: The database sharding command is analyzed to obtain database sharding information, wherein the database sharding information includes new database data; The database partitioning information is sent to the server to obtain the location of the new database.

6. A dynamic library splitting apparatus of a data system, characterized by comprising: include: The data synchronization module is used to synchronize data from the old cluster to the new cluster according to the event sourcing mode. The event sourcing mode records the defined events in the order of their occurrence and synchronizes the data from the old cluster to the new cluster in the order of their occurrence. The first judgment module is used to determine whether the data synchronization is complete; The first transmission module is used to send a data synchronization completion message to the coordinator, and the coordinator sends a database splitting command to the old cluster according to the data synchronization completion message. The execution module is used to execute the database sharding command and update the configuration of the old cluster and the new cluster; The second judgment module is used to determine whether the old cluster and the new cluster have completed database sharding. The first feedback module is used to feed back the results to the coordinator if the condition is met. The first transmission unit is used to send synchronization data commands to the new cluster; The acquisition unit is used to obtain a timestamp by retrieving a snapshot file from the old cluster; The comparison unit compares the timestamp with the local time to obtain the time difference; The determination unit determines that the data synchronization is complete when the time difference is in the range of 1s-9s. An insertion unit is used to insert the database sharding command into the command queue of the old cluster; The second transmission unit is used to send the database splitting command to the first automaton through a consensus algorithm; It also includes a method for executing the database splitting command through the first automaton and obtaining a first output program and a second output program, wherein the first output program does not process non-class messages, and the second output program sends a database splitting completion message to the coordinator. The database sharding completion message is stored in the local database.

Images