WO2014180207A1

WO2014180207A1 - Metadata server migration processing method and device

Info

Publication number: WO2014180207A1
Application number: PCT/CN2014/074849
Authority: WO
Inventors: 董晓国; 刘洋; 蔡浩; 陈辉; 刘彦秋
Original assignee: 中兴通讯股份有限公司
Priority date: 2013-11-04
Filing date: 2014-04-04
Publication date: 2014-11-13
Also published as: CN104615598B; CN104615598A

Abstract

Provided are a metadata server migration processing method and device, the method comprising: obtaining the configuration information of a target server that an original server is to be migrated to; writing the configuration information into an in-memory database of the target server, and generating a configuration file of the target server according to the configuration information; uploading the in-memory database and the configuration file to the target server for distributed deployment. The technical solution of the present invention prevents abnormal service operation caused by the damage to or the location change of the metadata server, significantly reduces manual operation errors and decreases the time for migration, thus improving migration efficiency.

Description

The present invention relates to the field of data storage, and more particularly to a migration processing method and apparatus for a metadata server. BACKGROUND OF THE INVENTION With the explosion of unstructured data, distributed file systems have entered a golden age of development. From high-performance computers to data centers, from data sharing to Internet applications, distributed file systems have penetrated into every aspect of data applications. For most distributed file systems, however, metadata and data are usually separated, that is, control flow and data flow are separated, resulting in higher system scalability. Therefore, metadata management is crucial. The distributed file system includes the following types of servers: Directory Tree Server (DTS), File Locate Register (FLR), File Access Client (FAC), and File Access Server (referred to as FAS;). DTS is primarily responsible for data configuration and management and managing file namespaces. FLR is primarily responsible for the data block distribution and management of files. The FAC is the agent that the application accesses the file system and is primarily responsible for providing a common file manipulation interface to the application. FAS is where the user data is actually stored in the file system. The system architecture of the distributed file system includes two cases (1) as shown in Figure 1, DTS and FLR are combined on one server; (2) As shown in Figure 2, DTS and FLR are located on different servers. In actual applications, the above-mentioned metadata server generates faults or changes in the equipment room for various reasons. If the metadata cannot be efficiently migrated to other servers, the smooth operation of the service will be affected. At present, for the problem that the metadata server is damaged or the server location is changed in the related technology, the metadata cannot be efficiently migrated to other servers, and the service cannot be operated normally. Currently, an effective solution has not been proposed. SUMMARY OF THE INVENTION The embodiments of the present invention provide a migration processing method and apparatus for a metadata server, so as to at least solve the related art, after the metadata server is damaged or the server location is changed, the metadata cannot be efficiently migrated to other servers, and the service is not normal. Running problems. According to an embodiment of the present invention, a migration processing method of a metadata server is provided, including: acquiring configuration information of a target server that the original server needs to move in; writing the configuration information to an in-memory database of the target server, and Generating a configuration file of the target server according to the configuration information; uploading the memory database and the configuration file to the target server for distribution and deployment. Preferably, obtaining the configuration information of the target server that the original server needs to move in, including: obtaining, from the foregoing original server, the original system information of the distributed file system where the original server is located, and the user configuration migration information determined according to the migration scenario, where Different migration scenarios correspond to different user configuration migration information; the configuration information is determined according to the original system information and the user configuration migration information. Preferably, the foregoing migration scenario includes at least one of the following: the active and standby DTSs are all migrated, only the standby DTS is migrated, the active and standby FLRs are all migrated, and only the standby FLR is migrated. Preferably, before the foregoing in-memory database and the foregoing configuration file are uploaded to the target server for distribution and deployment, the method further includes: acquiring an operation state of the original server; and constructing a DTS version file when the running state is offline; Uploaded to the target server, where the target server performs subsequent operations by using the DTS version file. Preferably, the method further includes: when the operating state is online, if the target server IP address changes, the communication process associated with the target server is dynamically switched to the changed IP address. Preferably, after the foregoing in-memory database and the foregoing configuration file are uploaded to the target server for distribution and deployment, the method includes: when the running state is offline, first starting the primary DTS version file in the target server, and waiting for the primary DTS version file. After the startup is successful, at least one of the following version files is started: an alternate DTS version file, a primary standby FLR version file, a file access client FAC version file, and a file access server FAS version file; when the above running state is online, at the above target At least one of the following is started in the server: the above-mentioned standby DTS version file, the above-mentioned primary and backup FLR version files, and the above-mentioned standby FLR version file. Preferably, after the foregoing in-memory database and the foregoing configuration file are uploaded to the target server for distribution and deployment, the method further includes: verifying whether the migration is successful; when the migration fails, performing a rollback operation, and clearing the intermediate file of the migration process. According to another embodiment of the present invention, a migration processing apparatus for a metadata server is provided, including: an obtaining module configured to acquire configuration information of a target server that the original server needs to move in; a writing module configured to The configuration information is written into the in-memory database of the target server; the generating module is configured to generate a configuration file of the target server according to the configuration information; and the uploading module is configured to upload the in-memory database and the configuration file to the target server for distribution and deployment. Preferably, the obtaining module includes: an obtaining unit, configured to acquire, from the original server, original system information of the distributed file system where the original server is located, and user configuration migration information determined according to the migration scenario, where different migration scenarios Corresponding to different user configuration migration information; the determining unit is configured to determine the configuration information according to the original system information and the user configuration migration information. Preferably, the acquiring unit is configured to acquire the user configuration migration information when the migration scenario includes at least one of the following: the primary and backup DTSs are migrated, only the standby DTS, the primary and secondary file location registers FLR are migrated, and only the standby is migrated. FLR. According to the embodiment of the present invention, the configuration information of the target server that the original server needs to be moved is obtained; the configuration information is written into the in-memory database of the target server, and the configuration file of the target server is generated according to the configuration information. And the technical solution for uploading the in-memory database and the configuration file to the target server for distribution and deployment, and solving the problem that the metadata server is damaged or the server location is changed, causing the service to fail to operate normally, and the problem is good. Reducing human error, shortening the time required for migration and improving migration efficiency. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a system architecture diagram of a distributed file system DTS and FLR according to the related art; FIG. 2 is another system architecture diagram of a distributed file system DTS and FLR according to the related art; 3 is a flowchart of a migration processing method of a metadata server according to an embodiment of the present invention; FIG. 4 is a structural block diagram of a migration processing apparatus of a metadata server according to an embodiment of the present invention; FIG. FIG. 6 is a schematic structural diagram of a migration system of a metadata server according to a preferred embodiment of the present invention; FIG. 7 is a metadata server migration of an offline system according to a preferred embodiment of the present invention; Figure 8 is a flow diagram of an online system migration standby DTS in accordance with a preferred embodiment of the present invention; Figure 9 is a flow diagram of an online system migration primary standby FLR in accordance with a preferred embodiment of the present invention; 10 is a flow diagram of an online system migration standby FLR in accordance with a preferred embodiment of the present invention. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. FIG. 3 is a flowchart of a migration processing method of a metadata server according to an embodiment of the present invention. As shown in FIG. 3, the method includes: Step S302 to Step S306,

S302: Obtain configuration information of the target server that the original server needs to move in; in this step, the source of the configuration information includes two ways: the original system information of the distributed file system of the original server obtained from the foregoing original server; User configuration migration information determined by the migration scenario. The user selects different migration scenarios and corresponds to different user configuration migration information. After obtaining the original system information and the user configuration migration information, the client determines the configuration information that needs to be migrated to the target server according to the obtained original system information and the user configuration migration information.

S304: Write the foregoing configuration information to the in-memory database of the target server, and generate a configuration file of the target server according to the configuration information. The in-memory database may be: an in-memory database configured by the enterprise for the server, but is not limited thereto.

S306: Upload the foregoing in-memory database and the foregoing configuration file to a target server for distribution deployment. Before the step, the client also needs to obtain the running state of the original server, and according to the obtained running state, the following operations are performed: When the obtained running state is offline, the DTS version file is constructed; the DTS version file is Uploaded to the target server, where the target server performs subsequent operations by using the DTS version file. That is, when the above-mentioned operating state is offline, it is finally necessary to upload the above-mentioned in-memory database, the above-mentioned configuration file, and the above-configured DTS version file to the target server. When the obtained running state is the online state, if the target server IP address changes, the communication process associated with the target server is dynamically switched to the changed IP address. Otherwise it will affect the subsequent target server configuration process. In the above steps, the client first obtains the configuration information of the target server that needs to be moved in two ways, one of which is the distributed file system of the original server obtained from the original server. The original system information; the other is the user configuration migration information determined according to the migration scenario. After obtaining the above configuration information, the configuration information is written into the in-memory database of the target server, and then the configuration file required for the subsequent target server configuration is generated according to the written configuration information, and finally the above-mentioned in-memory database and configuration file are uploaded to In the target server (if the running status of the original server is offline, the DTS version file needs to be uploaded), and the target server distributes and distributes according to the received content, thus completing the process of migrating metadata from the original server to the target server. . With such a technical solution, the automatic migration of the DTS server or the FLR server metadata to other servers can well solve the problems of metadata server damage or server location changes, and ensure the normal operation of the service. It should be noted that before and after the migration, the DTS and the FLR can be combined on one server or on different servers. In this embodiment, the migration scenario includes: the active and standby DTSs are all migrated, only the standby DTS is migrated, the active and standby FLRs are all migrated, and only the standby FLR is migrated. The present invention further improves the foregoing technical solution, after the migration process is finished, after the foregoing in-memory database and the foregoing configuration file are uploaded to the target server for distribution and deployment, the operation state of the original server needs to be acquired, and then the following two operation processes are performed. When the running status is offline, first start the main DTS version file in the target server. After the above-mentioned main DTS version file is successfully started, start at least one of the following version files: Alternate DTS version file, main standby FLR version File, file access client FAC version file and file access server FAS version file; when the above running state is online, start at least one of the following in the target server: the above standby DTS version file, the above-mentioned primary standby FLR version file, the above standby FLR version file. A further improvement of the foregoing technical solution is that after the migration process is completed, after the foregoing in-memory database and the configuration file are uploaded to the target server for distribution and deployment, it is also required to verify whether the migration is successful, and if not, the metadata migration process is successful. In case of failure, a rollback operation is required and the intermediate files in the migration process are cleared. FIG. 4 is a structural block diagram of a migration processing apparatus of a metadata server according to an embodiment of the present invention. As shown in FIG. 4, the device includes: an obtaining module 40, configured to acquire configuration information of a target server that the original server needs to move in; In the operation performed by the module, the obtained configuration information is derived from two paths, and is implemented by two modules. As shown in FIG. 5, the obtaining module 40 includes: an obtaining unit 400, configured to acquire the original server. The original system information of the distributed file system where the original server is located, and the user configuration migration information determined according to the migration scenario, where different migration scenarios correspond to different user configuration migration information, where the user configuration information acquired by the obtaining unit 400 is The migration scenario is as follows: The migration scenario includes at least one of the following: the active and standby DTSs are migrated, only the standby DTS is migrated, the active and standby file location registers FLR are migrated, and only the standby FLR is migrated. It is configured to determine the configuration information according to the original system information and the user configuration migration information. The writing module 42 is connected to the obtaining module 40, and is configured to write the configuration information into the in-memory database of the target server; the generating module 44 is connected to the writing module 42 and configured to generate a configuration file of the target server according to the configuration information. The uploading module 46 is connected to the generating module 44, and is configured to upload the above-mentioned in-memory database and the above-mentioned configuration file to the target server for distribution and deployment. Through the functions of the above modules, the client first obtains the configuration information of the target server that needs to be moved in. After obtaining the configuration information, the configuration information is written into the in-memory database of the target server, and then according to the written configuration information. The configuration file required for the subsequent target server configuration is generated, and finally the above-mentioned in-memory database and configuration file are uploaded to the target server, and the target server is distributed and deployed according to the received content, thereby completing the migration of the metadata from the original server to the target server. the process of. With such a technical solution, the automatic migration of the DTS server or the FLR server metadata to other servers can well solve the problems of metadata server damage or server location changes, and ensure the normal operation of the service. The above various modules involved in this embodiment may be implemented by software or by corresponding hardware. For example, each of the above modules may be in the processor, or at least two of the modules may be located in the same processor, but are not limited thereto, and are determined according to actual conditions. In order to better understand the working process of the server migration in the above embodiment, the following detailed description will be given in conjunction with the preferred embodiments. It should be noted that the following preferred embodiments do not constitute a limitation of the present invention. Specifically, FIG. 6 is a schematic structural diagram of a migration system of a metadata server according to a preferred embodiment of the present invention. As shown in Figure 6, the client monitors the entire migration process in batches. The migration systems applicable to this architecture include: DTS and FLR Combined system and DTS and FLR separation system. The migration scenarios of the solution include: migration of the active and standby DTSs, migration of only the standby DTS, migration of the active and standby FLRs, and migration of only the standby FLR. After the migration, DTS and FLR can be combined on one server or on different servers. The client batch monitors and manages the entire migration process. The specific steps are as follows: 1: The client monitors and manages the batch metadata server migration process.

2: Extracting data from the migration server by dropping the metadata storage file (the file in the in-memory database) for offline analysis;

3: Connect to the migration target server, and build the socket;

4: The user selects the migrated scenario and configures the target server information at the same time; 5: Writes the target server configuration data and generates the configuration file to the metadata storage file on the client;

6: Upload the constructed DTS version, metadata file and configuration file from the client to the target server, and perform automatic distribution and deployment;

7: Automatically start the DTS version, and download the man-machine command script;

8: Upgrade the metadata storage file, convert the data in the original metadata server into the metadata in the target server; 9: Automatically set the communication between the servers to dynamically switch;

10: Automatically launch all other server versions;

11: After the migration is complete, check the rack diagram displayed by the client to see if all the servers are online. 12: Log in to port 1502 of the active DTS, check whether the data table and basic read/write functions are normal. 13: If the migration fails, proceed Roll back the operation and clear the middle file of the migration process. In the above embodiment, the migration process of the server is applicable to the offline system and the online system. The following details: For the offline system: Step A: Automatically analyze and extract the original system information from the metadata storage file; Step B: Connect the migration target server , Socket build chain; Step c: Select the migration scenario, enter the migration target server information, and automatically construct the migrated metadata storage file and configuration file. Step D: Automatically construct the DTS version file; Step E: Automatically distribute the deployed DTS version file, and construct the completed element Data save file and configuration file; Step F: Automatically stop FLR, FAC, FAS version; Step G: Automatically start the main DTS version, and start the DTS version successfully, automatically start all other server versions; Step H: Login to the main use Port 1502 of DTS, check data table, basic read and write function is normal. If it is not normal, perform a rollback operation. For the online system: Step A: Automatically analyze and extract the original system information from the metadata storage file; Step B: Connect the migration target server to perform Socket chain establishment; Step C: Select the migration scenario, enter the migration target server information, and automatically construct the configuration. File; Step D: Automatically distribute the deployment configuration file, Boot file, and file system metadata file; Step E: If the migration target server IP changes, the server-to-server communication is dynamically switched; Step F: Automatically start the server version; Step G: Log in to port 1502 of the main DTS to check whether the data table and basic read/write functions are normal. If it is not normal, perform a rollback operation. Since the types of servers migrated by the online system and the offline system are different, the execution steps are also slightly different. The following is described in detail in conjunction with the following preferred embodiments: For the offline system, the primary standby DTS is migrated. 7 is a flow diagram of a metadata server migration of an offline system in accordance with a preferred embodiment of the present invention. As shown in Figure 7, the process includes the following processing steps:

S700: extracting original system data from the main DTS data storage file: information of DTS, FLR, FAC, FAS; S702: Write configuration information of the migration target server, including module IP information, version table information, and the like, to the metadata storage file on the client offline;

S704: automatically constructing a version file and a configuration file of the DTS;

S706: Using a script to implement a Secure Shell (SSH) protocol, automatically log in to the original FLR, FAC, FAS server, and modify the configuration file;

S708: Upload the constructed DTS version and configuration file from the client to the migration target active and standby DTS servers respectively.

S710: uploading the modified metadata storage file from the client to the migration target DTS, and synchronizing to the standby DTS by using the data synchronization; S712: automatically uploading and uploading the uploaded file on the migration target primary standby DTS server by using a script;

S714: automatically stop all versions of FLR, FAC, and FAS by using a script; S716: automatically enable the active DTS version by using a script;

S718: Whether the primary DTS version is successfully started, if yes, go to step S720, otherwise go to step S714; S720: After the primary DTS version is successfully started, the standby DTS and the FLR, FAC, and FAS versions are automatically started.

S722: After all the versions are successfully started, log in to the port 1502 of the active DTS; S724: check whether the data table is normal, if yes, go to step S726, otherwise go to step S730; S726: check whether the basic read/write function is normal. If not, go to step S730, if it is normal, go to step S728; S728: the migration is successful;

S730: The migration fails, the rollback operation is performed, and the intermediate file is cleared. For an online system, only the alternate DTS is migrated: Figure 8 is a flow diagram of an online system migration standby DTS in accordance with a preferred embodiment of the present invention. As shown in Figure 8: S800: offline extraction of DTS, FLR, FAC, FAS information from the main DTS data file; S802: using the man-machine command to write configuration information of the migration target server, such as IP configuration, to the metadata storage file online;

S804: automatically construct a configuration file of the DTS standby machine;

S806: uploading the DTS standby configuration file and the BOOT version startup file to the migration target server; S808: using a script to implement SSH automatic login target migration system, modifying the configuration files of the main DTS, FLR, FAC, and FAS;

S810: determining whether the original standby DTS is online, if yes, proceeding to step S812, otherwise proceeding to step S814; S812: automatically stopping the original standby DTS version;

S814: determining whether the IP address of the migration target standby DTS is changed, if yes, proceeding to step S816, otherwise proceeding to step S818;

S816: Notifying the main DTS, using the man-machine command to realize dynamic communication with the main DTS, FLR, FAC, FAS, and switching to a new IP;

S818: Enable the BOOT file of the migration target standby DTS, and wait for the startup standby DTS version to be successfully started;

S820: After all the versions are successfully started, log in to the port 1502 of the active DTS; S822: Check whether the data table is normal. If it is normal, proceed to step S824, otherwise proceed to step S828;

S824: Verify that the basic read/write function is normal, if it is normal, proceed to step S826, otherwise, go to step S828;

S826: The migration is successful;

S828: The migration fails, the rollback operation is performed, and the intermediate file is cleared. For an online system, migrating the active and standby FLRs: Figure 9 is a flow diagram of an online system migration primary standby FLR in accordance with a preferred embodiment of the present invention. As shown in Figure 9:

S900: offlinely export DTS, FLR, FAC, and FAS related information from the metadata storage file;

S902: Modify the FLR module information to the metadata storage file of the primary DTS by using the man-machine command, and synchronize the data to the metadata storage file of the standby DTS; S904: automatically construct an FLR configuration file according to the target migration system information;

S906: Using a script to implement SSH to automatically log in to the migration target system, and automatically modify the DTS, FAC, and FAS configuration files;

S908: upload the file system metadata file to the FLR host, upload the BOOT version startup file and configuration file to the active and standby FLR, and perform automatic distribution and deployment;

S910: Determine whether the IP of the active or standby FLR changes. If yes, go to step S912; otherwise, go to step S914.

S912: Notifying the main DTS, using the man-machine command to realize dynamic communication with the DTS, the FAC, and the FAS, and switching to the new IP address; S914: The script automatically starts the BOOT file of the main FLR, after the main FLR is successfully started. , then automatically start the standby FLR BOOT file;

S916: After all versions are successfully started, log in to port 1502 of the active DTS;

S918: Check if the data table is normal. If yes, go to step S920, otherwise go to step S924;

S920: Verify that the basic read/write function is normal, if yes, proceed to step S922, otherwise proceed to step S924;

S922: The migration is successful;

S924: The migration fails, the rollback operation is performed, and the intermediate file is cleared. For an online system, migration standby FLR: Figure 10 is a flow diagram of an online system migration standby FLR in accordance with a preferred embodiment of the present invention. As shown in Figure 10: S1002: Offline DTS, FLR, FAC, FAS related information is exported from the metadata storage file;

S1004: Using the man-machine command to modify the FLR module information online to the metadata storage file of the main DTS, and the data is synchronized to the metadata storage file of the standby DTS;

S1006: automatically construct an alternate FLR configuration file according to the target migration system information;

S1008: Using the script to implement SSH automatic login to the migration target system, automatically modifying the DTS, the main FLR, FAC, and FAS configuration files; S1010: Upload the BOOT startup file and configuration file to the FLR standby machine, and perform automatic deployment;

S1010: determining whether the IP of the standby FLR changes, if yes, proceeding to step S1014, if no, proceed to step S1016;

S1014: Notifying the main DTS, using the man-machine command to dynamically communicate with the DTS, the primary FLR, the FAC, and the FAS, and switching to the new IP address;

S1016: Use a script to automatically start the BOOT file of the standby FLR;

S1018: After all the versions are successfully started, log in to port 1502 of the active DTS.

S1020: Check if the data table is normal. If yes, go to step S1022, otherwise go to step S1026;

S1022: Verify that the basic read/write function is normal, if yes, proceed to step S1024, otherwise proceed to step S1026;

S1024: The migration is successful;

S1026: The migration failed, the rollback operation was performed, and the intermediate file was cleared. It will be apparent to those skilled in the art that the various devices or steps of the present invention described above can be implemented with a general purpose computing device. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented in program code executable by a computing device such that they may be stored in a storage device for execution by the computing device. In some cases, the steps shown or described may be performed in an order different than that described herein. They can also be fabricated separately into individual integrated circuit modules, or a plurality of modules or steps thereof can be implemented as a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software. The above are only the preferred embodiments of the present invention, and are not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention. INDUSTRIAL APPLICABILITY The above technical solution provided by the present invention can be applied to a migration process of a metadata server, and adopts configuration information of acquiring a target server that the original server needs to move in; and writing the configuration information to an in-memory database of the target server. And generating a configuration file of the target server according to the configuration information; uploading the in-memory database and the configuration file to the target server for distribution and deployment, and solving related In the technology, the problem that the metadata server is damaged or the server location changes cause the service to fail to operate normally, the error of the human operation can be reduced, the time required for the migration is shortened, and the migration efficiency is improved.

Claims

Claim

A migration processing method for a metadata server, comprising:

Obtain configuration information of the target server that the original server needs to move in;

Writing the configuration information into an in-memory database of the target server, and generating a configuration file of the target server according to the configuration information;

The in-memory database and the configuration file are uploaded to the target server for distribution.

2. The method according to claim 1, wherein the obtaining configuration information of the target server that the original server needs to move in comprises:

Obtaining, from the original server, the original system information of the distributed file system where the original server is located, and the user configuration migration information determined according to the migration scenario, where different migration scenarios correspond to different user configuration migration information;

The configuration information is determined according to the original system information and the user configuration migration information.

3. The method according to claim 2, wherein the migration scenario comprises at least one of the following:

The active and standby directory server DTSs are migrated, only the standby DTS is migrated, and the active and standby file location registers FLR are migrated and only the standby FLR is migrated.

The method according to claim 1, wherein before the uploading the in-memory database and the configuration file to the target server for distribution and deployment, the method further includes:

Obtaining an operating status of the original server;

Constructing a DTS version file when the running state is offline;

Uploading the DTS version file to the target server, wherein the target server performs subsequent operations by using the DTS version file.

5. The method according to claim 4, further comprising: when the operating state is online, dynamically changing a communication process associated with the target server to a change if the target server IP address changes After the IP address. The method according to claim 4, wherein after uploading the in-memory database and the configuration file to the target server for distribution deployment, the method comprises:

When the running state is offline, firstly, the main DTS version file is started in the target server, and after the main DTS version file is successfully started, at least one of the following version files is started: the standby DTS version file, the main Alternate FLR version file, file access client FAC version file and file access server FAS version file;

When the running state is online, at least one of the following is started in the target server: the standby DTS version file, the primary standby FLR version file, and the standby FLR version file. The method according to any one of claims 1 to 6, wherein after the in-memory database and the configuration file are uploaded to a target server for distribution and deployment, the method further includes:

Verify that the migration was successful;

When the migration fails, a rollback operation is performed and the intermediate files of the migration process are cleared. A migration processing device for a metadata server includes:

An obtaining module, configured to acquire configuration information of a target server that the original server needs to move in; a writing module, configured to write the configuration information into an in-memory database of the target server; and a generating module, configured to use, according to the configuration information, Generating a configuration file of the target server; uploading a module, configured to upload the in-memory database and the configuration file to a target server for distribution deployment. The device according to claim 8, wherein the obtaining module comprises: an obtaining unit, configured to acquire, from the original server, original system information of a distributed file system where the original server is located, and a user determined according to the migration scenario Configure the migration information, where different migration scenarios correspond to different user configuration migration information.

And a determining unit, configured to determine the configuration information according to the original system information and the user configuration migration information. The device according to claim 9, wherein the acquiring unit is configured to acquire the user configuration migration information when the migration scenario includes at least one of the following: