neo4j 迁移_在Kubernetes中迁移Neo4j图模式

neo4j 迁移

在零停机时间下运行企业应用程序时，我们需要能够执行数据库架构迁移而又不中断活动用户。这不仅对于关系数据库很重要，而且对于诸如Neo4J之类的图数据库也很重要，后者不会在write上强制执行架构。但是，重构图形并使图形数据模型与应用程序保持同步仍然有意义。在以下视频中，我将解释如何在托管的Kubernetes环境中迁移到由Cypher脚本定义的架构版本，该脚本受版本控制。

我在Cypher迁移脚本和CLI模式下有用的neo4j-migrations工具中使用了基于文件的方法。该工具将当前模式版本存储在图形中，并且如果之前未针对给定版本执行过迁移，则将应用所需的迁移。当前所有迁移脚本和工具都打包到Docker映像中，我们从该映像中将图形迁移到最新版本。

coffee-shop应用程序将在实际应用程序启动之前，部署并运行从该迁移Docker映像启动的init容器。这样，将始终针对预期的架构版本执行应用程序。与零停机时间一起执行数据库架构迁移时，我们一如既往必须考虑N-1兼容性 ，这可能需要我们在迁移完成之前部署多个应用程序版本。

自己尝试

您可以在Playground Quarkus应用程序中找到迁移示例，该应用程序已经扩展了我在视频中显示的资源。

这类似于在容器内部运行的内容：

 gt; ls /cyphers/ V001__SchemaMasterData.cypher V002__AddFlavorName.cypher V003__RemoveFlavorDescription.cypher

 gt; ./neo4j-migrations --address <neo4j-address> \ --password <pw> \ --location file: gt; ./neo4j-migrations --address <neo4j-address> \ --password <pw> \ --location file: ///cyphers/ migrate Applied migration 001 ("SchemaMasterData") Applied migration 002 ("AddFlavorName") Applied migration 003 ("RemoveFlavorDescription") Database migrated to version 003.

在部署新版本的实际应用程序之前，我们通过运行Kubernetes初始化容器来应用迁移。通过确保旧应用程序版本和当前应用程序版本都与图模式兼容，我们可以在不停机的情况下进行迁移。

初始化容器使用类似于应用程序容器的配置来连接Neo4J实例：

 # [...] initContainers: - name: schema-migration image: sdaschner/neo4j-coffee-shop-migration:v001 env: - name: NEO4J_ADDRESS value: "bolt://graphdb-neo4j:7687" - name: NEO4J_PASSWORD valueFrom: secretKeyRef: name: graphdb-neo4j-secrets key: neo4j-password

所示示例相当基本，但是提供了所有必需的支架，以支持数据迁移，从而在我们的管道中实现零停机时间部署。

您可能还想看看Neo4J中可用的APOC迁移过程。

与往常一样，至关重要的是预先测试更改，尤其是在涉及的数据方面，例如，首先将其部署到专用测试或暂存环境中，并确保迁移脚本按预期工作。通过将这些内容纳入我们的业务流程，我们可以提高开发速度和质量。

更多资源