恢复 Neo4j 容器
| 此方法假定您拥有凭据并希望将备份存储在 Google Cloud Storage、AWS S3 或 Azure Blob Storage 上。如果不是这种情况，您需要根据所需的云存储方法调整恢复脚本，但这种方法适用于任何备份位置。 |
| 此方法仅适用于 Neo4j 4.0+。工具和 DBMS 本身在 3.5 和 4.0 之间发生了很大变化，此处的方法可能不适用于较旧的数据库，除非进行大量修改。 |
方法
恢复容器用作主集群中的initContainer。在 Neo4j 集群中的节点开始之前，恢复容器会复制备份集并将其恢复到适当的位置。当 initContainer 终止时，常规 Neo4j docker 实例将启动并从备份中断的地方继续执行。
此容器主要针对此代码库中backup容器生成的备份 .tar.gz 存档进行测试。我们建议您使用这种方法。如果您使用其他方法压缩自己的备份，请仔细检查restore.sh脚本，因为它需要对目录结构做出某些假设才能正确恢复。
为了从云存储读取备份文件，容器需要提供一些凭据或身份验证。可用机制取决于云服务提供商。
使用服务帐号访问云存储（仅限 Google Cloud）
GCP
Workload Identity 是在 GKE 中运行的应用程序访问 Google Cloud 服务的推荐方法，因为它具有更好的安全属性和可管理性。
按照GCP 指示进行操作
-
在您的 GKE 集群上启用 Workload Identity
-
创建具有备份位置读取权限的 Google Cloud IAMServiceAccount
-
将 IAMServiceAccount 绑定到 Neo4j 部署的 Kubernetes ServiceAccount*
[*] 您可以通过在 values.yaml 中设置serviceAccountName来配置 Neo4j 部署使用的 Kubernetes ServiceAccount 的名称。要检查 Neo4j 部署使用的 Kubernetes ServiceAccount 的名称，请运行kubectl get pods -o=jsonpath='{.spec.serviceAccountName}{"\n"}' <您的 neo4j pod 名称>
如果您无法在 GKE 中使用 Workload Identity，则可以创建服务密钥秘密，如下一节所述。
创建服务密钥秘密以访问云存储
首先，您需要创建一个包含您的帐号服务密钥内容的 Kubernetes 秘密。此密钥必须具有访问您尝试恢复的存储桶和备份集的权限。
AWS
-
您必须创建凭据文件，此文件应如下所示
[default]
region=
aws_access_key_id=
aws_secret_access_key=-
您必须为该文件创建一个秘密
kubectl create secret generic neo4j-aws-credentials \
--from-file=credentials=aws-credentialsGCP
如果您使用 Workload Identity for GCP，则无需执行本节中的步骤。
-
您必须创建凭据文件，此文件应如下所示
{
"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": ""
}-
您必须为该文件创建一个秘密
kubectl create secret generic neo4j-gcp-credentials \
--from-file=credentials=gcp-credentials.jsonAzure
-
您必须创建凭据文件，此文件应如下所示
export ACCOUNT_NAME=<NAME_STORAGE_ACCOUNT>
export ACCOUNT_KEY=<STORAGE_ACCOUNT_KEY>-
您必须为该文件创建一个秘密
kubectl create secret generic neo4j-azure-credentials \
--from-file=credentials=azure-credentials.sh如果该服务密钥秘密不存在，则身份验证信息将无法作为卷挂载到 initContainer 中，并且您的 pod 可能会卡在ContainerCreating阶段。
为核心节点和只读副本节点配置 initContainer
请参考单实例恢复部署场景以查看如何配置 initContainers。
您需要自定义和确保的内容：* 确保您已创建适当的秘密并设置其名称 * 确保挂载到 /auth 的卷与您在上面创建的秘密名称匹配。* 确保您的 BUCKET 和凭据根据您创建秘密的方式正确设置。
上面的示例场景仅为核心节点创建 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-helm 根目录运行的标准 neo4j 安装 - 不是 tools/restore。此外，它可能是您最初创建核心/副本时运行的相同命令。
helm install \
neo4j neo4j/neo4j \
-f values.yaml \
--set acceptLicenseAgreement=yes警告和提示
您部署 Neo4j 的一种常见方法是在容器初始化时从最后一个备份恢复。这对于集群来说是不错的选择，因为它可以最大限度地减少启动节点时所需的追赶量。最后一个备份和集群其余部分之间的任何差异都将通过追赶来提供。
| 对于单节点，请在此处格外小心。 |
如果一个节点崩溃，您自动从备份恢复并强制覆盖磁盘上的先前内容，您将丢失数据库在上次备份完成时到崩溃发生时之间捕获的任何数据。因此，对于 Neo4j 的单节点实例，您应该在需要时手动执行恢复，或者您应该保持非常规律的备份计划以最大限度地减少数据丢失。如果数据丢失在任何情况下都是不可接受的，请不要自动恢复单节点部署。
Azure Storage 的特别说明。参数需要一个“存储桶”，但对于 Azure 存储，命名略有不同。与 AWS 或 Google 相比，没有协议方案。指定的存储桶是“blob 容器名称”，而不是帐户名称。备份文件将在该位置放置，并且与您在备份一章中使用的“blob 容器名称”相同，假设您按照那里的示例操作。将尊重相对路径；如果您将存储桶设置为container/path/to/directory，则预期您的备份文件存储在container的/path/to/directory/db/db-TIMESTAMP.tar.gz路径下，其中“db”是正在备份的数据库的名称（即 neo4j 和系统）。 |