Restoring Kafka Metadata

Scenarios

Kafka metadata restoration is required in the following scenarios: when data is unexpectedly modified or deleted and requires retrieval; when major ZooKeeper operations (such as upgrades or significant adjustments) cause exceptions in system data or fail to achieve the expected result; when all modules fail and become unavailable; and when data is migrated to a new cluster.

Kafka metadata restoration tasks can be created on FusionInsight Manager. The system supports manual data restoration only.

MRS clusters support multiple data path types for restoring Kafka metadata.

• LocalDir: indicates that data is restored from the local disk of the active management node.
• LocalHDFS: indicates that data is restored from the HDFS directory of the current cluster.
• RemoteHDFS: indicates that data is restored from the HDFS directory of the standby cluster.
• NFS: indicates that data is restored from the NAS using the NFS protocol.
• CIFS: indicates that data is restored from the NAS using the CIFS protocol.
• OBS: indicates that data is restored from OBS.

Notes and Constraints

• Data restoration can be performed only when the system version is consistent with the version used during data backup.

• MRS 3.1.0 and later support data restoration from OBS.

Impact on the System

• After the metadata is restored, the data generated after the data backup and before the data restoration is lost.
• After the metadata is restored, the offset information stored on ZooKeeper by Kafka consumers is rolled back, resulting in repeated consumption.

Prerequisites

• If you need to restore data from a remote HDFS, a standby cluster has been created and the data has been backed up. For details, see Backing Up Kafka Metadata. 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 has been configured. For details, see Configuring Mutual Trust Between MRS Clusters. If the active cluster is deployed in normal mode, mutual trust is not required.

• Cross-cluster replication has been configured for the active and standby clusters. For details, see Enabling MRS Inter-Cluster Replication.
• Time is consistent between the active and standby clusters, with the NTP services on both clusters configured to use the same time source.
• The Kafka service is disabled first, and then enabled upon data restoration.

Restoring Kafka Metadata

1. Log in to MRS Manager.

   For details about how to log in to MRS Manager, see Accessing MRS Manager.

2. Choose O&M > Backup and Restoration > Backup Management.
3. In the row containing the specified backup task, choose More > View History in the Operation column to display the task's historical execution records.

   In the displayed window, locate the desired success record and click View in the Backup Path column to display the task's backup path information and obtain the following details:

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

     Locate the correct path, and manually copy the full path of the backup files from the Backup Path column.

4. On MRS Manager, choose O&M > Backup and Restoration > Restoration Management.
5. Click Create.
6. Set Task Name to the name of the restoration task.
7. Select the cluster to be operated from Recovery Object.
8. In the Restoration Configuration area, select Kafka.
9. Select a backup directory type for Path Type of Kafka.

   Table 1 Path for data restoration

   Type	Parameter	Description
   LocalDir	Source Path	Backup file to be restored. File name format: Version_Data source_Task execution time.tar.gz
   LocalHDFS	Source Path	Full path of the HDFS directory storing backup files. Path format: Backup path/Backup task name_Task creation time/Version_Data source_Task execution time.tar.gz
   	Source NameService Name	NameService name of the backup directory during restoration task execution. The default value is hacluster.
   RemoteHDFS	Source NameService Name	NameService name of the backup data cluster. You can set it to the NameService name (haclusterX, haclusterX1, haclusterX2, haclusterX3, or haclusterX4) of the built-in remote cluster. You can also set it to the NameService name of a configured remote cluster.
   	IP Mode	IP version of the target IP address. The system automatically determines the IP version, such as IPv4 or IPv6, based on the cluster network type.
   	Source NameNode IP Address	Service plane IP address of the active or standby NameNode in the standby cluster.
   	Source Path	Full path of the HDFS directory storing backup data in the standby cluster. Path format: Backup path/Backup task name_Data source_Task creation time/Version_Data source_Task execution time.tar.gz
   	Queue Name	Name of the YARN queue used for backup task execution. The name must be identical to that of a queue currently running properly in the cluster.
   NFS	IP Mode	IP version of the target IP address. The system automatically determines the IP version, such as IPv4 or IPv6, based on the cluster network type.
   	Server IP Address	IP address of the NAS server.
   	Source Path	Full path of the NAS server directory storing backup files. Path format: Backup path/Backup task name_Data source_Task creation time/Version_Data source_Task execution time.tar.gz
   CIFS	IP Mode	IP version of the target IP address. The system automatically determines the IP version, such as IPv4 or IPv6, based on the cluster network type.
   	Server IP Address	IP address of the NAS server.
   	Port	Port number used by the CIFS protocol to connect to the NAS server. The default value is 445.
   	Username	Username configured during CIFS protocol setup.
   	Password	Password configured during CIFS protocol setup.
   	Source Path	Full path of the NAS server directory storing backup files. Path format: Backup path/Backup task name_Data source_Task creation time/Version_Data source_Task execution time.tar.gz
   OBS (available in MRS 3.1.0 and later)	Source Path	Full path of the OBS directory storing backup files. Path format: Backup path/Backup task name_Data source_Task creation time/Version_Data source_Task execution time.tar.gz

10. Click OK.
11. In the restoration task list, locate the row containing the created task, and click Start in the Operation column to execute the restoration task.
    • 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.
      If the Kafka service is reinstalled and metadata is restored after data backup, or metadata is migrated to a new cluster, the Kafka Broker cannot be restarted. You can check the error details in the /var/log/Bigdata/kafka/broker/server.log file. An example error message is as follows:

      ERROR Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)kafka.common.InconsistentClusterIdException: The Cluster ID kVSgfurUQFGGpHMTBqBPiw doesn't match stored clusterId Some(0Qftv9yBTAmf2iDPSlIk7g) in meta.properties. The broker is trying to join the wrong cluster. Configured zookeeper.connect may be wrong. at kafka.server.KafkaServer.startup(KafkaServer.scala:220) at kafka.server.KafkaServerStartable.startup(KafkaServerStartable.scala:44) at kafka.Kafka$.main(Kafka.scala:84) at kafka.Kafka.main(Kafka.scala)

      Check the value of log.dirs in the Kafka Broker configuration file ${BIGDATA_HOME}/FusionInsight_Current/*Broker/etc/server.properties. The value is the Kafka data directory. Navigate to the Kafka data directory and change the value 0Qftv9yBTAmf2iDPSlIk7g of cluster.id in meta.properties to kVSgfurUQFGGpHMTBqBPiw (the latest value in the error log).

      Perform the preceding modification on every node where a Kafka Broker is located. After completing the modification, restart the Kafka service.