CN116010378A - Data migration method, device and computer readable storage medium - Google Patents

Abstract

The application provides a data migration method, a data migration device and a computer readable storage medium, which comprise the following steps: starting data migration from the backup database to the main database; receiving a service request, wherein the service request is a request of a currently running application for requesting first target data; and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application. In the scheme, in the process of carrying out data migration from the backup database to the main database, if an application requests first target data, after the first target data is migrated from the backup database to the main database based on a service request, the main database provides the first target data for the requested application, and the first target data is migrated from the backup database to the main database on the premise of ensuring the data use of the application, thereby realizing the data migration from the backup database to the main database without stopping.

Description

Data migration method, device and computer readable storage medium

Technical Field

The present application relates to the field of data processing, and more particularly, to a data migration method, apparatus, and computer readable storage medium.

Background

Data high availability is a key factor in system high availability.

Currently, data high availability generally relies on the data synchronization mechanism of the database system to set up the master and slave libraries. And when the main library and the standby library are isomorphic databases, the mutual switching between the main library and the standby library can be completed depending on a scheme provided by a database manufacturer.

The existing oracle database ensures the synchronization of data through log synchronization between a main node and a standby node, and can realize the rapid switching and disaster recovery of the database. Moreover, the data synchronization implemented in the prior art is only to set up the database on software and does not require any additional purchase of components. The user can realize the synchronization of the main database and the standby database under the condition of little influence on the main database. When the primary and standby databases are switched, the high availability of data can be ensured, and the data difference between the primary and standby machines is limited to the online log part, so that the data is used as a data disaster recovery solution by a plurality of enterprises.

As shown in fig. 1, when the primary and backup databases are heterogeneous databases, the two heterogeneous databases use the primary database under normal service conditions, and for any modification operation to the primary database, the modification operation is synchronized to the backup database by a unidirectional synchronization mechanism of the primary and backup data of the database level provided by the primary database. When the primary database is switched to the backup database, the high availability of data can be ensured, and the data difference between the primary and the backup computers is limited to the online log part. However, when the backup database is switched to the main database, the main database and the backup database are subjected to bidirectional data synchronization due to the non-mature technical scheme.

In the prior art, static migration is adopted from backup database data to main database data. After the shutdown service is interrupted, deleting the data of the main database, and carrying out static data migration through a static data migration tool. However, with this migration approach, application downtime is required and downtime depends on the amount of database data. For a 7 x 24 hour system, service continuity cannot be guaranteed, service interruption is caused, and limitation exists.

Disclosure of Invention

In view of this, the present application provides a data migration method, which solves the problem in the prior art that when data is migrated from a backup database to main data, a shutdown is required to cause service interruption.

In order to achieve the above purpose, the present application provides the following technical solutions:

a data migration method applied to an electronic device, the method comprising:

starting data migration from the backup database to the main database;

receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application.

A data migration apparatus, applied to an electronic device, comprising:

the starting module is used for starting the data migration from the backup database to the main database;

the receiving module is used for receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

and the first migration module is used for migrating the first target data from the backup database to the main database based on the service request so that the main database provides the first target data for the application.

A computer readable storage medium for storing instructions which, when executed by a computer, are to perform a method as described above.

As can be seen from the above technical solution, compared with the prior art, the present application provides a data migration method, which includes: starting data migration from the backup database to the main database; receiving a service request, wherein the service request is a request of a currently running application for requesting first target data; and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application. In the scheme, in the process of carrying out data migration from the backup database to the main database, if an application requests first target data, after the first target data is migrated from the backup database to the main database based on a service request, the main database provides the first target data for the requested application, and the first target data is migrated from the backup database to the main database on the premise of ensuring the data use of the application, thereby realizing the data migration from the backup database to the main database without stopping.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required to be used in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only embodiments of the present application, and that other drawings may be obtained according to the provided drawings without inventive effort to a person skilled in the art.

FIG. 1 is a schematic diagram of an application database structure;

FIG. 2 is a flowchart of an embodiment 1 of a data migration method provided in the present application;

FIG. 3 is a flowchart of an embodiment 2 of a data migration method provided in the present application;

FIG. 4 is a flowchart of an embodiment 3 of a data migration method provided in the present application;

FIG. 5 is a flowchart of an embodiment 4 of a data migration method provided in the present application;

FIG. 6 is a flowchart of an embodiment 5 of a data migration method provided in the present application;

FIG. 7 is a flowchart of an embodiment 6 of a data migration method provided in the present application;

FIG. 8 is a schematic diagram of an embodiment of a data migration apparatus according to the present application;

FIG. 9 is a schematic diagram of another embodiment of a data migration apparatus according to the present application;

Fig. 10 is a schematic structural diagram of an electronic device applied to a data migration apparatus in a usage scenario provided in the present application;

FIG. 11 is a flowchart of an interface module of an electronic device applied to a data migration apparatus in a structure of a usage scenario;

FIG. 12 is a flowchart of an electronic device applied by a data migration apparatus in a configuration of a usage scenario, wherein the sub-module is executed by a ticketing service;

fig. 13 is a flowchart of execution of a ticketing service submodule in a structure of a usage scenario of an electronic device applied to a data migration apparatus provided in the present application;

fig. 14 is a flowchart of an electronic device applied by a data migration apparatus according to the present application executed by a service sub-module in a structure of a usage scenario;

fig. 15 is a flowchart of a second migration module executed by an electronic device of a data migration apparatus application provided in the present application in a structure of a usage scenario.

Detailed Description

Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present disclosure have been shown in the accompanying drawings, it is to be understood that the present disclosure may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustration purposes only and are not intended to limit the scope of the present disclosure.

The term "including" and variations thereof as used herein are intended to be open-ended, i.e., including, but not limited to. The term "based on" is based at least in part on. The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments. Related definitions of other terms will be given in the description below.

It should be noted that the terms "first," "second," and the like in this disclosure are merely used to distinguish between different devices, modules, or units and are not used to define an order or interdependence of functions performed by the devices, modules, or units.

It should be noted that references to "one", "a plurality" and "a plurality" in this disclosure are intended to be illustrative rather than limiting, and those of ordinary skill in the art will appreciate that "one or more" is intended to be understood as "one or more" unless the context clearly indicates otherwise.

It should be noted that, in the embodiments of the present application, a process of performing data migration from a backup database to a primary database is mainly explained. The process of data migration from the primary database to the backup database may refer to a migration manner in the prior art, and this process is not explained in detail in this application.

As shown in fig. 2, a flowchart of an embodiment 1 of a data migration method provided in the present application is applied to an electronic device, where the electronic device is configured to control data of a master database and a slave database, where the control includes writing data, migrating data, and the like, and the method includes the following steps:

step S201: starting data migration from the backup database to the main database;

and starting data migration from the backup database to the main database based on the configured migration parameters.

The configured migration parameters are used for determining time/time when the backup database performs data migration to the main database.

For example, migration may occur at a time when the data storage capacity of the backup database reaches a preset proportion of the total storage space.

For example, the time of migration reaches a contracted migration period.

In specific implementation, the migration parameters can be configured according to actual conditions, and when the operation of the backup database and the main database reaches the conditions specified by the migration parameters, the data migration from the backup database to the main database is automatically started.

Step S202: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

in the process of data migration from the backup database to the main database, the currently running application can also perform a data request on the database.

The application generates a service request when making a data request, wherein the service request is first target data.

It should be noted that, the first target data may also be referred to as active data, where the active data is data used by an application in a data migration process, and the application may request the active data by using a service request manner.

Step S203: and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application.

And after receiving the service request, if the backup database has first target data corresponding to the service request, migrating the first target data into the main database in the process of migrating the data from the backup database to the main database.

In the specific implementation, the first target data is converted into the data service reply, so that the application can continue to use the data in the data migration process, and the data migration without shutdown is realized.

The following embodiments of the migration process will be described in detail, but not described in detail in this embodiment.

It should be noted that, the primary database is used as a database for directly providing data for the application, so that in the process of data migration, the first target data is migrated from the backup database to the primary database, and the primary database provides the first target data for the application, so that the first target data is migrated from the backup database to the primary database on the premise of ensuring the data use of the application, and the data migration without shutdown is realized.

In summary, the data migration method provided in this embodiment includes: starting data migration from the backup database to the main database; receiving a service request, wherein the service request is a request of a currently running application for requesting first target data; and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application. In the scheme, in the process of carrying out data migration from the backup database to the main database, if an application requests first target data, after the first target data is migrated from the backup database to the main database based on a service request, the main database provides the first target data for the requested application, and the first target data is migrated from the backup database to the main database on the premise of ensuring the data use of the application, thereby realizing the data migration from the backup database to the main database without stopping.

As shown in fig. 3, a flowchart of an embodiment 2 of a data migration method is provided, and the method includes the following steps:

step S301: starting data migration from the backup database to the main database;

Step S302: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

step S303: migrating the first target data from the backup database to a primary database based on the service request, such that the primary database provides the first target data to the application;

steps S301 to 303 are identical to steps S201 to 203 in embodiment 1, and are not described in detail in this embodiment.

Step S304: inquiring second target data to be migrated in the backup database;

wherein the second target data is different from the first target data.

In addition to the first target data requested by the currently running application, the backup database also stores second target data, which is not requested by the currently running application.

When the data migration process from the backup database to the main database is started, a data list is generated, wherein the data list contains data to be migrated.

Specifically, the second target data to be migrated is queried in the data list.

The second target data may also be referred to as inactive data, where the inactive data is data that is not used by the application transaction during the data migration process.

Specifically, all second target data to be migrated can be queried in the backup database from near to far based on the date of generation.

In the process of migrating the backup database to the primary database, a time for migrating the data, such as 1 day, 30 days, 100 days, etc., or a specific time, such as 2021, 5 months, 1 day, etc., may be set, and the data generated after the initial date is used as the data to be migrated.

Of course, the time/time of migration data may be determined according to practical situations, which is not limited in this application.

It should be noted that, the migration of the second target data may be started after the migration of the first target data is started, and the migration of the first target data may not be started after the migration of the first target data is completed.

In a specific implementation, whether the time for starting the migration of the second target data is after the migration of the first target data is completed or after the migration of the first target data is started may be set according to actual situations.

Step S305: and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

And according to the generation time of the second target data, sequentially inserting the second target data into the main database from near to far.

The data in the main database is stored according to time, and after the generation time of a piece of second target data is determined, the second target data is inserted into a storage position corresponding to the corresponding time in the main database.

It should be noted that, the steps S304-305 are used for migrating inactive data in the backup database, and the steps S302-303 are used for migrating active data in the backup database, and the migration time of the two data is not limited to the sequence in the embodiment, and in specific implementation, the migration of the inactive data may be performed when the active data is not available, the migration of the active data may be performed when the active data is available, or the migration of the inactive data may be performed at any time when the active data is available.

In specific implementation, the database tables of the main database and the backup database are provided with a field of migration identification, and different values are adopted to represent migrated and non-migrated.

Specifically, data which is within the migration time and for which the migration identification is not migrated is used as the second target data.

Correspondingly, after the second target data is migrated to the main database, the migration identification corresponding to the second target data in the database table in the main database is modified to be migrated.

As one example, a field of the migration identification indicates no migration with 0 and 1 indicates migrated.

In summary, the data migration method provided in this embodiment further includes: inquiring second target data to be migrated in a backup database, wherein the second target data is different from the first target data; and based on the generation time of the second target data, sequentially migrating the second target data to a main database. In the scheme, after the second target data to be migrated in the backup database is queried, the second target data are sequentially migrated to the main database based on the generation time of the second target data, so that active data can be migrated, inactive data can be migrated, active data and inactive data are migrated from the backup database to the main database on the premise of guaranteeing the use of the applied data, the whole data can be gradually migrated from the backup database to the main database, the whole database migration is guaranteed to be finally realized, and the high availability of the whole data is guaranteed.

As shown in fig. 4, a flowchart of an embodiment 3 of a data migration method is provided, and the method includes the following steps:

Step S401: starting data migration from the backup database to the main database;

step S402: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

steps S401 to 402 are identical to steps S201 to 202 in embodiment 1, and are not described in detail in this embodiment.

Step S403: analyzing the service request to obtain a data primary key, wherein the data primary key corresponds to the first target data;

the data primary key is used as a parameter capable of identifying a specific row or column in the database table, and whether corresponding data exist in the database table can be searched based on the data primary key.

Specifically, the service request carries the data primary key of the first target data of the request, and the service request is analyzed to obtain the data primary key.

Wherein the corresponding first target data can be determined based on the data primary key.

Step S404: and migrating the first target data from the backup database to the main database based on the data main key, so that the main database provides the first target data to the application.

And after the first target data corresponding to the data primary key is found in the backup database, the first target data is migrated to the primary database.

Specifically, the specific process of step S404 is as follows:

step S4041: inquiring whether first target data corresponding to the data primary key exists in a primary database;

the main database is a database which is used for providing data and is preferentially selected, so that after the data main key is obtained, the main database is firstly queried, and whether the first target data corresponding to the data main key exists in the main database is queried.

If the first target data exists in the main database, the main database provides the first target data, the first target data is operated in the main database, and the first target data is converted into service data for replying.

Step S4042: and if the first target data does not exist in the main database, migrating the first target data from the backup database to the main database.

If the first target data does not exist in the main database, the first target data exists in the backup database, and the first target data is migrated from the backup database to the main database so that the main database provides the first target data, thereby realizing the operation of the first target data in the main database, converting the first target data into service data and replying

Wherein the service request may be modification data or query data, etc.

As an example, when the service request is to modify the first target data, it is first determined whether the first target data exists in the primary database, and if not, after the active data is migrated from the backup data to the primary database, the first target data in the primary database is modified.

In summary, the data migration method provided in this embodiment includes: analyzing the service request to obtain a data primary key, wherein the data primary key corresponds to the first target data; and migrating the first target data from the backup database to the main database based on the data main key. In the scheme, the data primary key is obtained based on the service request, so that corresponding first target data is determined from the backup database based on the data primary key and is migrated to the primary database, the primary database provides the first target data for the application, and the purpose of maintaining the running of the application without stopping in the data migration process is achieved.

As shown in fig. 5, a flowchart of an embodiment 4 of a data migration method provided in the present application includes the following steps:

Step S501: emptying the main database;

in this application, the data migration of the backup database to the primary database is to perform the primary-backup switching subsequently, but after the primary-backup switching, the current primary database does not perform any transaction, and the data is not trusted, so the primary database needs to be emptied before the data migration of the backup database to the primary database is started.

Specifically, the flushing can be performed by deleting all data.

Of course, other ways of emptying may be used, and the present application is not limited to the manner of emptying.

It should be noted that, in the following step 504, in the process of migrating the first target data in the backup database to the primary database, during the migration process, some data may already be migrated to the primary database, and it may be first determined whether the first target data exists in the primary database based on the service request.

Step S502: starting data migration from the backup database to the main database;

step S503: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

step S504: migrating the first target data from the backup database to a primary database based on the service request, such that the primary database provides the first target data to the application;

Step S505: inquiring second target data to be migrated in the backup database;

step S506: and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

Steps S502-506 are identical to steps S201-305 in embodiment 2, and are not described in detail in this embodiment.

In summary, in the data migration method provided in this embodiment, before starting data migration from the backup database to the primary database, the method further includes: and emptying the main database. In the scheme, before the backup database is started to transfer data to the main database, the main database is emptied, so that the data which is subsequently transferred to the main database is not influenced by the original storage content in the main database.

As shown in fig. 6, a flowchart of an embodiment 5 of a data migration method provided in the present application includes the following steps:

step S601: emptying the main database;

step S602: starting data migration from the backup database to the main database;

steps S601-602 are identical to steps S501-502 in embodiment 4, and are not described in detail in this embodiment.

Step S603: if the current running state of the electronic equipment is in the first state, setting the data migration identification field of the backup database as not migrated, and setting the data migration identification field of the main database as migrated;

When the electronic equipment is in a first state, the backup database is in a normal mode, and the main database is in a migration mode.

Step S604: if the current running state of the electronic equipment is the second state, setting a data migration identification field of the main database to be not migrated;

when the electronic equipment is in the second state, the backup database and the main database are both in a conventional mode.

The electronic equipment has two states, wherein the backup database is in a conventional mode and the main database is in a migration mode in a first state; in the second state, both the backup database and the primary database are in a regular mode.

In the first state, when the backup database is in a normal mode, providing the data in the backup database to an application, and when the main database is in a migration mode, migrating second target data to the main database by the backup database; and providing the data in the main database to the application when the main database is in the normal mode in the second state.

The switching between the two states may be based on configured migration parameters.

If the current electronic equipment is in a first state, data in a backup database is adopted to provide for an application, and accordingly, a data migration identification field in the backup database is controlled to be set to be not migrated, and the data in the backup database is characterized as reliable, first target data are obtained from the backup database; if the main database is in the migration mode, migrating the second target data in the backup database to the main database;

If the current electronic equipment is in the second state, data in the main database is adopted to provide for the application, corresponding control is carried out to set a data migration identification field in the main database to be not migrated, and the data in the main database is characterized as reliable, and then the first target data is directly obtained from the main database.

If the running state of the current electronic equipment is the first state, at the moment, the data of the backup database is reliable, the backup database is controlled to perform data migration to the main database, and the data migration identification field in the main database is controlled to be set to be migrated, so that the fact that some data in the backup database are migrated to the main database is represented.

It should be noted that, if the service request received in the subsequent step S605 is to query the first target data, the backup database that is the original storage location of the first target data may be directly accessed based on the identifier of the primary database being migrated if the running state of the current electronic device is the first state, and if the running state of the current electronic device is the second state, the data of the primary database may be accessed based on the identifier of the primary database being not migrated and the data of the primary database being trusted. And then, converting the first target data obtained by the query into data service and providing the data service for the application.

Step S605: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

step S606: migrating the first target data from the backup database to a primary database based on the service request, such that the primary database provides the first target data to the application;

step S607: inquiring second target data to be migrated in the backup database;

step S608: and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

Steps S604-608 are identical to steps S502-506 in embodiment 4, and are not described in detail in this embodiment.

In summary, the data migration method provided in this embodiment further includes: if the backup database is in the normal mode and the main database is in the migration mode, determining that the running state of the current electronic equipment is in the first state, setting a data migration identification field of the backup database to be not migrated, and setting the data migration identification field of the main database to be migrated; if the backup database and the main data database are both in the normal mode, determining that the current running state of the electronic equipment is a second state, and setting a data migration identification field of the main database to be not migrated; in the first state, when the backup database is in a normal mode, providing the data in the backup database to an application, and when the main database is in a migration mode, migrating second target data to the main database by the backup database; in the second state, when the main database is in the normal mode, the data in the main database is provided to the application. In this embodiment, based on different current operation states of the electronic device, the data migration identification fields of the database are set to be different contents, so that when target data is queried later, whether the data of the main database is available or not can be determined based on the data migration identification fields of the main database and the backup database, and the speed of providing the first target data for the service is improved.

As shown in fig. 7, a flowchart of an embodiment 6 of a data migration method is provided, and the method includes the following steps:

step S701: emptying the main database;

step S702: starting data migration from the backup database to the main database;

step S703: if the current running state of the electronic equipment is in the first state, setting the data migration identification field of the backup database as not migrated, and setting the data migration identification field of the main database as migrated;

step S704: if the current running state of the electronic equipment is the second state, setting a data migration identification field of the main database to be not migrated;

step S705: receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

step S706: migrating the first target data from the backup database to a primary database based on the service request, such that the primary database provides the first target data to the application;

step S707: inquiring second target data to be migrated in the backup database;

step S708: based on the generation time of the second target data, sequentially migrating the second target data to a main database;

Steps S701-708 are identical to steps S601-608 in embodiment 5, and are not described in detail in this embodiment.

Step S709: and the data migration identification field of the main database is migrated.

After the first target data and/or the second target data are migrated to the main database, the data migration identification field in the main database is set to be migrated.

It should be noted that, if the service request is to create data, the data may be created for the master database. Specifically, after the creation data is obtained from the service request, the data format that can be stored in the main database is converted. The method of writing the creation data into the main database, wherein the interface provided by the written module structure is an insert XX table biased to database access (the insert XX table represents the database table accessed by the target), so that the creation data is converted into a data format corresponding to the interface in the embodiment.

Setting a data migration identification field according to the current running state of the electronic equipment, and constructing the data migration identification field as not migrated in a specific and conventional mode; and constructing a data migration identification field into a migrated mode.

In summary, the data migration method provided in this embodiment further includes: the data migration identification field of the primary database is set to migrated. In the scheme, after data in the backup database is migrated to the main database, the data migration identification field in the main database is set to be migrated so as to provide basis for data in the main database and subsequent migration in subsequent use.

Although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order. In certain circumstances, multitasking and parallel processing may be advantageous.

It should be understood that the various steps recited in the method embodiments of the present disclosure may be performed in a different order and/or performed in parallel. Furthermore, method embodiments may include additional steps and/or omit performing the illustrated steps. The scope of the present disclosure is not limited in this respect.

Corresponding to the embodiment of the data migration method provided by the application, the application also provides an embodiment of a device applying the data migration method.

Fig. 8 is a schematic structural diagram of an embodiment of a data migration apparatus provided in the present application, where the apparatus includes the following structures: a starting module 801, a receiving module 802 and a first migration module 803;

The starting module 801 is configured to start data migration from the backup database to the primary database;

wherein, the receiving module 802 is configured to receive a service request, where the service request is a request for requesting first target data by a currently running application;

the first migration module 803 is configured to migrate, based on the service request, the first target data from the backup database to the primary database, so that the primary database provides the first target data to the application.

Optionally, the first migration module includes:

the analysis unit is used for analyzing the service request to obtain a data primary key, and the data primary key corresponds to the first target data;

and the migration unit is used for migrating the first target data from the backup database to the main database based on the data main key.

Optionally, the migration unit is specifically configured to:

inquiring whether first target data corresponding to the data primary key exists in a primary database;

and if the first target data does not exist in the main database, migrating the first target data from the backup database to the main database.

Fig. 9 is a schematic diagram of another embodiment of a data migration apparatus provided in the present application, where the apparatus includes the following structures: a starting module 901, a receiving module 902, a first migration module 903 and a second migration module 904;

The structure functions of the starting module 901, the receiving module 902, and the first migration module 903 are identical to those described above, and will not be described herein.

The second migration module 904 is configured to query, in the backup database, second target data to be migrated, where the second target data is different from the first target data; and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

Optionally, the method further comprises:

and the emptying module is used for emptying the main database.

Optionally, the method further comprises:

the identification module is used for setting the data migration identification field of the backup database to be not migrated and setting the data migration identification field of the main database to be migrated if the running state of the current electronic equipment is in a first state, wherein when the electronic equipment is in the first state, the backup database is in a conventional mode and the main database is in a migration mode; if the current running state of the electronic equipment is a second state, setting a data migration identification field of the main database to be not migrated, wherein when the electronic equipment is in the second state, the backup database and the main database are both in a conventional mode; in the first state, when the backup database is in a normal mode, providing the data in the backup database to an application, and when the main database is in a migration mode, migrating second target data to the main database by the backup database; and providing the data in the main database to the application when the main database is in the normal mode in the second state.

Optionally, after migrating the first target data from the backup database to the primary database based on the data primary key, the identification module is further configured to:

the data migration identification field of the primary database is set to migrated.

In summary, in the data migration device provided in this embodiment, if there is an application requesting first target data in a process of migrating data from a backup database to a main database, after migrating the first target data from the backup database to the main database based on a service request, the main database provides the requested application with the first target data, and on the premise of ensuring data usage of the application, migrates the first target data from the backup database to the main database, thereby implementing data migration from the backup database to the main database without shutdown.

As shown in fig. 10, a schematic structural diagram of an electronic device applied to a data migration apparatus provided in the present application in a usage scenario, where the usage scenario is specifically an EMD (Electronic miscellaneous document, electronic bill administration system) scenario, includes: an interface module 1001, a service processing module 1002, a data migration apparatus 1003, a database access module 1004, a primary database 1005, and a backup database 1006;

The data migration device executes a data migration method provided in the application.

The interface module 1001 recognizes relevant service scenarios through different service requests, converts the relevant service scenarios into service requests recognizable by the service processing module 1002, and then gives the service requests to the service processing module for subsequent processing.

A flowchart of the interface module execution is shown in fig. 11. After receiving a service request in a service scene, the interface module checks whether the format and the field content of the request message are correct, prompts error information if the format and the field content are incorrect, ends the flow, branches to related branch service processing modules for processing if the format and the field content are correct, feeds back the result of whether the service processing modules succeed or not, returns prompt information when the service processing modules succeed in processing, ends the flow, and ends the flow if the processing does not succeed in prompting the error information.

The business processing module comprises a ticket issuing business sub-module, a ticket returning business sub-module and a service exchanging sub-module. The ticket issuing service sub-module is mainly responsible for processing the ticket issuing related service, the ticket returning service resource module is mainly responsible for processing the ticket returning related service, such as ticket returning, waste ticket, system cancellation, ticket returning cancellation and the like, and the switching-out service sub-module is mainly responsible for processing the switching-out related service.

A flow chart of the execution of the ticketing services sub-module is shown in fig. 12. After receiving the service request, checking whether passenger information, ticket information, price information and the like exist, if not, prompting error information, ending the flow, if so, requesting the database to store sales and transportation data, processing the data in the database by the data migration device, if the data migration device fails to process, prompting the error information, ending the flow, if the data migration device processes successfully ticketing, returning prompting information, and ending the flow.

The process of the data migration device for processing the data in the database is explained in the method specification.

A flow chart of the execution of the ticketing services sub-module is shown in fig. 13. After receiving the service request, if the sales record is extracted successfully, judging whether the verification of the service processing related information is successful or not, if the sales record is extracted successfully, prompting the error information, ending the process, if the verification is failed, storing the refund sales data by the data migration device (a first migration module in) based on the request, if the processing is failed, prompting the error information, ending the process, if the processing is successful, requesting the database to modify the sales transportation data, if the modification is failed, prompting the error information, ending the process, and if the modification is successful, returning the prompting information to the refund success, ending the process.

The process of processing the ticket returned sales data and the transportation data of the database modification sales is carried out by the data migration device (the first migration module in the data migration device) by referring to the explanation in the method specification.

A flowchart of the execution of the swap service submodule is shown in fig. 14. After receiving the service request, if the query of the ticket face is unsuccessful, prompting error information, and ending the flow; if the check is unsuccessful, prompting error information, ending the flow, if the check is unsuccessful, requesting the database to store sales and transportation data for exchanging new tickets, the data migration device (the first migration module in) processes the data in the database based on the request, if the process is unsuccessful, prompting the error information, ending the flow, if the process is successful, requesting to modify transportation data of old tickets in the database, the data migration device (the first migration module in) processes the data in the database based on the request, if the process is unsuccessful, prompting the error information, ending the flow, if the process is successful, exchanging successfully, returning prompting information, and ending the flow.

Correspondingly, in the present scenario, the first migration module in the data migration apparatus includes a plurality of sub-modules, for example: an active data migration sub-module, a data main database presence check sub-module, a data creation sub-module, a data query sub-module, and a data modification sub-module.

The active data migration submodule is mainly used for copying active data (first target data) from the backup database to the main database, modifying a data migration identification field of the main database to be migrated after copying, and synchronizing migration identification from the main database to the backup database through a unidirectional synchronization mechanism of the main and backup data provided by the main database to the backup database.

Specifically, the first migration module receives a request to obtain a data primary key, the active data migration submodule obtains the data primary key, obtains data corresponding to the primary key from the backup database through the data query module, creates data of the primary key backup database in the primary database through the data creation submodule, and updates the data migration identifier of the primary key primary database to migrated through the data modification module.

The data main database presence checking sub-module is used for a migration operation mode, and specifically, the data main database presence checking sub-module is mainly used for checking whether the active data exist in the main database based on an electronic parasitic bill number, and after a main key is acquired, the database access module is used for inquiring whether the data of the main database exist and whether the active data migration identifier is migrated.

The data creation sub-module is used for creating data processing of the data in the main database, and the data creation is carried out on the main database through the database access module. After the data creation module acquires creation data from the data service request, the creation data is converted into a data format which can be received by the data access module, and the migration identification is set according to the operation mode: in the normal mode, construct a migration flag as not migrated; in the migration mode, the build migration is identified as migrated.

The data query sub-module is used for carrying out data processing for querying the database. Specifically, in the migration mode, the active data in the backup database is obtained through the database access module, and in the conventional mode, the active data in the main database is obtained through the database access module. Specifically, after the data query sub-module obtains the query condition from the data service request, the database access module is called, the database access module is connected with the backup database under the condition that the operation mode is the migration operation mode, the database access module is connected with the main database under the condition that the operation mode is the normal operation mode, and the data query sub-module converts the active data replied by the database access module into data service reply.

The data modification sub-module is used for carrying out data modification data processing on the main database. Specifically, after the data modification sub-module obtains modification data from the data service request, in a migration mode, checking whether the active data exists in the main database or not through the active data main database existence checking sub-module based on the electronic parasitic bill number, and migrating the active data from the backup database to the main database through the active data migration sub-module under the condition that the main database does not have corresponding data; in the normal mode, no master database presence check and active data migration are required. The data modification sub-module modifies the data in the main database through the database access module.

The processing procedure of each sub-module of the data migration apparatus (the first migration module in the data migration apparatus) may also refer to the explanation in the foregoing method specification.

A flow chart of the execution of the second migration module is shown in fig. 15. Wherein, a migration identification field is added in the database tables of the main database and the backup database in advance, for example, 1 represents migrated and 0 represents non-migrated. The specific process is as follows:

step S1501: executing inactive migration, and sending a query request to the list query by taking the current date as a request date;

Step S1502: inquiring the list, namely inquiring all transaction numbers with migration identification of 0 and the date to be migrated next according to the request date;

step S1503: determining the query result in the last step, and judging whether the number of transaction numbers is 0;

if the number of transaction numbers is 0, the process goes to step S1508, and if the number of transaction numbers is not 0, step S1504 is performed.

Step S1504: judging whether the transaction number exists in the main data;

if any, the process goes to step S1507, and if not, step S1505 is executed.

Step S1505: invoking data query, and querying EMD ticket face data of a request transaction number;

the EMD face data is the inactive data herein.

Step S1506: inserting the query result into a main database, and updating the migration identifier to 1;

step S1507: judging whether the transaction number is the last transaction number;

if not, returning to repeat the step 4-6, and if so, executing the step 8;

step S1508: it is determined whether the next migration date is empty.

If the next date to be migrated is not empty, the steps S1502-S1508 are repeated with the next date to be migrated as the request date, and if the next date to be migrated is 0, the flow is ended.

Correspondingly, the database access module is respectively connected with the first migration module and the second migration module, and the main database and the backup database, and is used for transmitting information/data between the first migration module/the second migration module and the main database/the backup database.

The database access module is used for checking whether the database is connected, connecting the database, checking the operation legitimacy of the database, binding variables, executing the database operation and submitting the database operation.

Specifically, checking whether the database is connected includes: checking whether the database connection flag bit is connected; heartbeat SQL (Structured Query Language ) is executed using the database's interface to check if the database is actually connected.

Specifically, the connection database includes: creating a database connection state (an interface for performing database operations) using the interface of the database; and setting the database connection flag bit as connected.

Specifically, verifying the operation legitimacy of the database includes: checking whether SQL is legal or not by using a database interface; checking whether the naming of the binding variable is legal or not, and the naming of the binding variable is consistent with the database field.

Specifically, binding variables is performed, including: and carrying out variable binding according to the binding variable name, wherein the binding variable type is the field type of the same name of the database.

Specifically, performing database operations includes: and calling a database interface to execute database operation.

Specifically, submitting a database operation includes: and calling a database interface to submit database operation.

It should be noted that, the units described in the embodiments of the present disclosure may be implemented by software, or may be implemented by hardware. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

Corresponding to the embodiment of the data migration method provided by the application, the application also provides an embodiment of a computer readable storage medium applying the data migration method.

The computer readable storage medium has stored therein instructions which, when executed by a computer, are adapted to carry out the method according to any of the above-described method embodiments.

In the context of this disclosure, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are example forms of implementing the claims.

While several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of the disclosure. Certain features that are described in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable subcombination.

The foregoing description is only of the preferred embodiments of the present disclosure and description of the principles of the technology being employed. It will be appreciated by persons skilled in the art that the scope of the disclosure referred to in this disclosure is not limited to the specific combinations of features described above, but also covers other embodiments which may be formed by any combination of features described above or equivalents thereof without departing from the spirit of the disclosure. Such as those described above, are mutually substituted with the technical features having similar functions disclosed in the present disclosure (but not limited thereto).

Claims (10)

1. A data migration method, applied to an electronic device, the method comprising:

starting data migration from the backup database to the main database;

receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

and migrating the first target data from the backup database to the main database based on the service request, so that the main database provides the first target data to the application.

2. The method of claim 1, wherein after the migration of the first target data from the backup database to the primary database based on the service request, further comprising:

inquiring second target data to be migrated in a backup database, wherein the second target data is different from the first target data;

and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

3. The method of claim 1, wherein migrating the first target data from the backup database to the primary database based on the service request comprises:

analyzing the service request to obtain a data primary key, wherein the data primary key corresponds to the first target data;

And migrating the first target data from the backup database to the main database based on the data main key.

4. The method of claim 3, wherein migrating the first target data from a backup database to a primary database based on the data primary key comprises:

inquiring whether first target data corresponding to the data primary key exists in a primary database;

and if the first target data does not exist in the main database, migrating the first target data from the backup database to the main database.

5. The method of claim 1, wherein prior to initiating data migration of the backup database to the primary database, further comprising:

and emptying the main database.

6. The method of claim 5, further comprising, after the master database is emptied:

if the running state of the current electronic equipment is in a first state, setting a data migration identification field of a backup database to be not migrated, and setting a data migration identification field of a main database to be migrated, wherein when the electronic equipment is in the first state, the backup database is in a conventional mode and the main database is in a migration mode;

If the current running state of the electronic equipment is a second state, setting a data migration identification field of the main database to be not migrated, wherein when the electronic equipment is in the second state, the backup database and the main database are both in a conventional mode;

when the backup database is in a conventional mode, data in the backup database is provided for an application, and when the main database is in a migration mode, the backup database migrates second target data to the main database; and when the main database is in the normal mode, providing the data in the main database to the application.

7. The method of claim 6, wherein after migrating the first target data from the backup database to the primary database based on the data primary key, further comprising:

the data migration identification field of the primary database is set to migrated.

8. A data migration apparatus, for use in an electronic device, comprising:

the starting module is used for starting the data migration from the backup database to the main database;

the receiving module is used for receiving a service request, wherein the service request is a request of a currently running application for requesting first target data;

And the first migration module is used for migrating the first target data from the backup database to the main database based on the service request so that the main database provides the first target data for the application.

9. The apparatus of claim 8, further comprising

The second migration module is used for inquiring second target data to be migrated in the backup database, wherein the second target data is different from the first target data; and based on the generation time of the second target data, sequentially migrating the second target data to a main database.

10. A computer readable storage medium storing instructions which, when executed by a computer, are adapted to carry out the method of any one of claims 1 to 8.

Images