恢复 Neo4j 容器

此方法假设您拥有凭据，并希望将备份存储在 Google Cloud Storage、AWS S3 或 Azure Blob Storage 上。如果不是这种情况，您需要根据您期望的云存储方法调整恢复脚本，但此方法适用于任何备份位置。
此方法仅适用于 Neo4j 4.0+。3.5 和 4.0 之间的工具和 DBMS 本身发生了很大变化，此处的方法可能不适用于旧版本数据库，除非进行大量修改。

方法

恢复容器在主集群中用作 initContainer。在 Neo4j 集群中的节点启动之前，恢复容器会下载备份集并将其恢复到位。当 initContainer 终止时，常规的 Neo4j Docker 实例会启动，并从备份中断的地方继续。

此容器主要针对本代码仓库中 backup 容器生成的备份 .tar.gz 归档进行测试。我们建议您使用该方法。如果您使用不同方法 tar/gz 自己的备份，请仔细检查 restore.sh 脚本，因为它需要对归档备份的目录结构做出某些假设才能正确恢复。

为了从云存储中读取备份文件，容器需要提供一些凭据或身份验证。可用的机制取决于云服务提供商。

使用服务账号访问云存储（仅限 Google Cloud）

GCP

由于其改进的安全属性和可管理性，Workload Identity 是从 GKE 中运行的应用程序访问 Google Cloud 服务的推荐方式。

遵循 GCP 说明 以

  • 在 GKE 集群上启用 Workload Identity

  • 创建一个对备份位置具有读取权限的 Google Cloud IAM 服务账号

  • 将 IAM 服务账号绑定到 Neo4j 部署的 Kubernetes 服务账号*

[*] 您可以通过在 values.yaml 中设置 serviceAccountName 来配置 Neo4j 部署使用的 Kubernetes 服务账号的名称。要检查 Neo4j 部署正在使用的 Kubernetes 服务账号的名称，请运行 kubectl get pods -o=jsonpath='{.spec.serviceAccountName}{"\n"}' <您的 neo4j pod 名称>

如果您无法在 GKE 中使用 Workload Identity，则可以改为创建服务密钥 secret，如下一节所述。

创建服务密钥 secret 以访问云存储

首先，您需要创建一个包含账号服务密钥内容的 Kubernetes secret。此密钥必须具有访问您尝试恢复的 bucket 和备份集的权限。

AWS

  • 您必须创建凭据文件，该文件应如下所示

[default]
region=
aws_access_key_id=
aws_secret_access_key=

  • 您必须为此文件创建一个 secret

kubectl create secret generic neo4j-aws-credentials \
    --from-file=credentials=aws-credentials

GCP

如果您使用 GCP 的 Workload Identity，则无需遵循本节中的步骤。

  • 您必须创建凭据文件，该文件应如下所示

{
  "type": "",
  "project_id": "",
  "private_key_id": "",
  "private_key": "",
  "client_email": "",
  "client_id": "",
  "auth_uri": "",
  "token_uri": "",
  "auth_provider_x509_cert_url": "",
  "client_x509_cert_url": ""
}

  • 您必须为此文件创建一个 secret

kubectl create secret generic neo4j-gcp-credentials \
    --from-file=credentials=gcp-credentials.json

Azure

  • 您必须创建凭据文件，该文件应如下所示

export ACCOUNT_NAME=<NAME_STORAGE_ACCOUNT>
export ACCOUNT_KEY=<STORAGE_ACCOUNT_KEY>

  • 您必须为此文件创建一个 secret

kubectl create secret generic neo4j-azure-credentials \
    --from-file=credentials=azure-credentials.sh

如果此服务密钥 secret 未就位，则身份验证信息将无法作为卷挂载到 initContainer 中，并且您的 Pod 可能会卡在 ContainerCreating 阶段。

配置核心和只读副本节点的 initContainer

请参考单实例恢复部署场景，了解 initContainers 的配置方式。

您需要自定义和确保的内容： * 确保您已创建相应的 secret 并设置其名称 * 确保挂载到 /auth 的卷与您上面创建的 secret 名称匹配。* 确保您的 BUCKET 和凭据已根据您创建 secret 的方式正确设置。

上面的示例场景仅为核心节点创建了 initContainer。如果您正在使用只读副本，强烈建议您对 readReplica.initContainers 执行相同的操作。如果您仅恢复到核心节点而不恢复到只读副本，当它们启动时，核心节点会将数据复制到只读副本。这也能正常工作，但可能导致启动时间更长且带宽消耗更多。

为 Init Container 设置恢复环境变量

  • 要进行恢复，您需要将必要的参数添加到 values.yaml 中，该文件应如下所示

...
core:
  ...
  restore:
    enabled: true
    secretName: (neo4j-gcp-credentials|neo4j-aws-credentials|neo4j-azure-credentials|NULL) #required. Set NULL if using Workload Identity in GKE.
    database: neo4j,system #required
    cloudProvider: (gcp|aws|azure) #required
    bucket: (gs://|s3://)test-neo4j #required
    timestamp: "latest" #optional #default:"latest"
    forceOverwrite: true #optional #default:true
    purgeOnComplete: true #optinal #default:true
readReplica:
  ...
  restore:
    enabled: true
    secretName: (neo4j-gcp-credentials|neo4j-aws-credentials|neo4j-azure-credentials|NULL) #required. Set NULL if using Workload Identity in GKE.
    database: neo4j,system #required
    cloudProvider: (gcp|aws|azure) #required
    bucket: (gs://|s3://)test-neo4j #required
    timestamp: "2020-06-16-12:32:57" #optional #default:"latest"
    forceOverwrite: true #optional #default:true
    purgeOnComplete: true #optinal #default:true
...

  • 标准的 neo4j 安装从 neo4j-helm 的根目录运行 - 而不是 tools/restore。此外，它可以是您最初用于创建核心/副本的相同命令。

helm install \
    neo4j neo4j/neo4j \
    -f values.yaml \
    --set acceptLicenseAgreement=yes

警告和提示

一种常见的 Neo4j 部署方式是在容器初始化时从上次备份恢复。这对于集群来说是很好的，因为它可以最大程度地减少节点启动时所需的追赶。上次备份与集群其余部分之间的任何差异都将通过追赶提供。

对于单个节点，请在此处格外小心。

如果节点崩溃，并且您自动从备份恢复，并强制覆盖磁盘上的先前内容，您将丢失数据库在上次备份和崩溃之间捕获的任何数据。因此，对于 Neo4j 的单节点实例，您应该在需要时手动执行恢复，或者保持非常规律的备份计划以最大程度地减少数据丢失。如果数据丢失在任何情况下都不可接受，请不要自动恢复单节点部署。

Azure 存储的特别注意事项。参数需要一个“bucket”，但对于 Azure 存储，命名方式略有不同。没有像 AWS 或 Google 那样协议方案。指定的 bucket 是“blob 容器名称”，而不是账号名称，即文件被备份放置的位置，并且与您在备份章节中使用的“blob 容器名称”相同（假设您遵循了那里的示例）。相对路径将被尊重；如果您将 bucket 设置为 container/path/to/directory，则期望您的备份文件存储在 container 中，路径为 /path/to/directory/db/db-TIMESTAMP.tar.gz，其中“db”是要备份的数据库名称（例如 neo4j 和 system）。

运行恢复

在 initContainer 就绪并正确配置后，只需使用常规方法部署新集群。在启动之前，恢复将发生，当集群上线时，它将填充数据。

限制

  • 如果您希望恢复用户名、密码和权限，则必须包含系统图的恢复。

  • 容器尚未测试增量备份

© . All rights reserved.