Kubernetes 部署 ArcadeDB:从单实例到生产级 HA 集群【免费下载链接】arcadedbArcadeDB Multi-Model Database, one DBMS that supports SQL, Cypher, Gremlin, HTTP/JSON, MongoDB and Redis. ArcadeDB is a conceptual fork of OrientDB, the first Multi-Model DBMS. ArcadeDB supports Vector Embeddings.项目地址: https://gitcode.com/gh_mirrors/ar/arcadedbArcadeDB 是一款支持 SQL、Cypher、Gremlin、HTTP/JSON、MongoDB 与 Redis 协议的多模型数据库,并且原生支持向量嵌入(Vector Embeddings)。本文将手把手教你如何在 Kubernetes 上部署 ArcadeDB,从最简单的单实例 Helm 安装开始,一步步演进到 3 节点 Raft 共识的生产级 HA 高可用集群,并给出探针配置、持久化与故障演练等完整实践,适合数据库运维与平台工程师参考。ArcadeDB 是什么:一个数据库,六种协议ArcadeDB 源自 OrientDB 的概念分支,是第一个多模型 DBMS 的继任者。它的核心卖点在于:一套存储引擎,同时提供图、文档、键值、时间序列和向量检索能力,并且对客户端说多种语言:接入方式说明SQL原生 SQL,含CREATE VERTEX等图扩展Cypher兼容 Neo4j 生态的图查询语言GremlinTinkerPop 标准图遍历语言HTTP/JSONREST 风格 API,默认端口 2480MongoDBWire 协议兼容(端口 27017)Redis键值协议兼容(端口 6379)这意味着你的团队无需为每种数据模型单独维护一套数据库,一个 ArcadeDB 集群即可统一承载。相关能力源码可参考 gremlin/、mongodbw/、redisw/、postgresw/ 等模块。为什么选择 Kubernetes 部署 ArcadeDB声明式管理:Pod、Service、PVC 全部由 YAML 定义,版本可回溯;弹性伸缩:借助 HPA 按负载伸缩只读副本;故障自愈:节点崩溃后自动重建并重新加入 Raft 集群;统一运维:探针、滚动更新、存储卷与监控一体化。官方 Helm Chart 已迁移到独立仓库,仓库安装说明见 k8s/README.md。若需从源码构建镜像,可参考 package/ 目录下的 Dockerfile 与打包脚本。前置条件:一分钟检查清单一个可用的 Kubernetes 集群(1.24),建议 ≥3 节点;已安装 Helm v3;已安装 kubectl 并配置好 kubeconfig;集群具备默认 StorageClass(用于 PVC 动态供应)。第一步:Helm 快速安装单实例 ArcadeDB最快的上手方式是通过 Helm Chart 一条命令拉起单实例:helm repo add arcadedb https://helm.arcadedb.com/ helm repo update helm install my-arcadedb arcadedb/arcadedb安装完成后,查看资源状态:kubectl get pods -l app.kubernetes.io/namearcadedb默认 Chart 会创建一个单副本 StatefulSet、一个 ClusterIP Service(HTTP 2480 / RPC 2424)。如果你想在本地快速体验,也可以参考仓库根目录的 docker-compose.yml,用docker compose up一键起一个带 OpenBeer 示例数据的容器。第二步:配置健康检查探针,让集群自愈K8s 靠探针判断 Pod 是否存活、是否就绪。ArcadeDB 在 API 端口(默认 2480)暴露了两个探针端点:GET /api/v1/health—存活探针:进程与 HTTP 层正常即返回 204,不做数据库 I/O,适合livenessProbe;GET /api/v1/ready—就绪探针:服务器进入ONLINE状态返回 204;当设置arcadedb.server.readinessRequiresHAtrue且 HA 开启时,节点未加入 Raft 组或尚未追平日志会返回 503,直到追上为止。推荐探针配置如下:livenessProbe: httpGet: { path: /api/v1/health, port: 2480 } initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: { path: /api/v1/ready, port: 2480 } initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3关键点:就绪探针务必用/api/v1/ready而非/api/v1/health。否则滚动重启时,未追平日志的节点仍会被标记就绪,可能破坏写仲裁(quorum)。第三步:从单实例升级到 3 节点生产级 HA 集群单实例无法应对节点故障。ArcadeDB 的 HA 基于Apache Ratis 实现的 Raft 共识算法:数据在 Leader 写入后复制到多数派(Follower),Leader 宕机后自动选举新 Leader,写入仅在多数派可用时进行,从根本上避免脑裂与数据丢失。仓库提供了开箱即用的 StatefulSet 示例:package/src/main/config/arcadedb-statefulset.yaml。它包含四个关键对象:对象作用Namespace隔离环境,默认arcadedbLoadBalancer Service对外暴露 HTTP 2480 端口Headless Service提供arcadedb-0.arcadedb...形式的 Pod DNS,供集群发现StatefulSet管理 3 个有序启动的 Pod,自带 PVC 模板核心 HA 配置通过 JVM 参数注入:-Darcadedb.ha.enabledtrue -Darcadedb.ha.serverListarcadedb-0.arcadedb.default.svc.cluster.local:2424 -Darcadedb.ha.k8strue -Darcadedb.ha.k8sSuffix.arcadedb.default.svc.cluster.local -Darcadedb.ha.replicationIncomingHost0.0.0.0 -Darcadedb.ha.raftStorageDirectory/mnt/data0/raft -Darcadedb.ha.raftPersistStoragetrue各参数含义如下:arcadedb.ha.enabled— 开启 HA 复制;arcadedb.ha.serverList— 初始成员列表,只需给出第一个成员,k8strue时节点会通过 DNS 后缀自动发现并加入其余成员;arcadedb.ha.k8s/arcadedb.ha.k8sSuffix— 声明运行在 Kubernetes 中,并指定 StatefulSet 的 DNS 后缀,实现自动组网;arcadedb.ha.raftPersistStorage— 将 Raft 日志持久化到 PVC(挂载于/mnt/data0),节点重启后无需全量快照重同步,这是生产环境的必选项。上述参数在 engine/src/main/java/com/arcadedb/GlobalConfiguration.java 中均有定义,集群实现见 ha-raft/src/main/java/com/arcadedb/server/ha/raft/RaftHAServer.java。启动集群:kubectl apply -f arcadedb-statefulset.yaml kubectl get pods -w # 观察 arcadedb-0/1/2 依次 ReadyPod 反亲和(podAntiAffinity)已内置,确保 3 个节点尽量分布在不同宿主机上,避免单机故障拖垮整个集群。第四步:生产环境加固的 5 个最佳实践开启 HA 感知就绪:设置环境变量ARCADEDB_SERVER_READINESSREQUIRESHAtrue,让滚动更新期间未追平日志的节点不进入 Service 端点,保证写仲裁稳定;使用 SSD 存储:Raft 日志与数据库文件对延迟敏感,生产环境请选择 SSD 类型的 StorageClass,而非示例中的普通卷;按需开启 HPA:Helm Chart 支持autoscaling.enabled,注意minReplicas必须 ≥3 且为奇数,否则无法形成多数派,Chart 内置了 quorum 守卫校验;Ingress 与 NetworkPolicy:对外访问建议走 Ingress,内部仅放通 2424(Raft/RPC)与 2480(HTTP),可用 Chart 内置的networkPolicy.enabled;定期备份:HA 保证的是高可用而非误删保护,仍需通过导出或快照定期备份数据。第五步:故障演练——Leader 挂了会发生什么仓库的 e2e 测试真实模拟了这些场景,见 e2e-ha/src/test/java/com/arcadedb/containers/ha/LeaderFailoverIT.java,以及 NetworkPartition、SplitBrain、RollingRestart 等用例。以杀掉 Leader为例,流程为:3 节点写入 20 条数据,确认三副本一致;定位当前 Leader,直接stop()该容器;存活节点在约数秒内自动选举出新 Leader,继续写入成功;重启被杀节点,它通过 Raft 日志追赶(catch-up)自动重新同步数据,最终三节点数据完全一致。这套测试即生产事故彩排——在真正上线前,建议你在测试环境用kubectl delete pod leader-pod演练一遍同样的流程。总结:从单实例到 HA 集群的路线图阶段方式适用场景单实例helm install开发、测试、Demo3 节点 HAStatefulSet Raft生产环境多活扩展HPA 只读副本高并发读写核心要点只有四个:用 StatefulSet 保序启动、用 Headless Service 自动发现、用 PVC 持久化 Raft 日志、用/api/v1/ready做 HA 感知探针。按本文步骤操作,你就能在 Kubernetes 上跑起一套具备自动故障转移、自动重同步能力,同时兼容六种协议的 ArcadeDB 生产级 HA 集群。【免费下载链接】arcadedbArcadeDB Multi-Model Database, one DBMS that supports SQL, Cypher, Gremlin, HTTP/JSON, MongoDB and Redis. ArcadeDB is a conceptual fork of OrientDB, the first Multi-Model DBMS. ArcadeDB supports Vector Embeddings.项目地址: https://gitcode.com/gh_mirrors/ar/arcadedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes 部署 ArcadeDB:从单实例到生产级 HA 集群
Kubernetes 部署 ArcadeDB:从单实例到生产级 HA 集群【免费下载链接】arcadedbArcadeDB Multi-Model Database, one DBMS that supports SQL, Cypher, Gremlin, HTTP/JSON, MongoDB and Redis. ArcadeDB is a conceptual fork of OrientDB, the first Multi-Model DBMS. ArcadeDB supports Vector Embeddings.项目地址: https://gitcode.com/gh_mirrors/ar/arcadedbArcadeDB 是一款支持 SQL、Cypher、Gremlin、HTTP/JSON、MongoDB 与 Redis 协议的多模型数据库,并且原生支持向量嵌入(Vector Embeddings)。本文将手把手教你如何在 Kubernetes 上部署 ArcadeDB,从最简单的单实例 Helm 安装开始,一步步演进到 3 节点 Raft 共识的生产级 HA 高可用集群,并给出探针配置、持久化与故障演练等完整实践,适合数据库运维与平台工程师参考。ArcadeDB 是什么:一个数据库,六种协议ArcadeDB 源自 OrientDB 的概念分支,是第一个多模型 DBMS 的继任者。它的核心卖点在于:一套存储引擎,同时提供图、文档、键值、时间序列和向量检索能力,并且对客户端说多种语言:接入方式说明SQL原生 SQL,含CREATE VERTEX等图扩展Cypher兼容 Neo4j 生态的图查询语言GremlinTinkerPop 标准图遍历语言HTTP/JSONREST 风格 API,默认端口 2480MongoDBWire 协议兼容(端口 27017)Redis键值协议兼容(端口 6379)这意味着你的团队无需为每种数据模型单独维护一套数据库,一个 ArcadeDB 集群即可统一承载。相关能力源码可参考 gremlin/、mongodbw/、redisw/、postgresw/ 等模块。为什么选择 Kubernetes 部署 ArcadeDB声明式管理:Pod、Service、PVC 全部由 YAML 定义,版本可回溯;弹性伸缩:借助 HPA 按负载伸缩只读副本;故障自愈:节点崩溃后自动重建并重新加入 Raft 集群;统一运维:探针、滚动更新、存储卷与监控一体化。官方 Helm Chart 已迁移到独立仓库,仓库安装说明见 k8s/README.md。若需从源码构建镜像,可参考 package/ 目录下的 Dockerfile 与打包脚本。前置条件:一分钟检查清单一个可用的 Kubernetes 集群(1.24),建议 ≥3 节点;已安装 Helm v3;已安装 kubectl 并配置好 kubeconfig;集群具备默认 StorageClass(用于 PVC 动态供应)。第一步:Helm 快速安装单实例 ArcadeDB最快的上手方式是通过 Helm Chart 一条命令拉起单实例:helm repo add arcadedb https://helm.arcadedb.com/ helm repo update helm install my-arcadedb arcadedb/arcadedb安装完成后,查看资源状态:kubectl get pods -l app.kubernetes.io/namearcadedb默认 Chart 会创建一个单副本 StatefulSet、一个 ClusterIP Service(HTTP 2480 / RPC 2424)。如果你想在本地快速体验,也可以参考仓库根目录的 docker-compose.yml,用docker compose up一键起一个带 OpenBeer 示例数据的容器。第二步:配置健康检查探针,让集群自愈K8s 靠探针判断 Pod 是否存活、是否就绪。ArcadeDB 在 API 端口(默认 2480)暴露了两个探针端点:GET /api/v1/health—存活探针:进程与 HTTP 层正常即返回 204,不做数据库 I/O,适合livenessProbe;GET /api/v1/ready—就绪探针:服务器进入ONLINE状态返回 204;当设置arcadedb.server.readinessRequiresHAtrue且 HA 开启时,节点未加入 Raft 组或尚未追平日志会返回 503,直到追上为止。推荐探针配置如下:livenessProbe: httpGet: { path: /api/v1/health, port: 2480 } initialDelaySeconds: 10 periodSeconds: 10 failureThreshold: 3 readinessProbe: httpGet: { path: /api/v1/ready, port: 2480 } initialDelaySeconds: 5 periodSeconds: 5 failureThreshold: 3关键点:就绪探针务必用/api/v1/ready而非/api/v1/health。否则滚动重启时,未追平日志的节点仍会被标记就绪,可能破坏写仲裁(quorum)。第三步:从单实例升级到 3 节点生产级 HA 集群单实例无法应对节点故障。ArcadeDB 的 HA 基于Apache Ratis 实现的 Raft 共识算法:数据在 Leader 写入后复制到多数派(Follower),Leader 宕机后自动选举新 Leader,写入仅在多数派可用时进行,从根本上避免脑裂与数据丢失。仓库提供了开箱即用的 StatefulSet 示例:package/src/main/config/arcadedb-statefulset.yaml。它包含四个关键对象:对象作用Namespace隔离环境,默认arcadedbLoadBalancer Service对外暴露 HTTP 2480 端口Headless Service提供arcadedb-0.arcadedb...形式的 Pod DNS,供集群发现StatefulSet管理 3 个有序启动的 Pod,自带 PVC 模板核心 HA 配置通过 JVM 参数注入:-Darcadedb.ha.enabledtrue -Darcadedb.ha.serverListarcadedb-0.arcadedb.default.svc.cluster.local:2424 -Darcadedb.ha.k8strue -Darcadedb.ha.k8sSuffix.arcadedb.default.svc.cluster.local -Darcadedb.ha.replicationIncomingHost0.0.0.0 -Darcadedb.ha.raftStorageDirectory/mnt/data0/raft -Darcadedb.ha.raftPersistStoragetrue各参数含义如下:arcadedb.ha.enabled— 开启 HA 复制;arcadedb.ha.serverList— 初始成员列表,只需给出第一个成员,k8strue时节点会通过 DNS 后缀自动发现并加入其余成员;arcadedb.ha.k8s/arcadedb.ha.k8sSuffix— 声明运行在 Kubernetes 中,并指定 StatefulSet 的 DNS 后缀,实现自动组网;arcadedb.ha.raftPersistStorage— 将 Raft 日志持久化到 PVC(挂载于/mnt/data0),节点重启后无需全量快照重同步,这是生产环境的必选项。上述参数在 engine/src/main/java/com/arcadedb/GlobalConfiguration.java 中均有定义,集群实现见 ha-raft/src/main/java/com/arcadedb/server/ha/raft/RaftHAServer.java。启动集群:kubectl apply -f arcadedb-statefulset.yaml kubectl get pods -w # 观察 arcadedb-0/1/2 依次 ReadyPod 反亲和(podAntiAffinity)已内置,确保 3 个节点尽量分布在不同宿主机上,避免单机故障拖垮整个集群。第四步:生产环境加固的 5 个最佳实践开启 HA 感知就绪:设置环境变量ARCADEDB_SERVER_READINESSREQUIRESHAtrue,让滚动更新期间未追平日志的节点不进入 Service 端点,保证写仲裁稳定;使用 SSD 存储:Raft 日志与数据库文件对延迟敏感,生产环境请选择 SSD 类型的 StorageClass,而非示例中的普通卷;按需开启 HPA:Helm Chart 支持autoscaling.enabled,注意minReplicas必须 ≥3 且为奇数,否则无法形成多数派,Chart 内置了 quorum 守卫校验;Ingress 与 NetworkPolicy:对外访问建议走 Ingress,内部仅放通 2424(Raft/RPC)与 2480(HTTP),可用 Chart 内置的networkPolicy.enabled;定期备份:HA 保证的是高可用而非误删保护,仍需通过导出或快照定期备份数据。第五步:故障演练——Leader 挂了会发生什么仓库的 e2e 测试真实模拟了这些场景,见 e2e-ha/src/test/java/com/arcadedb/containers/ha/LeaderFailoverIT.java,以及 NetworkPartition、SplitBrain、RollingRestart 等用例。以杀掉 Leader为例,流程为:3 节点写入 20 条数据,确认三副本一致;定位当前 Leader,直接stop()该容器;存活节点在约数秒内自动选举出新 Leader,继续写入成功;重启被杀节点,它通过 Raft 日志追赶(catch-up)自动重新同步数据,最终三节点数据完全一致。这套测试即生产事故彩排——在真正上线前,建议你在测试环境用kubectl delete pod leader-pod演练一遍同样的流程。总结:从单实例到 HA 集群的路线图阶段方式适用场景单实例helm install开发、测试、Demo3 节点 HAStatefulSet Raft生产环境多活扩展HPA 只读副本高并发读写核心要点只有四个:用 StatefulSet 保序启动、用 Headless Service 自动发现、用 PVC 持久化 Raft 日志、用/api/v1/ready做 HA 感知探针。按本文步骤操作,你就能在 Kubernetes 上跑起一套具备自动故障转移、自动重同步能力,同时兼容六种协议的 ArcadeDB 生产级 HA 集群。【免费下载链接】arcadedbArcadeDB Multi-Model Database, one DBMS that supports SQL, Cypher, Gremlin, HTTP/JSON, MongoDB and Redis. ArcadeDB is a conceptual fork of OrientDB, the first Multi-Model DBMS. ArcadeDB supports Vector Embeddings.项目地址: https://gitcode.com/gh_mirrors/ar/arcadedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
