29.3. 从持久性卷中恢复集群

如果 Kafka 集群仍然存在，您可以从持久性卷(PV)中恢复 Kafka 集群。

例如，您可能想要进行此操作，例如：

命名空间被意外删除
整个 OpenShift 集群都会丢失，但 PV 保留在基础架构中

29.3.1. 从命名空间删除中恢复

由于持久性卷和命名空间之间的关系，可以从命名空间删除中恢复。PersistentVolume (PV) 是位于命名空间外的存储资源。PV 使用一个 PersistentVolumeClaim (PVC)挂载到 Kafka pod 中，该 PVC 在命名空间中存在。

PV 的重新声明策略会告知集群在删除命名空间时如何操作。如果重新声明策略被设置为：

删除（默认），当 PVC 在命名空间中删除时会删除 PV
Retain，当删除命名空间时 PV 不会删除。

如果确保在命名空间被意外删除时可以从 PV 中进行恢复，需要使用 persistentVolumeReclaimPolicy 属性在 PV 规格中将策略从 Delete 重置为 Retain：

apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  persistentVolumeReclaimPolicy: Retain

另外，PV 可以继承关联的存储类的重新声明策略。存储类用于动态卷分配。

通过为存储类配置 reclaimPolicy 属性，使用存储类的 PV 会使用适当的重新声明策略创建。使用 storageClassName 属性为 PV 配置存储类。

apiVersion: v1
kind: StorageClass
metadata:
  name: gp2-retain
parameters:
  # ...
# ...
reclaimPolicy: Retain

apiVersion: v1
kind: PersistentVolume
# ...
spec:
  # ...
  storageClassName: gp2-retain

注意

如果您使用 Retain 作为重新声明策略，但您想要删除整个集群，则需要手动删除 PV。否则，它们不会被删除，并可能会对资源造成不必要的成本。

29.3.2. 恢复丢失 OpenShift 集群

当集群丢失时，您可以使用 disk/volumes 中的数据在基础架构中保留时恢复集群。恢复过程与删除命名空间时相同，假设可以恢复 PV，并手动创建它们。

29.3.3. 从持久性卷中恢复已删除的集群

此流程描述了如何从持久性卷(PV)中恢复已删除的集群。

在这种情况下，主题 Operator 会标识 Kafka 中存在主题，但 KafkaTopic 资源不存在。

当进入重新创建集群时，有两个选项：

当您可以恢复所有 KafkaTopic 资源时，请使用 选项 1。
因此，在启动集群前必须恢复 KafkaTopic 资源，以便主题 Operator 不会删除对应的主题。
当您无法恢复所有 KafkaTopic 资源时，请使用选项 2。
在这种情况下，您可以在没有 Topic Operator 的情况下部署集群，删除 Topic Operator 主题存储元数据，然后使用 Topic Operator 重新部署 Kafka 集群，以便它可以从对应的主题重新创建 KafkaTopic 资源。

注意

如果没有部署 Topic Operator，您只需要恢复 PersistentVolumeClaim (PVC)资源。

开始前

在此过程中，PV 被挂载到正确的 PVC 中非常重要，以避免数据崩溃。为 PVC 指定 volumeName，它必须与 PV 的名称匹配。

如需更多信息，请参阅持久性存储。

注意

该流程不包括对 KafkaUser 资源的恢复，这些资源必须手动重新创建。如果需要保留密码和证书，必须在创建 KafkaUser 资源前重新创建 secret。

流程

检查集群中 PV 的信息：

oc get pv

会显示与数据相关的 PV 的信息。

显示此过程很重要的列的输出示例：

NAME                                         RECLAIMPOLICY CLAIM
pvc-5e9c5c7f-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-my-cluster-zookeeper-1
pvc-5e9cc72d-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-0
pvc-5ead43d1-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-my-cluster-zookeeper-2
pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c ... Retain ...    myproject/data-0-my-cluster-kafka-0
pvc-7e21042e-3317-11ea-9786-02deaf9aa87e ... Retain ...    myproject/data-0-my-cluster-kafka-1
pvc-7e226978-3317-11ea-97b0-0aef8816c7ea ... Retain ...    myproject/data-0-my-cluster-kafka-2

NAME 显示每个 PV 的名称。
RECLAIM POLICY 显示 PV 被保留。
CLAIM 显示到原始 PVC 的链接。

重新创建原始命名空间：
```
oc create namespace myproject
```

重新创建原始 PVC 资源规格，将 PVC 链接到适当的 PV：

例如：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-0-my-cluster-kafka-0
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gp2-retain
  volumeMode: Filesystem
  volumeName: pvc-7e1f67f9-3317-11ea-a650-06e1eadd9a4c

编辑 PV 规格，以删除绑定原始 PVC 的 claimRef 属性。

例如：

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    kubernetes.io/createdby: aws-ebs-dynamic-provisioner
    pv.kubernetes.io/bound-by-controller: "yes"
    pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
  creationTimestamp: "<date>"
  finalizers:
  - kubernetes.io/pv-protection
  labels:
    failure-domain.beta.kubernetes.io/region: eu-west-1
    failure-domain.beta.kubernetes.io/zone: eu-west-1c
  name: pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
  resourceVersion: "39431"
  selfLink: /api/v1/persistentvolumes/pvc-7e226978-3317-11ea-97b0-0aef8816c7ea
  uid: 7efe6b0d-3317-11ea-a650-06e1eadd9a4c
spec:
  accessModes:
  - ReadWriteOnce
  awsElasticBlockStore:
    fsType: xfs
    volumeID: aws://eu-west-1c/vol-09db3141656d1c258
  capacity:
    storage: 100Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: data-0-my-cluster-kafka-2
    namespace: myproject
    resourceVersion: "39113"
    uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: failure-domain.beta.kubernetes.io/zone
          operator: In
          values:
          - eu-west-1c
        - key: failure-domain.beta.kubernetes.io/region
          operator: In
          values:
          - eu-west-1
  persistentVolumeReclaimPolicy: Retain
  storageClassName: gp2-retain
  volumeMode: Filesystem

在示例中，删除了以下属性：

claimRef:
  apiVersion: v1
  kind: PersistentVolumeClaim
  name: data-0-my-cluster-kafka-2
  namespace: myproject
  resourceVersion: "39113"
  uid: 54be1c60-3319-11ea-97b0-0aef8816c7ea

部署 Cluster Operator。

oc create -f install/cluster-operator -n my-project

重新创建集群。
根据您是否有重新创建集群所需的所有 KafkaTopic 资源，请按照以下步骤操作。
选项 1： 如果您在丢失 集群前存在所有 KafkaTopic 资源，包括内部主题，如来自 __consumer_offsets 的提交偏移：
1. 重新创建所有 KafkaTopic 资源。
  在部署集群前重新创建资源非常重要，否则主题 Operator 将删除主题。
2. 部署 Kafka 集群。
  例如：
```
oc apply -f kafka.yaml
```
选项 2：如果您在丢失集群前没有所有 KafkaTopic 资源：
1. 在部署前，部署 Kafka 集群，如第一个选项一样，但没有 Topic Operator，方法是从 Kafka 资源中删除 topicOperator 属性。
  如果您在部署中包含主题 Operator，则主题 Operator 将删除所有主题。
2. 从 Kafka 集群中删除内部主题存储主题：
```
oc run kafka-admin -ti --image=registry.redhat.io/amq-streams/kafka-37-rhel9:2.7.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete
```
  该命令必须与监听程序的类型以及用于访问 Kafka 集群的身份验证对应。
3. 通过使用 topicOperator 属性重新部署 Kafka 集群来启用 Topic Operator，以重新创建 KafkaTopic 资源。
  例如：
```
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  #...
  entityOperator:
    topicOperator: {} 1
    #...
```
1
在这里，我们显示没有附加属性的默认配置。您可以使用 EntityTopicOperatorSpec schema reference 中所述的属性指定所需的配置。
通过列出 KafkaTopic 资源来验证恢复：
```
oc get KafkaTopic
```

29.3. 从持久性卷中恢复集群

29.3.1. 从命名空间删除中恢复

29.3.2. 恢复丢失 OpenShift 集群

29.3.3. 从持久性卷中恢复已删除的集群

学习

尝试、购买和销售

社区

关于红帽文档

让开源更具包容性

關於紅帽

Red Hat legal and privacy links

Red Hat legal and privacy links