Restoring Solr Service Data

Scenario

Solr service data needs to be restored in the following scenarios: Data is modified or deleted unexpectedly and needs to be restored. After an administrator performs major operations (such as upgrade and data adjustment) on Solr, an exception occurs or the expected result is not achieved. All modules are faulty and become unavailable. Data is migrated to a new cluster.

System administrators can create a Solr service data restoration task on FusionInsight Manager. After the task is successfully executed, the service data is restored. Only manual restoration tasks are supported.

• Data restoration can be performed only when the system version is consistent with that during data backup.
• To restore Solr service data when services are normal, manually back up the latest service data first and then restore the data. Otherwise, the Solr service data that is generated after the data backup and before the data restoration will be lost.
• During the execution of a restoration task, if the index to be restored already exists, the index will be deleted and then automatically created. Therefore, index-related service operations may be affected during the restoration task execution.
• Ensure that the running status of all instances in the cluster is normal and can receive requests properly. To ensure successful restoration, do not perform operations such as adding, deleting, stopping, or restarting Solr instances, stopping or restarting the Solr service, or stopping or restarting the cluster.
• Solr metadata and service data cannot be restored at the same time. Otherwise, service data restoration fails.

Impact on the System

• After the data is restored, the data generated after the data backup and before the data restoration is lost.
• After the data is restored, the Solr upper-layer applications need to be started.

Prerequisites

• The Solr backup file save path is correct.
• The Solr upper-layer applications are stopped.
• If you need to restore data from a remote HDFS, prepare a standby cluster. If the active cluster is deployed in security mode and the active and standby clusters are not managed by the same FusionInsight Manager, mutual trust must be configured. For details, see Configuring Cross-Manager Mutual Trust Between Clusters. If the active cluster is deployed in normal mode, no mutual trust is required.
• Time is consistent between the active and standby clusters and the NTP services on the active and standby clusters use the same time source.

Procedure

1. On FusionInsight Manager, choose O&M > Backup and Restoration > Backup Management.
2. In the Operation column of the specified task in the task list, choose More > View History.

   In the window that is displayed, select a success record and click View in the Backup Path column to view its backup path information and find the following information:

   • Backup Object: indicates the backup data source.
   • Backup Path: indicates the full path where backup files are stored.

     Select the correct path, and manually copy the full path of backup files in Backup Path.

3. On FusionInsight Manager, choose O&M > Backup and Restoration > Restoration Management.
4. Click Create.
5. Set Task Name to the name of the restoration task.
6. Select the desired cluster from Recovery Object.
7. In Restoration Configuration, choose Solr > Solr under Service Data.
8. Set Path Type of Solr to a restoration directory type.

   The following types of directories can be restored:

   RemoteHDFS: indicates that the backup files are stored in the HDFS directory of the standby cluster.

   If you select this option, configure the following parameters:

   • Source NameService Name: indicates the NameService name of the backup data cluster, for example, hacluster. You can obtain it from the NameService Management page of HDFS of the standby cluster.
   • IP Mode: indicates the mode of the target IP address. The system automatically selects the IP address mode based on the cluster network type, for example, IPv4 or IPv6.
   • Source Active NameNode IP Address: indicates the service plane IP address of the active NameNode in the standby cluster.
   • Source Standby NameNode IP Address: indicates the service plane IP address of the standby NameNode in the standby cluster.
   • Source NameNode RPC Port: indicates the value of dfs.namenode.rpc.port in the HDFS basic configuration of the standby cluster.
   • Source Path: indicates the full path of HDFS directory for storing backup data of the standby cluster, for example, Backup path/Backup task name_Data source_Task creation time.
   • Recovery Point List: Click Refresh and select a Solr snapshot directory that has been backed up in the standby cluster.

9. In the Data Configuration area, select one or more indexes for Backup Object based on service requirements.
10. Specify Force recovery. The value false does not take effect. All backup data is forcibly restored when there are indexes with the same name. If the index contains data added after backup, the added data will be lost after the data restoration.
11. Click Verify to check whether the restoration task is configured correctly.
    • If the specified directory to be restored does not exist, the verification fails.
    • If the forcible restoration conditions are not met, the verification fails.

12. Click OK.
13. In the restoration task list, locate the row where the created task is located, and click Start in the Operation column.
    • After the restoration is successful, the progress bar is in green.
    • After the restoration is successful, the restoration task cannot be executed again.
    • If the restoration task fails during the first execution, rectify the fault and click Retry to execute the task again.