Methods and electronic devices for data backup under cross-device link aggregation groups

Abstract

This application discloses a method and electronic device for data backup under a cross-device link aggregation group, relating to the field of computer network communication technology. The method includes: a switch generating data entries to be backed up and metadata tags to a database; when multiple metadata tags are at a first preset value, determining a first target switch based on the switch's performance parameters, and modifying the metadata tags corresponding to the data entries to be backed up generated by the first target switch to a second preset value. This method solves the problems of synchronization congestion and entry omission risks in the current data backup process, and the lack of an effective verification and repair mechanism for data synchronization results. This method only requires data entry synchronization between the device and the database, avoiding congestion in the synchronization channel between switches. Comparison and cleaning of data entries through metadata tags eliminates entry omissions and inconsistencies. Furthermore, the switch can directly pull the latest entry backup from a remote database and restore device data.

Description

Technical Field

[0001] This invention relates to the field of computer network communication technology, and more specifically to a method and electronic device for data backup under a cross-device link aggregation group. Background Technology

[0002] Multichassis Link Aggregation Group (mclag) is a mechanism for implementing cross-device link aggregation. By aggregating links between two access switches and user-side devices in the same state, it improves link reliability from the board level to the device level. Simultaneously, because mclag devices can be upgraded independently, it ensures the stability of service traffic. The mclag master and slave devices need to synchronize data entries, with data between them serving as backups for each other to improve network reliability and achieve fast service traffic convergence. However, in large-scale network environments, the sheer number of terminals leads to a massive scale of software entries. When network topology oscillations or device restarts occur, the master device needs to synchronize a massive number of entry update messages to the slave device within a short period, easily causing synchronization channel congestion, resulting in delayed or even missed entry updates, ultimately leading to inconsistencies between master and slave device entries. Currently, the data backup process lacks an effective verification and repair mechanism for data synchronization results, and the system cannot automatically detect legacy or erroneous entries. Summary of the Invention

[0003] This invention provides a method and electronic device for data backup under a cross-device link aggregation group, in order to solve the problems of synchronization congestion and table entry omission risks in the current data backup process, and the lack of an effective verification and repair mechanism for data synchronization results.

[0004] In a first aspect, this application provides a method for data backup under a cross-device link aggregation group, the method comprising: Retrieve existing data table entries to be backed up and their metadata tags from the database. The data table entries to be backed up are generated and backed up to the database by any switch under the cross-device link aggregation group. The metadata tags are used to determine the source of the data table entries to be backed up. When multiple metadata tags corresponding to the data entries to be backed up are at the first preset value, obtain the performance parameters of the switch; Determine the first target switch based on the performance parameters, and modify the metadata tag corresponding to the data table entry to be backed up generated by the first target switch to the second preset value. If multiple metadata tags corresponding to the data table item to be backed up are the second preset value, or if multiple metadata tags are different, retain the data table item to be backed up and the metadata tags.

[0005] Secondly, this application provides an apparatus for data backup under a cross-device link aggregation group, the apparatus comprising: The information acquisition module is used to acquire existing data table entries to be backed up and metadata tags of the data table entries to be backed up in the database. The data table entries to be backed up are generated and backed up to the database by any switch under the cross-device link aggregation group, and the metadata tags are used to determine the source of the data table entries to be backed up. The parameter acquisition module is used to acquire the switch's performance parameters when multiple metadata tags corresponding to the data table entries to be backed up are at the first preset value; The first tag modification module is used to determine the first target switch based on performance parameters and modify the metadata tag corresponding to the data table entry to be backed up generated by the first target switch to the second preset value. The second tag modification module is used to retain the data table item to be backed up and the metadata tags when multiple metadata tags corresponding to the data table item to be backed up are at the second preset value, or when multiple metadata tags are different.

[0006] Thirdly, this application provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the data backup method under the cross-device link aggregation group described in the first aspect or any corresponding embodiment.

[0007] Fourthly, this application provides a computer-readable storage medium storing computer instructions for causing a computer to perform the method for data backup under a cross-device link aggregation group as described in the first aspect or any corresponding embodiment.

[0008] Fifthly, this application provides a computer program product, including computer instructions for causing a computer to perform a method for data backup under a cross-device link aggregation group as described in the first aspect or any corresponding embodiment.

[0009] This application addresses the issues of synchronization congestion and missing entries in current data backup processes, as well as the lack of effective verification and repair mechanisms for data synchronization results. By setting up a database and shifting the synchronization pressure from between switches to between devices and a high-performance database, this method effectively avoids synchronization channel congestion between switches. Metadata tags are used to compare and clean data entries, eliminating missing entries and inconsistencies. Furthermore, when both master and slave devices fail and restart simultaneously, the latest backup entries can be directly retrieved from the remote database, and a correct forwarding table can be quickly generated using an intelligent cleaning process, enabling rapid business recovery. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a method for data backup under a cross-device link aggregation group according to an embodiment of this application; Figure 2 This is a schematic diagram of the master device, database, and slave device in the mclag scenario according to an embodiment of this application; Figure 3 This is a schematic diagram of the table entry cleaning process according to an embodiment of this application; Figure 4 This is a flowchart of incremental data table entry synchronization according to an embodiment of this application; Figure 5 This is a schematic diagram of the arbitration strategy and algorithm according to the embodiments of this application; Figure 6 This is a flowchart of an mclag session backup method according to an embodiment of this application; Figure 7 This is a structural block diagram of an apparatus for data backup under a cross-device link aggregation group according to an embodiment of this application; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this application. Detailed Implementation

[0012] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0013] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0014] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0015] The specific application environment architecture or specific hardware architecture on which the data backup method under the cross-device link aggregation group depends is described here.

[0016] Cross-device link aggregation (mclag) is a mechanism for implementing cross-device link aggregation. By having two connected switches operate in the same state, it aggregates links with user-side devices or servers across devices, improving link reliability from the board level to the device level. Furthermore, because mclag devices can be upgraded independently, it ensures the stability of service traffic. Cross-device link aggregation requires data backup across different switches to improve network reliability, such as synchronizing data entries between master and slave devices.

[0017] Current data backup methods suffer from risks of synchronization congestion and missing entries, slow recovery after dual-machine failures, and a lack of effective verification and repair mechanisms. In large-scale network environments, the sheer number of terminals leads to a massive scale of software entries on switches. After network topology turbulence or device restarts, the master device in a switch needs to synchronize a massive number of entry update messages to the slave devices within a short period. However, while the Transmission Control Protocol (TCP) is highly reliable, its flow control and congestion window mechanisms can become bottlenecks for data recovery, causing synchronization channel congestion, resulting in delayed or even lost entries, ultimately leading to inconsistencies between master and slave device entries. When both the master and slave devices fail or restart simultaneously, all dynamically learned entries in the devices' memory will be lost. After recovery, both devices need to relearn all entries from scratch and perform large-scale synchronization again, a time-consuming process that prolongs network service interruption and fails to meet the millisecond-level fault recovery requirements of high availability scenarios. In addition, if entries are left behind or errors occur during the synchronization process, the system cannot automatically detect and repair them. It can only rely on aging equipment or new traffic to trigger relearning, which creates potential hidden dangers.

[0018] Based on the above, this application provides a method for data backup under a cross-device link aggregation group. The master-slave synchronization architecture is adjusted to a triangular architecture of master device-database-slave device. By introducing a remote database as an authoritative data source and backup repository, the direct strong dependency between master and slave devices is decoupled, and an intelligent table entry comparison and cleaning process is introduced. After establishing an mclag session between the master and slave devices, both devices synchronize data table entries to the remote database through a synchronization service, including data type and other characteristics, completing the table entry synchronization update between the master and slave devices. The master and slave devices continuously obtain the database synchronization status through polling, clean the software table entries in the database, and continuously perform periodic data verification and recovery, including data between the master and slave nodes, to ensure data consistency at both ends. The cleaned software table entries are then distributed to the hardware chip. The system introduces continuous entry verification and self-healing capabilities to improve the reliability and maintainability of the mclag system throughout its lifecycle; it provides an efficient disaster recovery mechanism that can quickly recover entries when both master and slave devices fail simultaneously, greatly shortening the business convergence time; and it resolves the issues of inconsistency and omission of entries caused by channel congestion during the synchronization of large-scale entries between mclag master and slave devices.

[0019] According to an embodiment of this application, a method embodiment for data backup under a cross-device link aggregation group is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] This embodiment provides a method for data backup under a cross-device link aggregation group. Figure 1 This is a flowchart of a data backup method under a cross-device link aggregation group according to an embodiment of this application, such as... Figure 1 As shown, the process includes the following steps: Step S101: Obtain the existing data table entries to be backed up and their metadata tags in the database. The data table entries to be backed up are generated and backed up to the database by any switch under the cross-device link aggregation group. The metadata tags are used to determine the source of the data table entries to be backed up.

[0021] Specifically, such as Figure 2 As shown, this embodiment designs a remote database, adjusting the master-slave synchronization architecture to a triangular architecture of master device-database-slave device. This triangular architecture consists of switch A, switch B, and the database, all of which can transmit data to each other. Switch A can exchange data with both host 1 and host 2, and switch B can exchange data with both host 1 and host 2. By introducing the database as an authoritative data source and backup repository, the direct strong dependency between master and slave devices is decoupled, and an intelligent table entry comparison and cleaning process is introduced.

[0022] In a cross-device link aggregation group, there are master and slave devices among the switches. After the master and slave devices establish an MCLAG session, they enter a periodic synchronization state, set the MCLAG status to OK, and notify the database synchronization service. The database synchronization service is used to synchronize the data table entries to be backed up to the database. Therefore, the data table entries to be backed up are software entries, which are generated and backed up to the database by any switch in the cross-device link aggregation group. Any switch can be a master or slave device.

[0023] In addition, each data table entry synchronized to the remote database carries a metadata tag, such as the Type tag, which identifies the source of the entry. If the Type tag is P (Peer-aged), it indicates that the entry was learned by this device; if the Type tag is L (Local-aged), it indicates that the entry was synchronized from the peer device. Therefore, the source of the data table entry to be backed up can be determined based on the metadata tag.

[0024] The master device or slave device retrieves the existing data table entries to be backed up and their metadata tags from the database. For example, the master device or slave device pulls all data table entries with metadata tags and metadata tags from the database as the data table entries to be backed up.

[0025] Step S102: When multiple metadata tags corresponding to the data table entries to be backed up are at the first preset value, obtain the performance parameters of the switch.

[0026] Specifically, the first preset value is, for example, L. When multiple metadata tags corresponding to a data table entry to be backed up are at the first preset value, that is, for a data table entry to be backed up, both ends of the table entries are L, this indicates that the system may have experienced an abnormal switch, and the original source cannot be determined.

[0027] Obtain the switch's performance parameters and determine which switch generated this metadata tag based on these parameters. Performance parameters include, for example, device priority, Internet Protocol (IP) address, and timestamp.

[0028] In addition, once the mclag system is running stably, it can periodically compare data by starting a low-priority background task to periodically compare and verify the device's local table entries with the backups in the remote database. If inconsistencies are found (such as a missing table entry on the device or an expired database entry), a repair process is automatically triggered (retrieving from the database or re-reporting), enabling continuous self-healing of the system. Adaptive control logic for synchronization frequency and batch size is added to the state machine, dynamically adjusting based on monitoring metrics.

[0029] Step S103: Determine the first target switch based on the performance parameters, and modify the metadata tag corresponding to the data entry to be backed up generated by the first target switch to the second preset value.

[0030] Specifically, the second preset value is, for example, P. The switch system determines the first target switch for generating the data entry to be backed up based on a preset arbitration strategy (such as comparing device priority, IP address size, or timestamp age). For example, if switch A has a higher device priority than switch B, then switch A is more likely to generate the data entry to be backed up, and switch A is chosen as the first target switch.

[0031] Modify the metadata tag corresponding to the data entry to be backed up generated by the first target switch to the second preset value. For example, change the value of the metadata tag corresponding to the data entry to be backed up generated by the first target switch from L to P to clarify the attribution.

[0032] Step S104: If multiple metadata tags corresponding to the data table item to be backed up are the second preset value, or if multiple metadata tags are different, retain the data table item to be backed up and the metadata tags.

[0033] Specifically, if multiple metadata tags corresponding to the data entry to be backed up are set to the second preset value, it means that for a data entry to be backed up, both ends of the entry are P. This usually occurs under special timing conditions (such as dual-active traffic), indicating that both devices have directly learned the entry from the network. The entry is valid and correct, and no processing is required; it is directly retained.

[0034] The presence of multiple different metadata tags indicates that for a data table entry to be backed up, one end of the entry is labeled P and the other end is labeled L. This suggests that the entry's origin is clear, requires no processing, and can be directly retained.

[0035] Therefore, the multiple metadata tags corresponding to the data table entries to be backed up are the second preset values, or the multiple metadata tags are different, and the data table entries to be backed up and the metadata tags are retained.

[0036] After the above table entry cleaning process resolves metadata tag conflicts, the remaining data table entries and metadata tags to be backed up will generate a conflict-free and consistent table entry list, which will also be synchronized to the database.

[0037] The above process is as follows Figure 3 As shown, the data table entries are cleaned; it is determined that for the same table entry in the database, both the primary and backup tables are marked with "L"; if both the primary and backup tables are marked with "L", table entry cleaning is performed, and the table entry marking is decided according to the primary and backup roles; if neither the primary nor backup tables are marked with "L", the data is retained.

[0038] This embodiment provides a method for data backup under a cross-device link aggregation group. Any switch in the cross-device link aggregation group generates data entries to be backed up and metadata tags, backing them up to a database. When multiple metadata tags corresponding to existing data entries to be backed up in the database are at a first preset value, a first target switch is determined based on the switch's performance parameters, and the metadata tags corresponding to the data entries to be backed up generated by the first target switch are modified to a second preset value. This method sets up a database to shift the synchronization pressure of data entries from the links between switches to the link between the device and the high-performance database, effectively avoiding congestion in the synchronization channels between switches. Data entries are compared and cleaned using metadata tags, eliminating the problems of missing entries and inconsistencies. Furthermore, when both master and slave devices fail and restart simultaneously, the latest entry backup can be directly pulled from the remote database, and combined with an intelligent cleaning process, a correct forwarding table can be quickly generated, enabling rapid service recovery. This solves the problems of synchronization congestion and missing entries in the current data backup process, and the lack of an effective verification and repair mechanism for data synchronization results.

[0039] As an optional embodiment, before obtaining the existing data table entries to be backed up and their metadata tags in the database, the method further includes: The database synchronization service synchronizes the data table entries and metadata tags to be backed up to the database. According to the preset state machine, obtain the data backup status of the switch; Once the data backup status indicates that the data entries to be backed up and the metadata tags have been synchronized, the control switch enters the service forwarding phase and the incremental synchronization phase of the entries.

[0040] Specifically, this invention proposes an intelligent synchronization method and device for MQLAG sessions based on remote database backup. Its core idea is to adjust the master-slave synchronization architecture to a triangular architecture of master device-database-slave device. By introducing a remote database as an authoritative data source and backup repository, the direct strong dependency between master and slave devices is decoupled, and an intelligent table entry comparison and cleaning process is introduced.

[0041] In a cross-device link aggregation group, switches contain master and slave devices. After an MQLAG session is established between the master and slave devices, they enter a periodic synchronization state, setting the MQLAG status to "ok" and notifying the database synchronization service. The database synchronization service then synchronizes the backup data entries and metadata tags generated by the master or slave device to the database.

[0042] Both the master and slave devices are equipped with preset state machines, which continuously monitor the data table synchronization process to obtain the data backup status of the switch. Based on the data backup status, it is confirmed whether the critical data table entries to be backed up and the metadata tags have been successfully backed up to the remote database.

[0043] Only after batch initialization synchronization is completed or critical table entries are confirmed to have been backed up will the system enter the formal service forwarding and next incremental synchronization phase. That is, after determining that the data table entries to be backed up and metadata tags have been synchronized based on the data backup status, the control switch will enter the service forwarding phase and the table entry incremental synchronization phase.

[0044] In this embodiment, a master-database-slave triangular architecture is adopted to decouple the strong dependency between master and slave devices, facilitating subsequent multi-active backup. A state machine is used to monitor the synchronization status, ensuring that service forwarding and incremental synchronization are only initiated after table entry backups are complete, thus improving the reliability and stability of mclag session synchronization.

[0045] As an optional embodiment, after the control switch enters the service forwarding phase and the entry incremental synchronization phase, the method further includes: Identify the newly added data table items that have changed; The newly added data entries are encapsulated into a preset notification message to obtain the information to be synchronized; The information to be synchronized is compressed to obtain a compressed package to be synchronized. Determine the data transmission size and data transmission interval based on the system load of the switch; Based on the data transmission size and data transmission interval, the compressed package to be synchronized is synchronized to the database, so that the database can update the data table entries and metadata tags according to the compressed package to be synchronized.

[0046] Specifically, this embodiment enters the incremental synchronization phase of table entries. The master and slave devices respectively use CDC (Change Data Capture) database synchronization technology to synchronize data table entries to the database. Only table entries that have changed are synchronized, avoiding the read / write and CPU pressure caused by large table entry requests.

[0047] The master or slave device identifies newly added data table entries that have changed, such as newly created data table entries, modified data table entries, and deleted data table entries.

[0048] Preset notification information, such as socket information. New data table entries are encapsulated into this preset notification information to obtain the information to be synchronized. For example, new data table entries are encapsulated into a socket notification and synchronized to a remote database.

[0049] Before sending the information to be synchronized, the information is compressed to obtain a compressed data packet. The data transmission size and interval are determined based on the switch's system load. For example, if the switch's system load is high, the data transmission size will be reduced and the data transmission interval increased to avoid further increasing the system load; for example, the data transmission size is 1Kb and the data transmission interval is 0.5 seconds. If the switch's system load is low, the data transmission size and the data transmission interval can be increased; for example, the data transmission size is 10Kb and the data transmission interval is 0.1 seconds.

[0050] A batch sending strategy is adopted, adaptively adjusting the data sending size and interval according to system load to synchronize the compressed packages to the database. This allows the database to update data table entries and metadata tags based on the compressed packages to be synchronized.

[0051] The remote database listening subscription service, upon receiving the compressed package to be synchronized, decompresses it and updates the data table entries and metadata tags in the database based on the decompressed data. Once the update is complete, the socket is closed and the device is notified that synchronization is complete.

[0052] The above process is as follows Figure 4As shown, according to the predetermined synchronization cycle, the device performs table entry maintenance; performs socket encapsulation and notifies the remote database; sends compressed data in batches to update the remote database, completing table synchronization. Furthermore, the synchronization cycle can be adjusted during the above process.

[0053] In this embodiment, by shifting the synchronization pressure of large table entries from the TCP link between the primary and backup servers to the link between the device and the high-performance database, synchronization channel congestion is effectively avoided. Only table entries that have changed are synchronized, thus avoiding the read / write and CPU pressure caused by requests for large table entries.

[0054] As an optional embodiment, determining the first target switch based on performance parameters includes: The overall device score of the switches is determined based on the performance parameters of multiple switches. Determine the score difference between the overall scores of the devices in the switches; The percentage of the score difference is determined based on the score difference and the overall equipment score; If the score difference ratio is greater than a preset threshold, the switch with the highest overall score will be selected as the first target switch.

[0055] Specifically, performance parameters include device priority, IP address, and timestamp. Based on the performance parameters of multiple switches, a comprehensive device score is determined for each switch. For example, if switch A has a higher device priority, an earlier IP address, and a timestamp closer to the current system time, switch A's comprehensive device score is 100, while switch B's comprehensive device score is 50.

[0056] Determine the score difference between the overall device scores of the switches. For example, if the overall device score of switch A is 85 and the overall device score of switch B is 80, the score difference is 85 - 80 = 5.

[0057] The percentage of the percentage difference in scores is determined based on the difference in scores and the overall score of the devices. For example, if the overall score of switch A is 85 and the overall score of switch B is 80, the difference in scores is 5, then the percentage of the percentage difference in scores = 5 ÷ 85 = 5.8824%; if the overall score of switch A is 111 and the overall score of switch B is 110, the difference in scores is 1, then the percentage of the percentage difference in scores = 1 ÷ 111 = 0.9009%.

[0058] Preset thresholds include, for example, 1%, 1.5%, or other values ​​that meet actual needs. If the score difference ratio is greater than the preset threshold, the score gap between different switches is significant, and the switch with the higher overall device score can be directly selected as the primary target switch. If the score difference ratio is less than or equal to the preset threshold, the score gap between different switches is not significant, and a refined arbitration process is required to determine the primary target switch from among multiple switches.

[0059] The above process is as follows Figure 5 As shown, the process includes: context collection; comprehensive score calculation; branch office score difference judgment; if the difference is less than 1%, a difference judgment is performed (refined arbitration process); and table entries are repaired.

[0060] In this embodiment, a periodic verification mechanism is employed to clean the data entries in the database, proactively identifying and repairing silent errors, thereby improving the long-term stability and maintainability of the system. A comprehensive device score is calculated based on multi-dimensional performance parameters, and the device gap is determined by the percentage difference in scores. When the gap is significant, the high-scoring switch is directly selected as the target device, simplifying the arbitration process and improving the efficiency and rationality of selecting the first target switch.

[0061] As an optional embodiment, the overall device score of a switch is determined based on the performance parameters of multiple switches, including: Obtain the switch's timestamp, device priority, resource utilization, and session performance metrics from the performance parameters; Determine the time difference between the timestamp and the preset timestamp, and determine the data item based on the first preset parameter and the time difference; The larger value between the second preset parameter and the data item is used as the score for the first dimension. Based on the third preset parameter, the device priority is mapped to a preset data range to obtain the second dimension score; Based on the first mapping relationship, the resource utilization rate is mapped to a preset data range to obtain the third dimension score; Based on the second mapping relationship, the session performance metrics are mapped to a preset data range to obtain the fourth dimension score; The scores of the first dimension, the second dimension, the third dimension, and the fourth dimension are combined according to the preset weights to obtain the overall score of the device.

[0062] Specifically, this embodiment uses a weighted algorithm to first calculate the different entries in the database, determine the priority level based on the scores, and then clean the database.

[0063] The performance parameters retrieve the switch's timestamp, device priority, resource utilization, and session performance metrics. Session performance metrics include, for example, network latency, packet loss rate, session connection duration, and number of disconnections. Resource utilization metrics include, for example, CPU utilization, memory utilization, and disk utilization.

[0064] The first dimension is the timestamp dimension. Determine the time difference between the current timestamp and the preset timestamp. For example, if the preset timestamp is in milliseconds, it needs to be converted to milliseconds as well, and the timestamp value needs to be modified to 1000 times the previous value. Use the modified timestamp as the new timestamp. Obtain the preset timestamp. For example, determine the timestamp of the creation or update of the data table entry to be backed up and use it as the preset timestamp; calculate the time difference between the current timestamp and the preset timestamp.

[0065] The first preset parameters include a maximum ratio and a time window threshold. The time window threshold sets the total effective time of the entry. For example, the time window threshold can be 5 minutes or other durations. The first preset parameter can be set to convert 5 minutes to milliseconds as 5 × 60 × 1000. The maximum ratio is, for example, 1. Data items are determined based on the first preset parameters and the time difference. For example, a timestamp can represent the current time of the device, and a preset timestamp can represent the generation time of the data entry to be backed up. The time difference between the timestamp and the preset timestamp represents the survival time of the data entry to be backed up, and the time window threshold represents the total effective time of the data entry to be backed up. The time difference is divided by the time window threshold, and the result is used as intermediate data, representing the proportion of time consumed by the data entry to be backed up. The maximum ratio is subtracted from the intermediate data, and the result is used as a data item, representing the proportion of the remaining survival time of the data entry to be backed up. If the survival time of the data entry to be backed up exceeds the time window threshold, the data item is less than 0.

[0066] The second preset parameter is, for example, 0 or other smaller values. The larger value between the second preset parameter and the data item is used as the first dimension score. For example, if the second preset parameter is 0, the larger value between 0 and the data item is used as the first dimension score. By comparing the data item with 0, the first dimension score is made to be at least 0, so as to avoid the first dimension score being negative due to the data item being less than 0, which would affect the accuracy of the target score calculation of the subsequent switch.

[0067] The third preset parameter is, for example, 100, and the preset data range is, for example, 0-1. The third preset parameter is used to normalize device priority. To obtain the device priority, for example: first, accurately locate the device configuration dictionary corresponding to the device ID; then, using a safe value extraction method, extract the device priority field from the device configuration dictionary, and determine the device priority based on the value in the device priority field; if the device priority field does not exist in the device configuration dictionary or the device ID is invalid, the device priority is set to 50 by default to ensure the scoring logic is not interrupted. The device priority is then mapped to the preset data range based on the third preset parameter to obtain the second-dimensional score. For example, the device priority is determined by dividing the calculated result of the device priority by the third preset parameter, thus normalizing the device priority to 0-1, and this calculated result is used as the second-dimensional score.

[0068] Resource utilization, such as CPU utilization, memory utilization, and disk utilization.

[0069] The first mapping relationship is as follows: the lower the utilization rate, the higher the score. For example, if the CPU utilization rate is 10%, the score is 0.9; if the CPU utilization rate is 90%, the score is changed to 0.1. That is, the first mapping relationship is: third-dimensional score = 1 - resource utilization rate. If there are multiple resource utilization rates, such as CPU utilization rate, memory utilization rate, and disk utilization rate, you can first determine the average or weighted average of each utilization rate, and then use the first mapping relationship to map it to a third-dimensional score in the range of 0-1.

[0070] Session performance metrics include network latency, packet loss rate, session connection duration, and number of disconnections. Session stability can be determined based on these metrics. The second mapping relationship is as follows: higher stability corresponds to a higher score in the fourth dimension. For example, a network latency of 10ms and a packet loss rate of 0% results in a fourth-dimensional score of 1; a network latency of 500ms and a packet loss rate of 80% results in a score of 0.2. Based on this second mapping relationship, session performance metrics are mapped to a preset data range to obtain the fourth-dimensional score.

[0071] The preset weights are set according to actual needs. For example, the preset weight for the first dimension score is 0.1, the preset weight for the second dimension score is 0.2, the preset weight for the third dimension score is 0.3, and the preset weight for the fourth dimension score is 0.4, with a total weight of 1. The first, second, third, and fourth dimension scores are combined based on these preset weights to obtain the overall equipment score. For example, the product of the first dimension score and its corresponding preset weight is calculated, as are the products of the second, third, and fourth dimension scores. These products are then summed, and the sum is taken as the overall equipment score.

[0072] In this embodiment, a multi-dimensional scoring system is constructed by integrating four core parameters: timestamp, device priority, resource utilization, and session performance. Each dimension undergoes normalization and extreme value filtering for standardization, and then the overall device score is calculated by weighting according to preset weights. This achieves a comprehensive and accurate quantitative evaluation of switch performance. The scoring logic is scientific and adaptable to actual needs, providing objective and reliable data support for subsequent switch selection and priority determination.

[0073] As an optional embodiment, when the percentage difference in scores is less than or equal to a preset threshold, the method further includes: Obtain timestamp weight, device priority weight, and session performance weight; The first adjusted score is obtained by adjusting the first dimension score using timestamp weights. The second adjusted score is obtained by adjusting the second dimension score using the device priority weight; The fourth dimension score is adjusted using session performance weights to obtain the third adjusted score; The first adjustment score, the second adjustment score, and the third adjustment score are combined to obtain the target scores for multiple switches; In the switch, the switch corresponding to the target score with the highest value is designated as the first target switch.

[0074] Specifically, when the score difference ratio is less than or equal to a preset threshold, the score difference between different switches is very small, and a fine arbitration process is needed to determine the first target switch among multiple switches.

[0075] Obtain timestamp weight, device priority weight, and session performance weight. For example, timestamp weight is 0.35, device priority weight is 0.20, and session performance weight is 0.25. The weight values ​​and weight types can be adjusted according to actual needs.

[0076] The first dimension score is adjusted using timestamp weights. The first adjusted score is the product of the first dimension score and the timestamp weights.

[0077] The second dimension score is adjusted using the device priority weight. The second adjusted score is the product of the second dimension score and the device priority weight.

[0078] The fourth dimension score is adjusted using the session performance weight, and the third adjusted score is the product of the fourth dimension score and the session performance weight.

[0079] The first, second, and third adjusted scores are combined to obtain target scores for multiple switches. For example, the sum of the first, second, and third adjusted scores can be used as the target score. Among the switches, the switch with the highest target score is selected as the first target switch.

[0080] In this embodiment, a refined arbitration process is initiated for scenarios where the overall scores of devices differ only slightly. By configuring timestamps, device priorities, and session performance-specific weights, the scores of corresponding dimensions are adjusted and the target score is calculated. The switch with the highest score is selected as the first target device, solving the problem of determining the device with similar scores and improving the accuracy and rationality of the selection process.

[0081] As an optional embodiment, after modifying the metadata tag corresponding to the backup data table entry generated by the first target switch to a second preset value, the method further includes: Generate a first target table entry list based on the data table entries to be backed up and their modified metadata tags; Synchronize the first target table entry list to the database; The first target entry list is sent to the switch's software entry library, and the information in the first target entry list is written into the switch's hardware forwarding table.

[0082] Specifically, in this embodiment, after the primary and backup devices have finished processing the data entries, they synchronously send the data to their respective software entries.

[0083] After the above table entry cleaning process resolves metadata tag conflicts, a conflict-free and consistent first target table entry list is generated based on the remaining data table entries to be backed up and their modified metadata tags. This first target table entry list is then synchronized to the database.

[0084] The first target entry list is sent to the switch's software entry library, and the information in the first target entry list is written into the switch's hardware forwarding table. For example, the cleaned first target entry list is sent to the switch's local software entry library in an orderly manner, and finally programmed into the switch's hardware forwarding table.

[0085] In addition, the strategy of sending the first target entry list to the software entry library can prioritize the recovery of software entries generated by this device, ensuring that local traffic is restored first, and then entries from the peer are restored.

[0086] In this embodiment, a conflict-free target entry list is generated, synchronized to the database, then distributed to the software entry library and written to the hardware forwarding table. A local entry-first recovery strategy is adopted to ensure rapid traffic recovery and improve the consistency of mclag entry synchronization and service forwarding efficiency.

[0087] As an optional embodiment, the method further includes: When multiple switches fail and restart simultaneously, retrieve the backed-up data table entries and their metadata tags from the database. When multiple metadata tags corresponding to the backed-up data table entries are at the first preset value, obtain the switch's performance parameters; Determine the second target switch based on the performance parameters, and modify the metadata tag corresponding to the data table entry to be backed up generated by the second target switch to the second preset value. Generate a second target table entry list based on the backed-up data table entries and their modified metadata tags; Based on the entries in the second target entry list whose metadata tags are set to the second preset value, generate the first software entry and send the first software entry to the software entry library of the switch. Based on the entries in the second target entry list whose metadata tags are set to the first preset value, a second software entry is generated and sent to the software entry library of the switch.

[0088] Specifically, this embodiment enables extremely rapid disaster recovery. When both the master and slave devices fail and restart simultaneously, there is no need for slow relearning or synchronization from the peer. Both devices can directly pull the latest data table backups from the remote database, including the backed-up data table entries and their metadata tags. Combined with the data table cleaning process, correct forwarding tables are quickly generated, reducing business recovery time from minutes to seconds or even sub-seconds.

[0089] The first preset value is, for example, L. When multiple metadata tags corresponding to a backed-up data table entry are at the first preset value (i.e., for a backed-up data table entry, both ends of the table are L), this indicates that the system may have experienced an abnormal switchover, and the original source cannot be determined. Obtain the switch's performance parameters, such as device priority, IP address, and timestamp.

[0090] The second target switch is determined based on performance parameters. The metadata tag corresponding to the backup data entry generated by the second target switch is modified to a second preset value. For example, the second preset value is P. The switch system determines the second target switch that generated the backup data entry based on a preset arbitration strategy (such as comparing device priority, IP address size, or the age of the timestamp). For example, if switch A has a higher device priority than switch B, switch A is more likely to generate the backup data entry, and switch A is selected as the second target switch. The metadata tag corresponding to the backup data entry generated by the second target switch is modified to the second preset value.

[0091] If multiple metadata tags corresponding to a backed-up data entry are set to the second preset value, it means that for a backed-up data entry, both ends of the entry are P. This usually occurs under special timing conditions (such as dual-active traffic), indicating that both devices have directly learned the entry from the network. This entry is valid and correct, and no processing is required; it is directly retained.

[0092] Next, the second target entry list needs to be sent to the switch's software entry library, and the information in the second target entry list needs to be written into the switch's hardware forwarding table. The strategy of sending the first target entry list to the software entry library can prioritize the restoration of software entries generated by this device, ensuring that local traffic is restored first, and then entries from the peer end are restored.

[0093] The second preset value is, for example, P. The table entries in the second target table entry list whose metadata tags are the second preset value are table entries learned by this device, i.e., table entries generated by this device. A first software table entry is generated based on this table entry, and the first software table entry is sent to the switch's software table entry library.

[0094] The first preset value is, for example, L. Based on the table entries in the second target table entry list whose metadata tags are the first preset value, and which are table entries generated by the peer device, a second software table entry is generated based on this table entry, and the second software table entry is sent to the switch's software table entry library.

[0095] In this embodiment, rapid disaster recovery is achieved after multiple switches fail and restart. Backup entries are retrieved from the database, metadata tags are corrected through arbitration, and software entries are distributed according to type. This significantly shortens service recovery time to the second / sub-second level, ensuring service continuity and entry consistency.

[0096] As an optional implementation, the metadata tags of the data table entries to be backed up are obtained, including: Obtain the table entry source, table entry update timestamp, and session identifier to which the table entry belongs for the data table entry to be backed up; Obtain the switch's device identifier, device processor, and device memory; Generate metadata tags based on the entry's source, update timestamp, session identifier, device identifier, device processor, and device memory.

[0097] Specifically, after the mclag session is established, the data entries are synchronized to the remote database. When synchronizing the data entries to the database, each data entry carries rich metadata tags, including data type, ARP (Address Resolution Protocol) entry, MAC (Media Access Control) entry, etc.

[0098] Based on the entry's source, update timestamp, session ID, device ID, device processor, and device memory, metadata tags are generated. These metadata tags include, for example: Type, Device ID, Timestamp, Session ID, Device_CPU, and Device_mem. Specifically, Type identifies the entry's source; Type P indicates an entry learned by this device, and Type L indicates an entry synchronized from a peer device; Device ID represents the device ID that generated the entry; Timestamp represents the entry's last update timestamp; Session ID represents the associated mclag session ID; Device_CPU represents the device processor (CPU); and Device_mem represents the device memory.

[0099] In this embodiment, metadata tags are generated by integrating table entry information such as entry source and update timestamp with device parameters such as device identifier and processor. This gives each data entry to be backed up a rich and unique identifier, improving the traceability and management efficiency of mclag entry backup and synchronization.

[0100] As an optional embodiment, this embodiment provides a method for backing up mclag sessions, such as... Figure 6 As shown, the method includes: establishing an mclag session between the primary and backup devices; synchronizing database table entries, including data types and other characteristics, to the remote database through a synchronization service; continuously obtaining the database synchronization status through polling; comparing the primary and backup databases during this stage, using a comparison algorithm for judgment; after the software table entries are cleaned, the data is distributed to the hardware chip; in the mclag session, table entry synchronization updates between the primary and backup devices are completed; the device system will continuously perform periodic data verification and recovery, including data between the primary and backup nodes, to ensure data consistency at both ends.

[0101] Additionally, an mclag session backup device can be created and deployed on an mclag device, including: a database synchronization service module for interacting with a remote database to report and retrieve table entries; a table entry management module for adding metadata tags to local table entries and receiving table entries from the database synchronization service module; a table entry comparison and cleaning module for executing table entry comparison and conflict resolution algorithms; and a table entry distribution module for distributing the processed consistent table entries to the software and hardware forwarding tables.

[0102] In this embodiment, by shifting the synchronization pressure of large-scale entries from the TCP link between the primary and backup systems to the link between the device and the high-performance database, synchronization channel congestion is effectively avoided. The periodic verification mechanism proactively detects and corrects silent errors, improving the long-term stability and maintainability of the system.

[0103] As an optional embodiment, when the ratio of score differences is less than or equal to a preset threshold, the specific process of the method in the above embodiment may further include steps A1 to A5.

[0104] In this embodiment, when the score difference ratio between different switches is less than 1%, a fine arbitration process is initiated. This embodiment provides additional evaluation dimensions (such as service traffic priority and network link quality), decision logic (such as multi-round scoring rules), retention strategies for archived failure entries (retention duration and cleanup trigger conditions) for the fine arbitration process, and completes the execution process.

[0105] Step A1: In addition to the basic context (device status, network environment), collect three types of core data: link quality parameters, service traffic characteristics, and historical arbitration records. Link quality parameters include, for example, packet loss rate, latency, and jitter in communication between the primary / backup devices and the database. Service traffic characteristics include, for example, the service type associated with the table entry, traffic priority, and bandwidth usage percentage. Historical arbitration records include, for example, the conflict resolution results for this table entry or similar table entries within the past 30 minutes.

[0106] Step A2 adds two new dimensions to the original four dimensions for determining whether to proceed to the fine-grained arbitration process: link quality and business priority. The link quality dimension calculates the optimal score based on a packet loss rate of <1% and latency of <5ms. The business priority dimension assigns weights based on the SLA level of the associated business, with core businesses receiving higher weights than non-core businesses.

[0107] Step A3: Sub-dimension quantization and weighted calculation.

[0108] Specifically, the link quality score = 1 - (packet loss rate × 0.6 + latency / 100ms × 0.4), with the result normalized to 0-1; the business priority score = the preset priority coefficient of the business associated with the table entry; the total score is recalculated by combining the original four dimension scores, for example: each of the newly added dimensions accounts for 10%, the weights of the original dimensions are reduced proportionally, and the sum remains 100%. The preset priority coefficients are, for example: core business 1.0, ordinary business 0.7, low priority 0.4.

[0109] Step A4: Multi-round iterative calibration.

[0110] Specifically, the first iteration calculates a new total score based on the supplementary dimensions. If the score difference is still <0.5%, the process proceeds to the second iteration. The second iteration introduces a historical consistency factor to correct the total score. The third iteration triggers real-time link probing if the score difference is still <0.3%. After correcting the link quality score based on the probing results, the final total score is calculated. The historical consistency factor is, for example, the percentage of times a device wins in the last three arbitrations of the same type of entry. Real-time link probing is, for example, sending three test packets to verify communication stability.

[0111] The second iteration introduces a historical consistency factor, which is explained below. All arbitration records for the same type of entry within the past 30 minutes are extracted from the arbitration logs of the remote database. For the two devices currently in conflict (switch A and switch B), the number of times each device wins in the collected historical arbitration records is counted. The ratio of the target device's winning count to the total number of historical arbitrations is calculated, and this ratio is normalized to the range of 0-1. The normalized value is used as the historical consistency factor; if the total number of historical arbitrations is 0, the historical consistency factor is set to 0.5 by default.

[0112] The historical consistency factor is used as an independent weighting item (accounting for 10%) to correct the original total score: Corrected total score = original total score × 90% + historical consistency factor × 10%.

[0113] Step A5: If the difference is still <0.3% after 3 rounds of iteration, execute the preset fallback rule. Prioritize the optimal combination of device priority and timestamp to avoid infinite loops. For example, device priority weight: 60%, timestamp weight: 40%.

[0114] In this embodiment, richer data and dimensions improve the accuracy of conflict decision-making. Multiple rounds of iterative calibration narrow the score difference, avoiding misjudgments. A fallback rule prevents infinite loops, ensuring a closed-loop process. Verification and archiving ensure reliable results, and retained data supports algorithm optimization, efficiently resolving table entry conflicts.

[0115] This embodiment also provides a data backup device under a cross-device link aggregation group. This device is used to implement the above embodiments and preferred embodiments, and details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0116] This embodiment provides a device for data backup under a cross-device link aggregation group, such as... Figure 7 As shown, it includes: The information acquisition module 701 is used to acquire existing data table entries to be backed up and metadata tags of the data table entries to be backed up in the database. The data table entries to be backed up are generated and backed up to the database by any switch under the cross-device link aggregation group. The metadata tags are used to determine the source of the data table entries to be backed up. The parameter acquisition module 702 is used to acquire the performance parameters of the switch when multiple metadata tags corresponding to the data table entries to be backed up are at the first preset value; The first tag modification module 703 is used to determine the first target switch based on performance parameters and modify the metadata tag corresponding to the data table entry to be backed up generated by the first target switch to the second preset value. The second tag modification module 704 is used to retain the data table item to be backed up and the metadata tags when multiple metadata tags corresponding to the data table item to be backed up are at the second preset value, or when multiple metadata tags are different.

[0117] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0118] In this embodiment, the device for data backup under the cross-device link aggregation group is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0119] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0120] The following is a detailed reference. Figure 8 This diagram illustrates a suitable structural schematic for implementing an electronic device according to embodiments of the present invention. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 801, which can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0121] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0122] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the method for data backup under a cross-device link aggregation group according to embodiments of the present invention.

[0123] Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0124] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the method for data backup under a cross-device link aggregation group when it is run.

[0125] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0126] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above-described methods for data backup under a cross-device link aggregation group.

[0127] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above-described methods for data backup under a cross-device link aggregation group.

[0128] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0129] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0130] The foregoing has provided a detailed description of a method and electronic device for data backup under a cross-device link aggregation group, as provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for data backup under a cross-device link aggregation group, characterized in that, The method includes: Obtain the existing data table entries to be backed up in the database and the metadata tags of the data table entries to be backed up, wherein the data table entries to be backed up are generated and backed up to the database by any switch under the cross-device link aggregation group, and the metadata tags are used to determine the source of the data table entries to be backed up. When multiple metadata tags corresponding to the data table entry to be backed up are at a first preset value, the performance parameters of the switch are obtained; Based on the performance parameters, a first target switch is determined, and the metadata tag corresponding to the data entry to be backed up generated by the first target switch is modified to a second preset value. If the multiple metadata tags corresponding to the data table item to be backed up are the second preset value, or if the multiple metadata tags are different, the data table item to be backed up and the metadata tags are retained.

2. The method according to claim 1, characterized in that, The step of determining the first target switch based on the performance parameters includes: The overall device score of the switch is determined based on multiple performance parameters of the switch. Determine the score difference of the overall scores of the devices between the switches; The percentage of the score difference is determined based on the score difference and the overall score of the equipment. If the score difference ratio is greater than a preset threshold, the switch with the highest overall device score among the switches will be selected as the first target switch.

3. The method according to claim 2, characterized in that, The step of determining the overall device score of the switch based on multiple performance parameters of the switch includes: The timestamp, device priority, resource utilization, and session performance metrics of the switch are obtained from the performance parameters. Determine the time difference between the timestamp and the preset timestamp, and determine the data item based on the first preset parameter and the time difference; The larger value between the second preset parameter and the data item is used as the score of the first dimension. The device priority is mapped to a preset data range based on the third preset parameter to obtain the second dimension score; The resource utilization rate is mapped to the preset data range according to the first mapping relationship to obtain the third dimension score; The session performance metrics are mapped to the preset data range according to the second mapping relationship to obtain the fourth dimension score; The first dimension score, the second dimension score, the third dimension score, and the fourth dimension score are combined according to preset weights to obtain the overall device score.

4. The method according to claim 3, characterized in that, When the percentage difference in scores is less than or equal to the preset threshold, the method further includes: Obtain timestamp weight, device priority weight, and session performance weight; The first dimension score is adjusted using the timestamp weight to obtain the first adjusted score; The second dimension score is adjusted using the device priority weight to obtain the second adjusted score; The fourth dimension score is adjusted using the session performance weights to obtain the third adjusted score; The first adjusted score, the second adjusted score, and the third adjusted score are combined to obtain the target scores for multiple switches; Among the switches, the switch corresponding to the target score with the largest value is designated as the first target switch.

5. The method according to claim 1, characterized in that, Before obtaining the existing data table entries to be backed up in the database and the metadata tags of the data table entries to be backed up, the method further includes: The data table entries to be backed up and the metadata tags are synchronized to the database using the database synchronization service. The data backup status of the switch is obtained according to the preset state machine; If the data table entry to be backed up and the metadata tag are determined to be synchronized based on the data backup status, the switch is controlled to enter the service forwarding phase and the table entry incremental synchronization phase.

6. The method according to claim 5, characterized in that, After controlling the switch to enter the service forwarding phase and the entry incremental synchronization phase, the method further includes: Identify the newly added data table items that have changed; The newly added data table entries are encapsulated into preset notification information to obtain the information to be synchronized; The information to be synchronized is compressed to obtain a compressed package to be synchronized; The data transmission size and data transmission interval are determined based on the system load of the switch. Based on the data transmission size and the data transmission interval, the compressed package to be synchronized is synchronized to the database, so that the database updates the data table entries and the metadata tags according to the compressed package to be synchronized.

7. The method according to claim 1, characterized in that, After modifying the metadata tag corresponding to the backup data table entry generated by the first target switch to a second preset value, the method further includes: A first target entry list is generated based on the data entries to be backed up and the modified metadata tags of the data entries to be backed up; Synchronize the first target table entry list to the database; The first target entry list is sent to the software entry library of the switch, and the information in the first target entry list is written into the hardware forwarding table of the switch.

8. The method according to claim 1, characterized in that, The method further includes: When multiple switches fail and restart simultaneously, retrieve the backed-up data table entries and their metadata tags from the database. When the multiple metadata tags corresponding to the backed-up data table entries are the first preset values, the performance parameters of the switch are obtained; Based on the performance parameters, a second target switch is determined, and the metadata tag corresponding to the data entry to be backed up generated by the second target switch is modified to a second preset value. A second target entry list is generated based on the backed-up data entries and the modified metadata tags of the backed-up data entries; Based on the entries in the second target entry list whose metadata tags are set to the second preset value, a first software entry is generated and the first software entry is sent to the software entry library of the switch. Based on the entries in the second target entry list whose metadata tags are set to the first preset value, a second software entry is generated and sent to the software entry library of the switch.

9. The method according to claim 1, characterized in that, Obtain the metadata tags of the data table entries to be backed up, including: Obtain the table entry source, table entry update timestamp, and table entry session identifier of the data table entry to be backed up; Obtain the device identifier, device processor, and device memory of the switch; The metadata tag is generated based on the entry source, the entry update timestamp, the session identifier to which the entry belongs, the device identifier, the device processor, and the device memory.

10. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the data backup method under any one of claims 1 to 9.

Images