Data processing method and storage medium

Through a dual-channel collaborative architecture, the main control end and the backup control end work together to achieve real-time synchronization and fine-grained takeover of meeting data, solving the problem of insufficient data backup granularity in existing technologies and improving the user's meeting experience.

CN123048290APending Publication Date: 2026-11-06SHENZHEN TAIDEN INDAL
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610866000.2
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-16
Publication Date
2026-11-06

AI Technical Summary

Technical Problem

The existing conference system has low data backup granularity, resulting in insufficient fault takeover granularity and affecting user experience.

Method used

The system adopts a dual-channel collaborative architecture. The master control end synchronizes meeting status data through a long connection, while the backup control end uses the change record table to obtain metadata for business data backup, thereby achieving real-time synchronization and fine-grained takeover.

Benefits of technology

It improves data synchronization efficiency and the precision of fault takeover, ensuring that the meeting status on the backup control end is consistent with that on the master control end, thus enhancing the user's meeting experience.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123048290A_ABST
    Figure CN123048290A_ABST
Patent Text Reader

Abstract

This application discloses a data processing method and storage medium. The method is applied to a conference system, which includes a master control terminal and a backup control terminal. The method includes: in response to a change in a first data table, the master control terminal writes first metadata of first business data into a change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the conference; the backup control terminal obtains the first metadata from the change record table; the backup control terminal backs up the first business data based on the first metadata and the first data table; and the master control terminal sends the conference status data of the conference to the backup control terminal via a long connection. This application helps to improve the granularity of conference data backup and the granularity of conference takeover.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a data processing method and a storage medium. Background Technology

[0002] In modern conference venues, conference systems are widely used. Currently, the management of conference systems primarily involves using conference management system software. This software and its operating system serve as the hardware and software environment to control the connected conference systems, enabling the increasingly widespread use of advanced conference systems that include proposals and voting.

[0003] With the increasing prevalence of conference systems, higher and higher demands are being placed on their security and reliability, making the preservation and backup of conference data increasingly important. However, current backups of conference data have relatively low granularity, resulting in limited granularity in fault takeover when the control end of the conference system fails. Summary of the Invention

[0004] This application provides a data processing method and storage medium that simultaneously backs up the business data and status data of a conference through dual channels, thereby improving the precision of conference data backup and thus improving the precision of fault takeover of the conference system.

[0005] In a first aspect, embodiments of this application provide a data processing method, the method being applied to a backup control terminal of a conference system, the conference system further including a master control terminal; the method includes: The backup control terminal obtains the first metadata from the change record table. The first metadata is the metadata of the first business data that has changed in the first data table. The first metadata is written to the change record table by the main control terminal when the first business data changes. The first data table is any data table related to the meeting. The backup control terminal backs up the first business data based on the first metadata and the first data table; The backup control terminal receives the conference status data from the master control terminal via a long connection.

[0006] Secondly, embodiments of this application provide a data processing method applied to the main control terminal of a conference system, wherein the conference system further includes a backup control terminal; the method includes: In response to a change in the first data table, the main control terminal writes the first metadata of the first business data into the change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting; The master control terminal sends the conference status data to the backup control terminal via a long connection.

[0007] Thirdly, embodiments of this application provide a data processing method, which is applied to a conference system, the conference system including a main control terminal and a backup control terminal; the method includes: In response to a change in the first data table, the main control terminal writes the first metadata of the first business data into the change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting; The backup control terminal obtains the first metadata from the change record table; The backup control terminal backs up the first business data based on the first metadata and the first data table; The master control terminal sends the conference status data to the backup control terminal via a long connection.

[0008] Fourthly, embodiments of this application provide a backup control terminal, which is a backup control terminal in a conference system, the conference system further including a main control terminal; the backup control terminal includes: an acquisition unit, a backup unit, and a receiving unit; The acquisition unit is used to acquire first metadata from the change record table, wherein the first metadata is the metadata of the first business data that has changed in the first data table, and the first metadata is written to the change record table by the main control terminal when the first business data changes, and the first data table is any data table related to the meeting; The backup unit is used to back up the first business data based on the first metadata and the first data table; The receiving unit is used to receive the conference status data of the conference from the master control terminal via a long connection.

[0009] Fifthly, embodiments of this application provide a master control terminal, which is the master control terminal in a conference system, and the conference system further includes a backup control terminal; the master control terminal includes: a writing unit and a sending unit; The writing unit is used to write the first metadata of the first business data to the change record table in response to a change in the first data table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting. The sending unit is used to send the conference status data of the conference to the backup control terminal via a long connection.

[0010] Sixthly, embodiments of this application provide a conference system, which includes a main control terminal and a backup control terminal; The main control terminal is used to write the first metadata of the first business data to the change record table in response to a change in the first data table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting. The backup control terminal is used to obtain the first metadata from the change record table; The backup control terminal is used to back up the first business data based on the first metadata and the first data table; The master control terminal is used to send the conference status data of the conference to the backup control terminal via a long connection.

[0011] In a seventh aspect, embodiments of this application provide an electronic device, including: a processor and a memory, the processor being connected to the memory, the memory being used to store a computer program, and the processor being used to execute the computer program stored in the memory, so that the electronic device performs the method as described in the first aspect, the second aspect, or the third aspect.

[0012] Eighthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the methods described in the first, second, or third aspects.

[0013] Ninthly, embodiments of this application provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the methods described in the first, second, or third aspects.

[0014] Implementing the embodiments of this application has the following beneficial effects: As can be seen in this embodiment, when the business data of the meeting changes, the master control end writes the metadata of the business data into the change record table, instead of directly synchronizing the business data to the backup control end. The backup control end uses its own processing resources to retrieve the metadata from the change record table and synchronize the business data. Since the main purpose of the backup control end is backup, it has a large amount of idle processing resources, enabling it to quickly synchronize the business data and achieve real-time synchronization, thus improving the efficiency of business data synchronization. Furthermore, the master control end synchronizes the meeting status data in the meeting via a long connection. Since meeting status data is lightweight, the master control end can synchronize the meeting status data in the meeting to the backup control end in real time via a long connection. Therefore, this application, through a specially designed dual-channel collaborative architecture, can synchronize all meeting business data and meeting status data to the backup control end in real time, improving the efficiency of data synchronization. Furthermore, since the backup control unit can obtain not only business data but also meeting status data in real time, it can acquire more granular data related to the meeting. In the event of a failure of the primary control unit, the backup control unit can utilize the meeting's business data and meeting status data to achieve more refined takeover of the meeting. This ensures that the meeting running on the backup control unit after takeover is consistent with the meeting running on the primary control unit before the failure, improving the granularity of fault takeover and enhancing the user's meeting experience. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0016] Figure 1 A schematic diagram of a conference system provided in an embodiment of this application; Figure 2 A schematic diagram of another conference system provided in the embodiments of this application; Figure 3 A flowchart illustrating a data processing method provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating incremental metadata collection using a trigger on a data table, as provided in an embodiment of this application. Figure 5 This is a schematic diagram illustrating polling change records according to an embodiment of this application. Figure 6 This is a schematic diagram illustrating the playback of metadata, provided as an embodiment of this application. Figure 7A schematic diagram illustrating real-time synchronization of meeting status data via a long connection, provided as an embodiment of this application; Figure 8 This is a schematic diagram illustrating the processing of check-in information under normal operation and under fault conditions of the main control terminal, as provided in an embodiment of this application. Figure 9 This is a schematic diagram illustrating the processing of voting information under normal operation and under fault conditions of the main control terminal, as provided in an embodiment of this application. Figure 10 A schematic diagram illustrating a fault detection and conference takeover provided in an embodiment of this application; Figure 11 A schematic diagram illustrating another conference takeover provided in this application embodiment; Figure 12 A schematic diagram of a backup control terminal provided in an embodiment of this application; Figure 13 A schematic diagram of a master control terminal provided in an embodiment of this application; Figure 14 A schematic diagram of yet another conference system provided in this application embodiment; Figure 15 This is a schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] 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, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The terms "first," "second," "third," and "fourth," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0019] In this document, the term "embodiment" means that a particular feature, result, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] See Figure 1 , Figure 1 This is a schematic diagram of a conference system provided in an embodiment of this application.

[0021] For example, such as Figure 1 As shown, the conference system includes a master control unit and a backup control unit. The master control unit includes a database and a change log table (DataBackup). The database includes multiple tables used to record business data generated during the conference, such as... Figure 1 The diagram shows a first data table, a second data table, ... . The backup control end includes a backup database, which can be understood as a backup database corresponding to the database on the main control end. Therefore, the backup database includes a first backup data table, a second backup data table, ... corresponding to the aforementioned first data table, second data table, ... It is understood that the aforementioned first data table, second data table, ... can be part or all of the data tables used to record business data for the meeting; this application does not limit this.

[0022] It is understood that the main control terminal in this application is the terminal device used to control the meeting in the conference system. For example, the main control terminal is a computer, terminal device, PC, etc., that the meeting host can operate. The backup control terminal is a backup device for the main control terminal. When the main control terminal fails to control the meeting, the host can activate the backup control terminal to control the meeting.

[0023] It should be noted that the master control terminal in this application can also be called the master control node, master node, or master control service node. These names are essentially the same and do not need to be distinguished. Similarly, the backup control terminal can also be called the backup control node, backup node, or backup control service node. These names are also essentially the same and do not need to be distinguished.

[0024] In addition, both the main control terminal and the backup control terminal are pre-installed with meeting-related applications. The meeting host can start a meeting by operating the meeting application on the main control terminal. During the meeting, business data and meeting status data related to the meeting will be generated. The main control terminal will store the business data in a data table in its database and send the meeting status data to the backup control terminal for backup via a long connection.

[0025] Optionally, the master controller can pre-create triggers on the database tables, for example, such as Figure 1 As shown, a first trigger is created on the first data table, a second trigger is created on the second data table, and so on. Therefore, the master terminal can monitor changes to the data tables through the triggers of the data tables.

[0026] For example, such as Figure 1 As shown, using Figure 1 In the conference system shown, when the first data table changes during the conference, the master control terminal detects the change in the first business data in the first data table through the first trigger, obtains the first metadata of the first business data, and writes the first metadata to the change record table (DataBackup). Correspondingly, the backup control terminal obtains the first metadata from the change record table (DataBackup), and backs up the first business data in the first backup data table of the backup control terminal based on the first metadata and the first data table.

[0027] Simultaneously, the master control terminal can also send conference status data to the backup control terminal via a persistent connection. Optionally, the persistent connection in this application can be any type of persistent connection; for ease of understanding, this application will primarily use a WebSocket connection as an example for explanation.

[0028] See Figure 2 , Figure 2 This is a schematic diagram of another conference system provided in an embodiment of this application.

[0029] For example, such as Figure 2 As shown, the conference system includes a master control unit and a backup control unit. The master control unit includes a database and a change log table (DataBackup). The master control unit includes a database, a change log table (DataBackup), and a status gating module. Optionally, the database of the master control unit includes multiple data tables for recording business data generated during the conference, for example... Figure 1 The diagram shows a first data table, a second data table, ... . The backup control end includes a backup database, which can be understood as a backup database corresponding to the database on the main control end. Therefore, the backup database includes a first backup data table, a second backup data table, ... corresponding to the aforementioned first data table, second data table, ... It is understood that the aforementioned first data table, second data table, ... can be part or all of the data tables used to record business data for the meeting; this application does not limit this.

[0030] In addition, the backup control unit also includes a polling module, a thread-safe queue, a playback module, a meeting status data receiving module, a fault detection module, and a takeover module. Optionally, the polling module is configured with a data retrieval thread, and the playback module is configured with a playback thread.

[0031] Optionally, the data retrieval thread of the polling module is used to poll the change record table to obtain the metadata written into the change record table; the playback thread of the playback module is used to play back the metadata obtained by the data retrieval thread of the polling module to back up the business data of the metadata; the fault detection module is used to obtain the number of polling anomalies when the polling module polls the change record table, and to monitor whether the long connection between the backup control end and the master control end is broken; the takeover module is used to take over the meeting based on the backed-up meeting status data and the backed-up meeting business data in response to the number of polling anomalies exceeding the threshold and / or the long connection being broken.

[0032] For example, such as Figure 2 As shown, using Figure 2 In the conference system shown, when the first data table changes during the conference, the master control terminal detects the change in the first business data in the first data table through the first trigger and obtains the first metadata of the first business data. Then, the first trigger determines whether incremental synchronization of the first data table is enabled through the state gating module. In response to the first data table enabling incremental synchronization, the first trigger writes the first metadata to the change record table (DataBackup). Correspondingly, the backup control terminal polls the change record table (DataBackup) through the data retrieval thread of the polling module and retrieves the first metadata from the change record table (DataBackup) through the data retrieval thread of the polling module. Then, the first metadata is stored in a thread-safe queue and retrieved from the thread-safe queue. Further, the backup control terminal replays the first metadata through the playback module (i.e., through the playback thread of the playback module), and during the playback process, it uses the first data table to back up the first business data in the first backup data table of the backup control terminal.

[0033] Furthermore, the master control unit sends meeting status data during the meeting to the backup control unit via a long connection. Correspondingly, the backup control unit receives the meeting status data through the meeting status data receiving module and caches the meeting status data locally.

[0034] Furthermore, the backup control unit also uses a fault detection module to detect whether the primary control unit is faulty. Specifically, the fault detection module obtains the number of times the polling module fails to poll the change record table, and monitors whether the long connection between the primary and backup control units is broken. If the number of polling failures exceeds a threshold and / or the long connection between the primary and backup control units is broken, the backup control unit determines that the primary control unit is faulty. Then, the backup control unit uses a takeover module to take over the meetings hosted by the primary control unit. Specifically, the takeover module retrieves the backup meeting's business data from the backup database on the backup control unit, and retrieves meeting status data from the local cache. Using the business data and meeting status data, it takes over the meetings, ensuring seamless meeting switching.

[0035] It can be seen that, based on Figure 1 and Figure 2 The illustrated conference system architecture, when changes occur in the conference's business data, the master control end writes the metadata of the business data to the change record table. Instead of directly synchronizing the business data to the backup control end, the backup control end utilizes its own processing resources to retrieve the metadata from the change record table and synchronize the business data. Since the primary purpose of the backup control end is backup, it has a large amount of idle processing resources, enabling rapid synchronization of business data and achieving real-time synchronization, thus improving the efficiency of business data synchronization. Furthermore, the master control end synchronizes conference status data via long-lived connections. Since conference status data is lightweight, the master control end can synchronize conference status data to the backup control end in real-time via long-lived connections. Therefore, this application, through a specially designed dual-channel collaborative architecture, can synchronize all conference business data and conference status data to the backup control end in real-time, improving data synchronization efficiency. Furthermore, since the backup control unit can obtain not only business data but also meeting status data in real time, it can acquire more granular data related to the meeting. In the event of a failure of the primary control unit, the backup control unit can utilize the meeting's business data and meeting status data to achieve more refined takeover of the meeting. This ensures that the meeting running on the backup control unit after takeover is consistent with the meeting running on the primary control unit before the failure, improving the granularity of fault takeover and enhancing the user's meeting experience.

[0036] See Figure 3 , Figure 3 This is a flowchart illustrating a data processing method provided in an embodiment of this application. The data processing method is applied to the aforementioned conference system. The method includes, but is not limited to, the following steps: 301: In response to a change in the first data table, the master control terminal writes the first metadata of the first business data to the change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting.

[0037] Optionally, the data tables related to the meeting are some or all of the data tables in the database of the master control terminal used to store (or persistently store) the business data generated during the meeting process.

[0038] Optionally, data tables related to the meeting can be pre-configured. For example, a list of hot-standby tables can be pre-configured. Specifically, the identifiers (e.g., table names, primary keys, etc.) of the meeting-related data tables are recorded in the hot-standby table list, and this list is written to the configuration file on the main control terminal. Therefore, when the main control terminal starts, it reads the hot-standby table list from the configuration file and determines the meeting-related data tables based on this list.

[0039] Furthermore, the master control unit pre-creates triggers on each data table related to the meeting. For example, the master control unit identifies each meeting-related data table based on the table identifiers in the hot standby list and creates a trigger on each meeting-related data table. For instance, a first trigger is created on the first data table. This allows the master control unit to monitor changes to the first data table through the first trigger.

[0040] For example, when the master control terminal detects a change in the first data table through the first trigger, it obtains the first metadata of the first business data, where the first business data is the business data that has changed in the first data table. Specifically, the master control terminal obtains the first metadata of the first business data through the first trigger.

[0041] Optionally, the types of changes to the first data table include, but are not limited to: Insert (or new addition), Delete, Update, and Batch changes. To distinguish them from batch changes, this application collectively refers to Insert (or new addition), Delete, and Update as ordinary changes.

[0042] Regarding batch changes, it should be noted that due to the special nature of meetings, in some cases, multiple copies of business data stored in the database tables on the main control side may need to be changed in batches. These batch changes include batch deletion, batch update, and batch insertion. For ease of distinction, this application refers to the business data to be changed in a batch as "batch business data." The changes to the batch business data are achieved by executing the corresponding batch change operations. For example, for batch deletion, a batch deletion operation is performed to delete the batch business data, and so on.

[0043] For example, if a delegation leaves or is removed from a meeting midway through, all of that delegation's meeting information (such as attendance records, access permissions for the meeting equipment used, etc.) needs to be deleted—that is, all of that delegation's meeting information stored in the data table needs to be removed. Deleting the meeting information for that delegation individually would require deleting the meeting information for each member of the delegation separately, a slow process that could disrupt the normal operation of the meeting. Therefore, for this special case, a batch deletion method can be used to delete the delegation's meeting information in batches. For instance, if the delegation's attendance information is stored in rows A to B of the attendance record table, then a batch deletion method can be used to delete all of the delegation's attendance information from row A to row B. The explanations for batch updates, batch inserts, and batch deletions are similar and will not be repeated.

[0044] Optionally, when the change type of the first data table is insertion, the aforementioned first business data is newly inserted (or added) business data into the first data table. Optionally, when the change type of the first data table is deletion, the first business data is data deleted from the first data table. Optionally, when the change type of the first data table is update, the first business data is data in the first data table that has been updated. When the change type of the first data table is batch change, the first business data is one piece of business data in a batch of business data that undergoes batch changes to the first data table.

[0045] The aforementioned first metadata includes, but is not limited to: table name, primary key, and operation type. The table name refers to the name of the first data table containing the first business data; the primary key is the primary key of the first business data in the first data table; and the operation type refers to the type of change to the first business data, which can also be understood as the type of change to the first data table.

[0046] It should be noted that when the change type of the first data table is a batch change, the aforementioned first metadata is essentially the metadata corresponding to that batch change, not the metadata of a single business data item within the batch of business data changed by that batch change. Therefore, when the change type of the first data table is a batch change, the table name in the first metadata is the table name of the table containing the batch of business data being changed (i.e., the table name of the first data table), the primary key is the primary key range formed by the primary keys of the batch of business data, and the operation type is that batch change.

[0047] For example, to change the batch change to batch delete data from rows 1 to 100 in the sign-in record table, the first metadata is: tableName: Sign-in record table; operation: BATCH_DELETE; condition: "id BETWEEN 1 AND 100".

[0048] Optionally, in one embodiment of this application, a large amount of business data for the meeting is pre-imported before the meeting begins (which can also be understood as the meeting preparation stage). For example, the meeting host may import delegation member information in batches. This business data is pre-imported into the main control terminal's data table, so the data table may change during this stage. Triggers on the data table can also detect these changes. If the triggers write the metadata of this business data to the change record table at this time, the change record table will cache a large amount of metadata in a short period. The backup control terminal may not be able to consume this metadata in time, and therefore cannot back up the business data written by the main control terminal in a timely manner. Secondly, this business data is pre-imported offline. Since the meeting has not yet started, there is ample time to back up this business data, such as performing a full backup, i.e., directly backing up the business data to the backup control terminal. Therefore, different backup methods are used to back up the business data before and during the meeting. In addition to pre-creating triggers on the data table, the master control unit also adds a field (e.g., DatabaseStatus) to the data table. The value of this field indicates whether a full backup or an incremental backup is performed on the changed business data. Optionally, the full backup in this application primarily targets the backup of business data before the meeting, i.e., a backup method where the business data is directly and fully synchronized to the backup control unit. The incremental backup in this application primarily targets the backup of business data during the meeting, i.e., a backup method where the business data is backed up by writing metadata of the changed business data into the change record table.

[0049] For example, if the above field value is a first preset value, a full backup of the changed business data is instructed to be performed; if the above field value is a second preset value, an incremental backup of the changed business data is instructed to be performed.

[0050] In addition, for ease of distinction, the DatabaseStatus field newly added to the first data table will be referred to as the first field.

[0051] Therefore, before writing the first metadata of the first business data into the change record table, the master control terminal first obtains the field value of the first field. If the first field value is a first preset value, it is determined that the first business data is business data generated during pre-meeting preparation, and the first business data is fully synchronized to the backup control terminal, i.e., the business data is directly synchronized. If the first field value is a second preset value, it is determined that the first business data is business data generated during the meeting, and the first metadata is written into the change record table, thus modifying the first business data through the change record table.

[0052] Optionally, the first preset value can be 0, false, or other values, and the second preset value can be 1, true, or other values. This application does not limit the specific values ​​of the first and second preset values.

[0053] It should be noted that the value of the first field mentioned above can be set by the meeting host. When importing business data for the meeting during the pre-meeting preparation stage, the value of the first field is set to the first preset value. In this way, the data generated during the pre-meeting preparation will be backed up through full synchronization. When the pre-meeting preparation is complete and the meeting is ready to start, the meeting host can set the value of the first field to the second preset value. In this way, when the first data table changes, hot backup of the business data can be achieved through incremental backup.

[0054] Furthermore, since this application involves batch changes to data tables, although the batch change (or the SQL statements related to the batch change) is only generated once, during the process of performing batch changes on the data tables, it is necessary to modify each piece of business data related to the batch change in the data tables. For example, for batch deletion, business data needs to be deleted one by one. Therefore, during the process of performing batch changes on the business data, the triggers of this data table will monitor the changes to each piece of business data in the batch. If the metadata of each piece of business data is written to the change record table for each change, the intended effect of concise modification as a batch change is not achieved.

[0055] Therefore, in one embodiment of this application, when the field value of the first field is a second preset value, before writing the first metadata to the change record table, the master control terminal will also determine whether the change type of the first data table is a batch change.

[0056] For example, the value of a second field in the first data table is obtained, where the value of the second field indicates whether the change type of the first data table is a batch change. Specifically, the main control terminal also pre-adds a field to each data table to record whether the change of each data table is a batch change. More specifically, when the field value is a third preset value, it indicates that the change of the data table is a batch change. When the field value is a fourth preset value, it indicates that the change of the data table is not a batch change. Finally, based on the value of the second field and the exclusion list, it is determined whether to write the first metadata to the change record table, where the exclusion list is used to record the data tables that have undergone batch changes.

[0057] For example, in response to the field value of the second field being a third preset value, where the third preset value indicates that the change type of the first data table is a batch change, the first business data is one of the business data in the batch business data to be changed in this batch change. Then, the main control terminal determines whether the first data table is recorded in the exclusion list, that is, whether the first data table is in the exclusion list. In response to the exclusion list recording the first data table, it means that during the batch change process, before changing the first business data, other business data in the batch business data have been changed, and when changing other business data, the first metadata has been written to the change record table. That is, the first business data is not the first business data to be changed in the batch change process, so the first metadata is ignored, that is, the first metadata corresponding to the batch change is not written to the change record table. If the first data table is not recorded in the exclusion list, it means that the first business data is the first business data to be changed during the batch change process. The first metadata is written to the change record table, and the first data table is added to the exclusion list. In this way, when other data in the batch business data other than the first business data is changed, the first metadata will not be written to the change record table, thereby avoiding writing too much invalid metadata to the change record table, which may cause invalid synchronization or synchronization failure.

[0058] For example, when the batch change to the first data table involves deleting business data from row 1 to row 100, where the first business data is row 3, the business data from row 1 to row 100 will be deleted sequentially during the batch change process. When the first row of business data is deleted (the first deletion), this first metadata is not recorded in the change record table. Therefore, when deleting the first row, the first metadata corresponding to this batch change is written to the change record table, and the first data table is added to the exclusion list. When deleting rows 2 to 100 subsequently, because the first data table is in the exclusion list, this first metadata will not be written to the change record table again. When the backup control end backs up this batch of business data, it only reads one metadata copy for this batch change. Using this single metadata copy, it can perform the same batch change operation as the master control end, synchronously backing up the corresponding batch of business data, thus avoiding writing too much invalid metadata, which could lead to invalid synchronization or synchronization failure.

[0059] For example, in response to the field value of the second field being a fourth preset value, wherein the fourth preset value is used to indicate that the change type of the first data table is not a batch change, that is, to indicate that the change of the first data table is a normal change, the first metadata can be directly written to the change record table, that is, the first metadata is directly written to the change record table.

[0060] 302: The backup control terminal obtains the first metadata from the change record table.

[0061] For example, the backup control terminal obtains the aforementioned first metadata by polling the change record table.

[0062] The aforementioned first metadata is obtained from the current polling of the change record table. It should be noted that before the backup control end polls the change record table for the current time, it will also perform the previous polling of the change record table, and the time interval between the previous polling and the current polling is determined by the polling result of the previous polling of the change record table.

[0063] For example, in response to the previous polling of the change record table yielding new metadata from the change records (i.e., the previous polling result was that new metadata was found in the change records), the backup control terminal performs the current polling of the change record table after a first time interval to obtain the new metadata corresponding to the current polling. The new metadata corresponding to the current polling includes the first metadata. That is, if new metadata was found in the previous polling, the time interval between the previous polling and the current polling is the first time interval. In response to the previous polling of the change record table not yielding new metadata from the change records (i.e., the previous polling result was that no new metadata was found in the change records), the backup control terminal performs the current polling of the change record table after a second time interval to obtain the new metadata corresponding to the current polling. The new metadata corresponding to the current polling includes the first metadata. That is, if no new metadata was found in the previous polling, the time interval between the previous polling and the current polling is the second time interval.

[0064] Optionally, the first duration is longer than the second duration, and the second duration is not zero. For example, the first duration can be 80ms, the second duration can be 20ms, and so on. This application does not limit the values ​​of the first and second durations. The reason for designing the second duration to be non-zero is that if no new metadata is found in the current polling, it is not necessary to immediately start the next polling. This is because it takes time for the master control end to generate new business data. Therefore, by designing a non-zero second duration, we wait for the master control end to generate new business data, allowing a certain amount of new metadata to accumulate in the change record table, so that new metadata can be polled in the next polling. However, the waiting time cannot be too long, otherwise the latest metadata cannot be polled from the change record table in a timely manner. Therefore, the second duration is designed to be a slightly small, but non-zero value. Furthermore, the reason for designing the first duration to be longer than the second duration is that after the backup control end polls for new metadata, it also stores the new metadata in a queue. The new metadata is then consumed gradually through the queue for backup. However, the length of the queue is limited, and consuming metadata from the queue also takes time. Therefore, after polling for new metadata from the change record table and storing it in the queue, a relatively longer waiting period is required before polling again. This allows sufficient time to consume metadata from the queue and avoids metadata congestion in the queue, which could lead to some metadata not being consumed in a timely manner. Therefore, the first duration is designed to be a slightly larger value, hence the first duration is longer than the second duration.

[0065] Specifically, when the backup control terminal performs the last polling of the change record table, it primarily polls the change record table by comparing the size of the primary key of each metadata element in the table. For example, during the last polling of the change record table, the backup control terminal iterates through the primary keys of the metadata in the change record table to determine if there exists a primary key greater than a first primary key in the change record table at the time of the last polling. The first primary key is the largest primary key among the new metadata polled in previous polling sessions before the last polling of the change record table by the backup control terminal. In other words, the first primary key is the largest primary key among the new metadata polled in previous polling sessions. For instance, if new metadata was polled in the previous poll, then the first primary key is the largest primary key among the new metadata polled in that previous poll; or, if no new metadata was polled in the previous poll, but new metadata was polled in the previous two polls, then the first primary key is the largest primary key among the new metadata polled in the previous two polls. In response to the absence of a primary key greater than the first primary key, the backup control terminal determines that no new metadata was retrieved from the change record table during the previous polling. In response to the presence of a primary key greater than the first primary key, the backup control terminal determines that new metadata was retrieved from the change record table during the previous polling. The new metadata retrieved from the change record table during the previous polling is the metadata in the change record table whose primary key is greater than the first primary key, that is, the metadata in the change record table whose primary key is greater than the first primary key is used as the new metadata retrieved during the previous polling.

[0066] As can be seen, when polling the change record table, this application designs different waiting times for the next poll based on the polling results. By designing this adaptive polling mechanism, the latest metadata can be polled from the change record table in a timely manner, and the latest metadata can be consumed in a timely manner, ensuring the success rate of data backup.

[0067] It should be noted that the above is only an example of the first metadata being obtained in the current poll. Of course, in actual applications, the first metadata may not be obtained in the current poll. In this case, if the first metadata cannot be obtained in the current poll, the backup control end will poll the change record table again after the second time interval until the first metadata is obtained. The first metadata will then be used to back up the first business data.

[0068] Specifically, when the backup control end polls the change record table, it does so through its polling module. More specifically, it polls the change record table through data retrieval threads within the polling module. The number of data retrieval threads can be one or more, and this application does not limit this. Optionally, when there are multiple data retrieval threads, they can continuously poll the metadata in the change record table to obtain the latest metadata. This allows the change process of the business data in the master control end's data table to be recorded, not just the final change result. For example, if the value of a field in a data table changes from A to B, and then to C, the existing data synchronization method will only synchronize the change from A to C to the backup control end, failing to record the intermediate change process. However, in the synchronization method of this application, when a field value changes from A to B, the metadata of the change from A to B is written to the change record table. Since multiple threads on the backup control end continuously poll the metadata in the change record table, they immediately detect the field value change, poll the metadata of the change from A to B, and back up this change process on the backup control end. When the field value changes from B to C, the metadata of the change from B to C is also polled, and this change process is backed up on the backup control end. In this way, the backup control end can back up the entire process of the field value changing from A to B and then to C. It should be noted that this application needs to back up the entire change process, not just the final result, because for meetings, due to the special nature of meetings, the entire change process of the meeting's business data is meaningful and needs to be backed up. For example, if a meeting participant changes from delegation A to representative B, and finally to representative C, this entire process needs to be recorded to know the complete change status of the participating delegations.

[0069] 303: The backup control terminal backs up the first business data based on the first metadata and the first data table.

[0070] For example, the backup control end stores the new metadata obtained each time it is polled into a first queue, which can also be called the thread-safe queue mentioned above. After obtaining the first metadata, the backup control end stores it in the first queue. Then, the backup control end consumes the first metadata from the first queue according to the consumption order of the queues.

[0071] Furthermore, the backup control unit determines the change type of the first data table based on the first metadata. Then, the backup control unit backs up the first business data based on the change type and the first data table.

[0072] Optionally, in response to the change type being insertion, i.e., the first business data being newly inserted into the first data table, the first business data is read from the first data table based on the first metadata. Specifically, the first business data can be read from the row corresponding to the primary key in the first data table using the primary key and table name in the first metadata. Then, the first business data is written to the first backup data table maintained by the backup control terminal, which corresponds to the first data table. This first backup data table is used to back up the business data in the first data table.

[0073] Optionally, in response to the change type being an update, i.e., the first business data is the updated data in the first data table, or the first business data is the updated business data in the first data table, the backup control terminal reads the first business data from the first data table based on the first metadata, and updates the second business data to the first business data in the first backup data table, wherein the second business data is the business data of the first business data before the first data table was updated.

[0074] Optionally, in response to the change type being deletion, i.e., the first business data being business data deleted from the first data table, the backup control terminal deletes the first business data from the first backup data table.

[0075] Optionally, in response to the change type being a batch change, i.e., the first business data being one of the batch business data in the first data table that has undergone batch changes, the backup control terminal performs a batch change operation corresponding to the batch change in the first backup data table based on the first metadata, thereby achieving the backup of the batch business data corresponding to the batch operation in the first backup data table, and thus achieving the backup of the first business data.

[0076] It is understandable that backing up the first business data using the first metadata is equivalent to replaying the change process of the first business data using the first metadata, and then modifying the first business data through replay. Optionally, the replay of the changes to the business data on the backup control end is implemented through a replay module on the backup control end, which includes a replay thread. Therefore, the backup control end replays the first metadata through the replay thread to obtain the change process of the first business data, and backs up the first business data in the first backup data table based on the change process. Therefore, when backing up business data with change types of insertion or update, through the replay mechanism, no matter how many times the same metadata is backed up, the final backup result is consistent. Therefore, the replay mechanism is inherently idempotent when backing up insertion and update business data, ensuring the consistency of the backup.

[0077] Finally, after backing up the backup control unit using the first metadata in the change record table, the backup control unit can notify the master control unit to delete the first metadata from the change record table so as to release the consumed metadata in the change record table in a timely manner.

[0078] 304: The master control terminal sends the conference status data of the conference to the backup control terminal through a long connection.

[0079] It is understood that in this application, in addition to backing up the conference's business data to the backup control end, the master control end will also back up the conference's status data to the backup control end via a long connection. Optionally, the aforementioned long connection can be any type of long connection; for example, the long connection can be a WebSocket connection.

[0080] Specifically, the master control unit writes meeting status data to the meeting log, which records the meeting status data monitored by the master control unit. Then, the backup unit subscribes to the meeting log, detects the meeting status data written to the meeting log by the master control unit, and reads the meeting status data from the meeting log through a long connection.

[0081] Optionally, the business data of the meeting involved in this application includes, but is not limited to: meeting information, information of the meeting delegates participating in the meeting, meeting agenda information, meeting topic information, meeting attendance information, and meeting voting information. The meeting attendance information includes attendance records for all topics from the start of the meeting to the current stage; the voting information includes voting records for all topics from the start of the meeting to the current stage. Therefore, the database at the main control end stores the full amount of attendance information and the full amount of voting information.

[0082] Optionally, the meeting status data involved in this application includes, but is not limited to: the operating status of meeting-related equipment, the meeting's attendance status and attendance detail snapshot, and the meeting's voting status and voting detail snapshot. Attendance status refers to the attendance status for the current topic, which includes either attendance in progress or attendance completed; the attendance detail snapshot records the attendance information for the current topic. Voting status refers to the voting status for the current topic, which includes either voting in progress or voting completed; the voting detail snapshot records the voting information for the current topic.

[0083] Optionally, the aforementioned check-in information includes, but is not limited to: a unique identifier for the check-in entity (unit ID), check-in type (unit Type), check-in method (signIn Method), and check-in code (signIn Code). The check-in entity includes the person checking in, the organization checking in, or the seat at the check-in location, etc. The check-in type refers to the type of the check-in entity, including but not limited to: representative, attendee, guest, etc. The check-in method refers to the method by which the check-in entity checks in, including but not limited to: card swiping, QR code scanning, facial recognition, password, one-click check-in, etc. The check-in code refers to the QR code, verification code, card number, or check-in key used by the person checking in, etc.

[0084] Optionally, the voting information mentioned above includes, but is not limited to, the terminal ID used for voting, the terminal type used for voting, and the voting result. The terminals used for voting include, but are not limited to, keypads, voting devices, tablets, and seat terminals. The terminal ID includes, but is not limited to, a number and a device number. The voting result includes, but is not limited to, for example, votes in favor, votes against, abstentions, invalid votes, and no vote cast.

[0085] As can be seen in this embodiment, when the business data of the meeting changes, the master control end writes the metadata of the business data into the change record table, instead of directly synchronizing the business data to the backup control end. The backup control end uses its own processing resources to retrieve the metadata from the change record table and synchronize the business data. Since the main purpose of the backup control end is backup, it has a large amount of idle processing resources, enabling it to quickly synchronize the business data and achieve real-time synchronization, thus improving the efficiency of business data synchronization. Furthermore, the master control end synchronizes the meeting status data in the meeting via a long connection. Since meeting status data is lightweight, the master control end can synchronize the meeting status data in the meeting to the backup control end in real time via a long connection. Therefore, this application, through a specially designed dual-channel collaborative architecture, can synchronize all meeting business data and meeting status data to the backup control end in real time, improving the efficiency of data synchronization. Furthermore, since the backup control unit can obtain not only business data but also meeting status data in real time, it can acquire more granular data related to the meeting. In the event of a failure of the primary control unit, the backup control unit can utilize the meeting's business data and meeting status data to achieve more refined takeover of the meeting. This ensures that the meeting running on the backup control unit after takeover is consistent with the meeting running on the primary control unit before the failure, improving the granularity of fault takeover and enhancing the user's meeting experience.

[0086] In one embodiment of this application, the backup control terminal obtains the number of times polling errors occur when polling the change record table, and monitors whether the long connection between the master control terminal and the backup control terminal is broken. Here, a polling error can be understood as a polling timeout or a polling failure, etc. Optionally, as... Figure 2 As shown, the backup control unit includes a fault detection module. This module can be used to obtain the number of polling anomalies when polling the change record table, and to monitor whether long connections are broken. For example, in response to a long connection break and / or a polling anomaly count exceeding a threshold, the backup control unit takes over the meeting based on the aforementioned meeting status data and the backup meeting's business data. Specifically, it retrieves the meeting's business data (i.e., the current full set of business data for the meeting) from the backup data table corresponding to the main control unit's data table, along with the synchronized meeting status data, and then takes over the meeting.

[0087] As can be seen, in this embodiment, by monitoring the faults of the polling module and the long connection, i.e., dual-link fault monitoring, the risk of missed detection is reduced and the comprehensiveness of fault monitoring is achieved.

[0088] The following section, with reference to the accompanying drawings, describes each step of the data processing in this application.

[0089] See Figure 4 , Figure 4 This illustration shows an incremental metadata collection process performed by a trigger on a data table, which is any data table related to a meeting, as provided in an embodiment of this application. Optionally, the above-mentioned incremental metadata collection process is executed by a trigger on the master control end, and the process includes, but is not limited to, the following steps: 401: The trigger for the data table detected a change to the data table.

[0090] The aforementioned changes include, but are not limited to: insert, update, delete, and batch changes.

[0091] 402: The trigger checks the value of the Database Status field in the data table. If the Database Status field value is a first preset value, the trigger executes step 403. If the Database Status field value is a second preset value, the trigger executes step 404.

[0092] 403: Trigger execution skipped, no data written to the process.

[0093] Among them, "execution skip, no writing process" means that the metadata of the changed business data in the data table is not written to the DataBackup table, but the changed business data is directly synchronized to the backup control end.

[0094] 404: The trigger checks the value of the Batch Status field in the data table to determine if the data table has undergone batch changes. If the Batch Status field value is the third preset value, the trigger executes step 405; if the BatchStatus field value is the fourth preset value, the trigger executes step 406.

[0095] The Batch Status field indicates whether the change type of the data table is a batch change. A third preset value indicates that the change type is a batch change. A fourth preset value indicates that the change type is not a batch change.

[0096] 405: The trigger determines whether the data table is in the exclusion list. If the data table is in the exclusion list, the trigger executes step 403. If the data table is not in the exclusion list, the trigger executes step 406.

[0097] 406: The trigger writes the metadata of the changed business data in the data table to the DataBackup table.

[0098] 407: Trigger execution completed.

[0099] See Figure 5 , Figure 5 This diagram illustrates a polling of change records, as provided in an embodiment of this application. The method is applied to the data retrieval thread of the playback module on the backup control end. The polling process includes, but is not limited to, the following steps: 501: Polling begins.

[0100] 502: Iterate through the primary key (ID) of each metadata in the change record table, determine whether there is metadata in the change record table with a primary key greater than the primary key of the new metadata found in the previous poll during this poll, and use the metadata with a primary key greater than the new metadata found in the previous poll as the new metadata.

[0101] 503: Determine if new metadata exists in the change record table during this polling. If new metadata exists, proceed to step 504; if no new metadata exists, proceed to step 505.

[0102] For example, if the change record table contains metadata with a primary key greater than the primary key of the new metadata found in the previous poll during the current poll, then it is determined that new metadata exists in the change record table during the current poll; otherwise, it is determined that no new metadata exists in the change record table during the current poll.

[0103] 504: Add the new metadata to the thread-safe queue and re-execute step 502 after waiting for the first duration.

[0104] 505: Re-execute step 502 after waiting for the second duration.

[0105] See Figure 6 , Figure 6 This diagram illustrates a method for replaying metadata, as provided in an embodiment of this application. The method is applied to the replay thread of the replay module on the backup control end. The method includes, but is not limited to, the following steps: 601: Start playback.

[0106] 602: Retrieve metadata from the thread-safe queue.

[0107] 603: Determine the change type of the data table on the master control side based on the retrieved metadata.

[0108] 604: In response to a change type of insert, the business data inserted into the data table on the master control side is read using this metadata, and the business data is inserted into the corresponding backup data table on the standby control side.

[0109] 605: In response to a change type of update, the updated business data in the master control terminal's data table is read using this metadata, and the corresponding backup data table in the standby control terminal is updated using this business data.

[0110] 606: In response to a change type of deletion, the corresponding business data is deleted from the backup data table on the backup control side using this metadata.

[0111] 607: In response to a change type of batch change, determine the batch change operation corresponding to the batch change based on the metadata, and execute the batch change operation in the corresponding backup data table on the backup control end.

[0112] 608: The master control terminal deletes the metadata consumed by the backup control terminal from the change log table.

[0113] See Figure 7 , Figure 7 This illustration shows a real-time synchronization of meeting status data via a long connection, as provided in this application embodiment. The meeting status data includes attendance status, voting status, attendance detail snapshots, and voting detail snapshots. The meeting status data synchronization process includes, but is not limited to, the following steps: 701: Meeting begins. The master control terminal sends a meeting start instruction to the backup control terminal.

[0114] For example, the master control terminal can indicate to the backup control terminal that the meeting has started, such as by setting the value of the meeting status field to in progress to indicate that the meeting has started.

[0115] 702: Check-in begins. The main control terminal sends the check-in start status via a long connection.

[0116] For example, the master control terminal sends the current sign-in status to the backup control terminal through the signIn Status field. For instance, the field value of the signIn Status field is set to in progress, thereby synchronizing the current sign-in status to the backup control terminal, so that the backup control terminal can update the sign-in status synchronously.

[0117] 703: Check-in in progress. The main control unit is sending a snapshot of the check-in details via a long connection.

[0118] The check-in details snapshot includes check-in information for the current topic. The check-in information can be referred to in the above description of check-in information, and will not be described again.

[0119] 704: Check-in complete. The main control terminal sends the check-in completion status via a long connection.

[0120] For example, the master control terminal still indicates the current sign-in status through the signIn Status field. For instance, by setting the value of the signIn Status field to "completed," the master control terminal synchronizes the sign-in completion status with the backup control terminal, facilitating the backup control terminal to update the sign-in status synchronously. Furthermore, the master control terminal can also synchronize the sign-in count with the backup control terminal via a persistent connection.

[0121] 705: Voting begins. The master control terminal sends the voting start status via a long connection.

[0122] For example, the master control terminal sends the current voting status to the backup control terminal through the vote Status field. For instance, setting the value of the vote Status field to "in progress" indicates that the voting is currently in progress, and this status can be synchronized to the backup control terminal, making it easier for the backup control terminal to update the voting status synchronously.

[0123] 706: Voting is in progress. The master control terminal sends a snapshot of the voting details via a long connection.

[0124] The voting details snapshot includes voting information for the current issue. The voting information can be referred to in the above description of voting information, and will not be repeated here.

[0125] 707: Voting complete. The master control terminal sends the voting completion status via a long connection.

[0126] For example, the master control terminal sends the current voting status to the backup control terminal through the vote Status field. For instance, setting the value of the vote Status field to "ended" indicates that the voting has ended, and this status can be synchronized to the backup control terminal, making it easier for the backup control terminal to update the voting status synchronously.

[0127] 708: The backup control unit receives the meeting status data synchronized from the master control unit in real time through a long connection, and uses the latest meeting status data received to update the historical meeting status data cached locally.

[0128] See Figure 8 , Figure 8 This is a schematic diagram illustrating how check-in information is processed under normal operating conditions and under fault conditions of the main control terminal, as provided in an embodiment of this application.

[0129] During the normal operation of the main control unit, this process includes, but is not limited to, the following steps: 801: The main control unit detected the sign-in operation of the sign-in subject.

[0130] For example, the main control unit detects that the person checking in signs in by swiping a card or pressing a button, etc.

[0131] 802: When the main control terminal detects the sign-in operation of the sign-in subject, the sign-in record table used to record sign-in information in the main control terminal is changed. The trigger of the sign-in record table detects the change and writes the metadata of the changed sign-in data in the sign-in record table to the change record table DataBackup.

[0132] 803: The backup control end synchronizes the changed sign-in data in the backup data table corresponding to the sign-in record table in the backup end by changing the DataBackup change record table.

[0133] 804: If the master control terminal detects a sign-in operation by the sign-in subject, the master control terminal sends the current sign-in status and the current sign-in details snapshot to the backup control terminal via a WebSocket connection.

[0134] 805: The backup control unit caches the current sign-in status and sign-in detail snapshots locally.

[0135] In the event of a primary control failure, i.e., during the standby control takeover meeting, the handling process includes, but is not limited to, the following steps: 806: The backup control unit reads the takeover context used for sign-in recovery.

[0136] This context includes the current check-in status, the currently checked-in topic, and the number of people who have already checked in. For example, the control unit can read the current check-in status from the locally cached check-in status. Alternatively, it can read the currently checked-in topic and the number of people who have already checked in from the check-in information recorded in the backup data table to obtain the takeover context.

[0137] 807: The backup control unit restores the sign-in parser using the current sign-in detail snapshot.

[0138] 808: The backup control unit sets the check-in status to in progress and continues to receive new check-in information.

[0139] It should be noted that the attendance information synchronized through the DataBackup table in this application is the full attendance information for the entire meeting (including attendance information for the current topic), while the attendance information synchronized through the attendance detail snapshot is the attendance information specific to the current topic. The reason for recording attendance information in the data table and generating an attendance detail snapshot is that attendance information is a very important part of the meeting. Recording attendance information in the data table allows for persistent storage of the attendance information, while recording attendance information specific to the current topic through the attendance detail snapshot makes it very convenient to print the attendance information for the current topic, facilitating the display of the attendance results for that topic.

[0140] See Figure 9 , Figure 9 This is a schematic diagram illustrating the processing of voting information under normal operation and under fault conditions of the main control terminal, as provided in an embodiment of this application.

[0141] During the normal operation of the main control unit, this process includes, but is not limited to, the following steps: 901: The main control unit detected the voting operation of the voting representative.

[0142] 902: When a voting operation is detected on the main control terminal, the voting record table used to record voting information in the main control terminal is changed. The trigger of the voting record table detects the change in the sign-in record table, and the trigger writes the metadata of the changed voting result in the voting record table to the change record table DataBackup.

[0143] 903: The backup control end synchronizes the changed voting results in the backup data table corresponding to the voting record table in the backup end through the change record table DataBackup.

[0144] 904: When the master control terminal detects a voting operation, the voting status changes. The master control terminal sends the current voting status to the backup control terminal via a WebSocket connection. The current voting status includes the voting status (voteStatus) and the voting start time (votestarTtime).

[0145] 905: The backup control unit caches the voting operation status.

[0146] 906: When the master control terminal detects a voting operation, the voting information changes, and the master control terminal sends a snapshot of the current voting details to the backup control terminal via a WebSocket connection.

[0147] 907: The backup control unit caches the current voting details snapshot.

[0148] In the event of a primary control failure, i.e., during the standby control takeover meeting, the handling process includes, but is not limited to, the following steps: 908: The backup control unit reads the takeover context used for voting recovery.

[0149] The aforementioned context of takeover includes, but is not limited to: the issue currently being voted on, the current voting status, and the start time of the vote.

[0150] 909: The backup control unit restores the voting parser using the current voting details snapshot.

[0151] 910: The backup control unit continues to receive new votes or calculates the final voting result.

[0152] It should be noted that the voting information synchronized through the DataBackup table in this application is the full voting information of the entire meeting (including the voting information for the current agenda item), while the voting information synchronized through the voting detail snapshot is the voting information specific to the current agenda item. The reason for recording voting information in the data table and generating a voting detail snapshot is that voting information is a very important part of the meeting. Recording voting information in the data table allows for persistent storage of the voting information, while recording the voting information specific to the current agenda item through the voting detail snapshot makes it very convenient to print the voting information for the current agenda item, facilitating the display of the voting results for that agenda item.

[0153] See Figure 10 , Figure 10 This diagram illustrates a fault detection and conference takeover mechanism provided in an embodiment of this application. The fault detection and conference takeover include, but are not limited to, the following steps: 1001: The backup control unit detects whether the WebSocket connection is broken and whether the number of abnormal polling attempts on the DataBackup change record table exceeds the threshold.

[0154] 1002: The number of WebSocket connection drops and / or errors exceeds the threshold.

[0155] 1003: The backup control unit stops polling the change log table DataBackup and stops receiving meeting status data via WebSocket connection.

[0156] 1004: The backup control unit uses the business data of the meeting backed up in the database and the meeting status data received through the WebSocket connection to assemble a takeover context for meeting takeover.

[0157] 1005: The standby control unit determines whether the takeover context is complete. If yes, in response to the complete takeover context, the standby control unit executes step 1006; if no, in response to the incomplete takeover context, the standby control unit executes step 1010.

[0158] 1006: The backup control unit continues to maintain the conference mode and uses the takeover of the upper and lower units to restore the conference to its state before the failure.

[0159] 1007: The backup control unit is waiting for the equipment related to the meeting to reconnect to the backup control unit.

[0160] 1008: The backup control unit determines whether the critical equipment among the meeting-related devices has been restored. If yes, in response to the restoration of the critical equipment, the backup control unit executes step 1009; if no, in response to the failure to restore the critical equipment, the backup control unit executes step 1010.

[0161] 1009: The backup control unit has completed the takeover of the meeting and resumed the current meeting.

[0162] 1010: The backup control unit takes over the meeting and prioritizes restoring the core processes of the meeting.

[0163] See Figure 11 , Figure 11 This is a schematic diagram illustrating another conference takeover provided in an embodiment of this application. The conference takeover process is applied to the backup control end. The conference takeover process includes, but is not limited to, the following steps: 1101: Begin taking over the context.

[0164] 1102: Obtain the field value of the field used to indicate the validity of the meeting, and determine whether the meeting is valid based on the field value. In response to an invalid meeting, proceed to step 1103; in response to a valid meeting, proceed to step 1104.

[0165] 1103: Restart the meeting.

[0166] 1104: Retrieve the field value of the field used to indicate the validity of the meeting status, and determine whether the meeting status is valid based on the field value. If the meeting status is valid, proceed to step 1105. If the meeting status is invalid, proceed to step 1103.

[0167] 1105: Determine whether the received detail snapshot is complete, where the detail snapshot includes the check-in detail snapshot and the voting detail snapshot. If the detail snapshot is incomplete, proceed to step 1106; if the detail snapshot is complete, proceed to step 1108.

[0168] 1106: Incomplete takeover context.

[0169] 1107: Activate the downgrade takeover mode and prioritize restoring the core processes of the meeting.

[0170] 1108: Full takeover context.

[0171] 1109: Restore system parameters.

[0172] 1110: Resume the meeting, the meeting agenda, and the meeting's topics.

[0173] 1111: Restore the host device for the meeting and restore the meeting mode.

[0174] 1112: Restore the sign-in status using the sign-in details snapshot.

[0175] 1113: Resume sign-in.

[0176] 1114: Restore voting status using a snapshot of voting details.

[0177] 1115: Restore screen event.

[0178] 1116: Waiting for the reconnection of meeting-related equipment.

[0179] 1117: Determine if all devices related to the meeting have successfully reconnected. If all devices have successfully reconnected, proceed to step 1118; if some devices have failed to reconnect, proceed to step 1107.

[0180] 1118: Activate full takeover mode and continue the current meeting.

[0181] See Figure 12 , Figure 12 This is a schematic diagram of a backup control terminal provided in an embodiment of this application. The backup control terminal 1200 includes: an acquisition unit 1201, a backup unit 1202, a receiving unit 1203, and a fault detection unit 1204, wherein: The acquisition unit 1201 is used to acquire first metadata from the change record table, wherein the first metadata is the metadata of the first business data that has changed in the first data table, and the first metadata is written to the change record table by the main control terminal when the first business data changes, and the first data table is any data table related to the meeting; Backup unit 1202 is used to back up the first business data based on the first metadata and the first data table; The receiving unit 1203 is used to receive the conference status data of the conference from the main control terminal through a long connection.

[0182] In one embodiment of this application, the first metadata is obtained by the backup control terminal through the current round of polling of the change record table; before the acquisition unit 1201 acquires the first metadata from the change record table, the acquisition unit 1201 is further configured to: In response to the previous polling of the change record table to retrieve new metadata from the change record, the change record table is polled again after a first time interval to obtain new metadata corresponding to the current polling, wherein the new metadata corresponding to the current polling includes the first metadata; In response to the fact that no new metadata was found from the change records during the previous polling of the change record table, the change record table is polled again after a second time period to obtain new metadata corresponding to the current polling, wherein the new metadata corresponding to the current polling includes the first metadata; In one embodiment of this application, when the acquisition unit 1201 performs the last polling of the change record table, the acquisition unit is further configured to: The primary key of the metadata in the change record table is traversed to determine whether there is a primary key greater than the first primary key in the change record table when the change record table was last polled. The first primary key is the largest primary key among the new metadata polled when the change record table was polled before the last polling of the change record table by the backup control end. In response to the absence of a primary key greater than the first primary key, it is determined that no new metadata was polled from the change records during the previous polling of the change record table; In response to the existence of a primary key greater than the first primary key, it is determined that new metadata was polled from the change records during the last polling of the change record table, wherein the new metadata polled from the change record table during the last polling is the metadata in the change record table whose primary key is greater than the first primary key.

[0183] In one embodiment of this application, regarding the backup of the first business data based on the first metadata and the first data table, the backup unit 1202 is specifically used for: Store the first metadata in the first queue; Consume the first metadata from the first queue; Based on the first metadata, determine the change type of the first data table; The first business data is backed up based on the change type and the first data table.

[0184] In one embodiment of this application, regarding the backup of the first business data based on the change type and the first data table, the backup unit 1202 is specifically used for: In response to the change type being insert, the first business data is read from the first data table based on the first metadata, and the first business data is written to the first backup data table corresponding to the first data table. In response to the change type being an update, the first business data is read from the first data table based on the first metadata, and the second business data is updated to the first business data in the first backup data table, wherein the second business data is the business data before the first business data is updated; In response to the change type being deletion, the first business data is deleted from the first backup data table; In response to the change type being a batch change, based on the first metadata, a batch change operation corresponding to the batch change is executed in the first backup data table to back up the first business data.

[0185] In one embodiment of this application, the fault detection unit 1204 is used for: The system retrieves the number of polling errors that occur when polling the change record table, and monitors whether the long connection is disconnected. In response to the polling exception occurring more than a threshold and / or the long connection being disconnected, the conference is taken over based on the conference status data and the backed-up business data of the conference.

[0186] In one embodiment of this application, the backup unit 1202 includes a polling module and a playback module, wherein the polling module is configured with a data retrieval thread and the playback module is configured with a playback thread; the fault detection unit 1204 includes a fault detection module and a takeover module. The data retrieval thread of the polling module is used to poll the change record table to retrieve the first metadata from the change record table; The playback thread of the playback module is used to play back the first metadata in order to back up the first business data. The fault detection module is used to obtain the number of times the polling module fails to poll the change record table, and to monitor whether the long connection is disconnected. The takeover module is used to take over the meeting in response to the number of polling anomalies exceeding a threshold and / or the long connection being disconnected, based on the meeting status data and the backed-up business data of the meeting.

[0187] See Figure 13 , Figure 13 This is a schematic diagram of a master control terminal provided in an embodiment of this application. The master control terminal 1300 includes: a writing unit 1301 and a sending unit 1302, wherein: The writing unit 1301 is used to write the first metadata of the first business data to the change record table in response to a change in the first data table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting. The sending unit 1302 is used to send the conference status data of the conference to the backup control terminal via a long connection.

[0188] In one embodiment of this application, before the writing unit 1301 writes the first metadata of the first business data to the change record table, the writing unit 1301 is further configured to: Get the value of the first field of the first field in the first data table; In response to the value of the first field being a first preset value, the first business data is fully synchronized to the backup control terminal; In response to the first field value being a second preset value, the field value of the second field of the first data table is obtained, wherein the field value of the second field is used to indicate whether the change type of the first data table is a batch change; Based on the field value of the second field and the exclusion list, it is determined whether to write the first metadata to the change record table, wherein the exclusion list is used to record data tables that have undergone batch changes.

[0189] In one embodiment of this application, the writing unit 1301, in determining whether to write the first metadata to the change record table based on the field value of the second field and the exclusion list, is specifically used for: In response to the value of the second field being a third preset value, it is determined whether the exclusion list records the first data table, wherein the third preset value is used to indicate that the change type of the first data table is a batch change; in response to the exclusion list recording the first data table, the main control terminal does not write the first metadata to the change record table; in response to the exclusion list not recording the first data table, the main control terminal writes the first metadata to the change record table and adds the first data table to the exclusion list; In response to the second field value being a fourth preset value, the first metadata is written to the change record table, whereby the fourth preset value indicates that the change type of the first data table is not a batch change.

[0190] See Figure 14 , Figure 14 This is a schematic diagram of another conference system provided in an embodiment of this application. The conference system 1400 includes a main control terminal 1401 and a backup control terminal 1402, wherein: The main control terminal 1401 is used to write the first metadata of the first business data to the change record table in response to a change in the first data table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting. The backup control terminal 1402 is used to obtain the first metadata from the change record table; The backup control terminal 1402 is used to back up the first business data based on the first metadata and the first data table; The master control terminal 1401 is used to send the conference status data of the conference to the backup control terminal through a long connection.

[0191] Optionally, for the specific functions of the main control terminal 1401 and the backup control terminal 1402, please refer to the description of the main control terminal and the backup control terminal in the above method embodiments, which will not be described in detail here.

[0192] See Figure 15 , Figure 15 This is a schematic diagram of an electronic device provided in an embodiment of this application. The electronic device 1500 can be the aforementioned main control terminal or backup control terminal.

[0193] Electronic device 1500 includes memory 1501, processor 1502, communication interface 1503, and bus 1504. Memory 1501, processor 1502, and communication interface 1503 are interconnected via bus 1504.

[0194] The memory 1501 can be a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 1501 can store programs; when the electronic device 1500 is the master control terminal, when the program stored in the memory 1501 is executed by the processor 1502, the processor 1502 and the communication interface 1503 are used to execute the various steps executed by the master control terminal in the data processing method of this embodiment. When the electronic device 1500 is the backup control terminal, when the program stored in the memory 1501 is executed by the processor 1502, the processor 1502 and the communication interface 1503 are used to execute the various steps executed by the backup control terminal in the data processing method of this embodiment.

[0195] The processor 1502 may be a general-purpose central processing unit (CPU), microprocessor, application specific integrated circuit (ASIC), graphics processing unit (GPU), or one or more integrated circuits, used to execute relevant programs to implement the data processing method in the method embodiments of this application.

[0196] The processor 1502 can also be an integrated circuit chip with signal processing capabilities. In implementation, each step of the data processing method in this application can be completed by the integrated logic circuitry in the hardware of the processor 1502 or by instructions in software form. The processor 1502 can also be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1501, and processor 1502 reads information from memory 1501 to execute various steps of the data processing method.

[0197] The communication interface 1503 can be a transceiver device such as a transceiver to enable communication between the electronic device 1500 and other devices or communication networks. The communication interface 1503 can also be an input-output interface to enable data transmission between the electronic device 1500 and input-output devices, including but not limited to keyboards, mice, displays, USB flash drives, and hard drives. For example, the processor 1502 can receive signals through the communication interface 1503.

[0198] Bus 1504 may include a pathway for transmitting information between various components of device electronics 1500 (e.g., memory 1501, processor 1502, communication interface 1503).

[0199] It should be noted that, although Figure 15The illustrated electronic device 1500 only shows the memory, processor, and communication interface. However, those skilled in the art should understand that in specific implementations, the electronic device 1500 may also include other devices necessary for normal operation. Furthermore, depending on specific needs, those skilled in the art should understand that the electronic device 1500 may also include hardware devices for implementing other additional functions. Moreover, those skilled in the art should understand that the electronic device 1500 may only include the devices necessary for implementing the embodiments of this application, and may not necessarily include... Figure 15 All the devices shown.

[0200] This application also provides a computer-readable storage medium storing a computer program that is executed by a processor to implement some or all of the steps of any of the data processing methods described in the above method embodiments.

[0201] This application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the data processing methods described in the above method embodiments.

[0202] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0203] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0204] In the several embodiments provided in this application, it should be understood that the disclosed apparatus can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical or other forms.

[0205] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0206] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software program module.

[0207] If the integrated unit is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0208] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage device, which may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0209] The embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data processing method, characterized in that, The method is applied to the backup control terminal of a conference system, which also includes a master control terminal; the method includes: The backup control terminal obtains the first metadata from the change record table. The first metadata is the metadata of the first business data that has changed in the first data table. The first metadata is written to the change record table by the main control terminal when the first business data changes. The first data table is any data table related to the meeting. The backup control terminal backs up the first business data based on the first metadata and the first data table; The backup control terminal receives the conference status data from the master control terminal via a long connection.

2. The method according to claim 1, characterized in that, The first metadata is obtained by the backup control terminal in the current round of polling the change record table; Before the backup control terminal obtains the first metadata from the change record table, the method further includes: In response to the previous polling of the change record table to retrieve new metadata from the change record, the backup control terminal performs the current polling of the change record table after a first time interval to obtain the new metadata corresponding to the current polling, wherein the new metadata corresponding to the current polling includes the first metadata; In response to the fact that no new metadata was found in the change record table during the previous polling, the backup control terminal performs the current polling of the change record table after a second time period to obtain the new metadata corresponding to the current polling, wherein the new metadata corresponding to the current polling includes the first metadata; The first duration is longer than the second duration.

3. The method according to claim 2, characterized in that, When the backup control terminal performs the last polling of the change record table, the method further includes: The backup control terminal iterates through the primary keys of the metadata in the change record table to determine whether there exists a primary key greater than the first primary key in the change record table when the last polling was performed. The first primary key is the largest primary key among the new metadata polled when the backup control terminal polled the change record table before the last polling. In response to the absence of a primary key greater than the first primary key, the backup control terminal determines that no new metadata was polled from the change records during the previous polling of the change record table; In response to the existence of a primary key greater than the first primary key, the backup control terminal determines that new metadata was polled from the change record table during the last poll, wherein the new metadata polled from the change record table during the last poll is the metadata in the change record table whose primary key is greater than the first primary key.

4. The method according to any one of claims 1-3, characterized in that, The backup control terminal backs up the first business data based on the first metadata and the first data table, including: The backup control terminal stores the first metadata in the first queue; The backup control terminal consumes the first metadata from the first queue; The backup control terminal determines the change type of the first data table based on the first metadata; The backup control unit backs up the first business data based on the change type and the first data table.

5. The method according to claim 4, characterized in that, The backup control terminal backs up the first business data based on the change type and the first data table, including: In response to the change type being insert, the first business data is read from the first data table based on the first metadata, and the first business data is written to the first backup data table corresponding to the first data table. In response to the change type being an update, the first business data is read from the first data table based on the first metadata, and the second business data is updated to the first business data in the first backup data table, wherein the second business data is the business data before the first business data is updated; In response to the change type being deletion, the first business data is deleted from the first backup data table; In response to the change type being a batch change, based on the first metadata, a batch change operation corresponding to the batch change is executed in the first backup data table to back up the first business data.

6. The method according to any one of claims 1-5, characterized in that, The method further includes: The backup control terminal obtains the number of polling anomalies when polling the change record table, and monitors whether the long connection is disconnected; In response to the polling exception occurring more than a threshold and / or the long connection being disconnected, the backup control unit takes over the meeting based on the meeting status data and the backed-up meeting service data.

7. The method according to claim 6, characterized in that, The backup control unit includes a polling module, a playback module, a fault detection module, and a takeover module. The polling module is configured with a data retrieval thread, and the playback module is configured with a playback thread. The data retrieval thread of the polling module is used to poll the change record table to retrieve the first metadata from the change record table; The playback thread of the playback module is used to play back the first metadata in order to back up the first business data. The fault detection module is used to obtain the number of times the polling module fails to poll the change record table, and to monitor whether the long connection is disconnected. The takeover module is used to take over the meeting in response to the number of polling anomalies exceeding a threshold and / or the long connection being disconnected, based on the meeting status data and the backed-up business data of the meeting.

8. A data processing method, characterized in that, The method includes: a main control terminal for a conference system, wherein the conference system also includes a backup control terminal; the method comprises: In response to a change in the first data table, the main control terminal writes the first metadata of the first business data into the change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting; The master control terminal sends the conference status data to the backup control terminal via a long connection.

9. The method according to claim 8, characterized in that, Before the master control terminal writes the first metadata of the first business data into the change record table, the method further includes: The main control terminal obtains the value of the first field of the first field of the first data table; In response to the first field value being a first preset value, the master control terminal fully synchronizes the first business data to the backup control terminal, and does not write the first metadata to the change record table; In response to the first field value being a second preset value, the main control terminal obtains the field value of the second field of the first data table, wherein the field value of the second field is used to indicate whether the change type of the first data table is a batch change; The main control terminal determines whether to write the first metadata to the change record table based on the field value of the second field and the exclusion list, wherein the exclusion list is used to record data tables that have undergone batch changes.

10. The method according to claim 9, characterized in that, The main control terminal determines whether to write the first metadata to the change record table based on the field value of the second field and the exclusion list, including: In response to the value of the second field being a third preset value, the main control terminal determines whether the exclusion list records the first data table, the third preset value being used to indicate that the change type of the first data table is a batch change; in response to the exclusion list recording the first data table, the main control terminal does not write the first metadata to the change record table; in response to the exclusion list not recording the first data table, the main control terminal writes the first metadata to the change record table and adds the first data table to the exclusion list; In response to the value of the second field being a fourth preset value, the master control terminal writes the first metadata into the change record table, whereby the fourth preset value is used to indicate that the change type of the first data table is not a batch change.

11. A data processing method, characterized in that, The method is applied to a conference system, which includes a main control terminal and a backup control terminal; the method includes: In response to a change in the first data table, the main control terminal writes the first metadata of the first business data into the change record table, wherein the first business data is the business data that has changed in the first data table, and the first data table is any data table related to the meeting; The backup control terminal obtains the first metadata from the change record table; The backup control terminal backs up the first business data based on the first metadata and the first data table; The master control terminal sends the conference status data to the backup control terminal via a long connection.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1-11.