为什么我的Apache Ignite持久存储保持锁定？
我有一个将Apache Ignite用作单节点集群的应用程序。也就是说，Ignite由应用程序启动和停止，其生命周期与应用程序匹配。
Ignite缓存同时启用了持久存储和读通。所以
- 首先调用cache.get
所有这一切似乎都运转得很好。这是我的问题：有时（经常）当应用程序被跳转或重新部署时，持久存储区数据目录就Apache Ignite而言仍然保持锁定状态。因此，Ignite会无声地创建一个新的空持久性存储，这违背了持久性存储的全部目的。
我们的数据目录当前如下所示：
-sh-4.2$ pwd
/myapp/oracle/user_projects/domains/myapp_inst/igniteCache/myserver/data
-sh-4.2$ ls -ltr
total 48
drwxr-x---. 10 mygroup mygroup 4096 Jan 9 16:25 node00-7c02d9ab-7ef3-4d01-8ebd-d1184fa281a2
drwxr-x---. 10 mygroup mygroup 4096 Jan 9 17:28 node01-06a5d059-1b62-4ac2-84bf-5325deac8138
drwxr-x---. 10 mygroup mygroup 4096 Feb 4 15:39 node02-ba720d52-570a-448c-9109-75687ee664e7
drwxr-x---. 10 mygroup mygroup 4096 Feb 5 12:16 node03-d2c521aa-e0ee-471b-ad16-08af382a1e3d
drwxr-x---. 10 mygroup mygroup 4096 Feb 6 17:44 node04-505e754e-a3d3-48b1-a759-d5ec8867dc96
drwxr-x---. 10 mygroup mygroup 4096 Feb 6 18:23 node05-ec0f89e3-bfe5-4bb6-87da-302951439f66
drwxr-x---. 10 mygroup mygroup 4096 Feb 13 15:41 node06-5b9dc33a-42f6-4f1c-8d57-14d5ddb30dc5
drwxr-x---. 10 mygroup mygroup 4096 Feb 13 15:43 node07-47aacde5-2598-4a85-9383-761e569bb1d1
drwxr-x---. 10 mygroup mygroup 4096 Feb 13 15:47 node08-0374a51d-4b90-4e5a-9465-adabc900ea0b
drwxr-x---. 10 mygroup mygroup 4096 Feb 13 15:52 node09-610c69c6-35e0-4d74-90db-6be09bb77659
-rw-r-----. 1 mygroup mygroup 41 Feb 13 17:00 lock
drwxr-x---. 10 mygroup mygroup 4096 Feb 13 17:00 node10-f115d95b-7b76-41e0-bd32-966030331c9c
应该只有一个“nodeXX…”上面的目录。
问题
- 我能为我的应用程序做些什么来确保，无论发生什么故障，持久存储锁都会被释放
真的，我所能做的任何事情都会有帮助。
共有1个答案
请设置Ignite ConsistentId:igniteCfg。setConsistentId（“My\u Node\u Id”Id）；https://apacheignite.readme.io/docs/distributed-persistent-store#section-持久路径管理
在这种情况下，ignite将尝试获取文件锁并等待10秒，如果无法获取，则不会创建新文件夹，但会出现异常。
-
最近我发现了一个像Apache Mesos这样的东西。 在所有演示和示例中，这一切看起来都令人惊讶。我可以很容易地想象一个人将如何竞选无状态的工作--这自然符合整个想法。 3-请告诉我的方法在哲学方面是否是错误的（数据服务器的DFS和Mesos顶部的postgres之类的服务器的某种切换） 问题主要是从Apache Mesos的持久存储中复制的，由程序员堆栈交换上的zerkms提出。
-
本平台是通过storageclass来动态创建PV。也就是说咱们依赖于storageclass，如果您的Kubernetes不支持相应的存储试，将无法非常方便的进行挂载。 目前暂不支持挂载多个PVC，或许以后会更新吧。 这里演示的是用的NFS进行演示，实际使用时可根据自己的需求配置相应的provisioner，其他配置是一样的不需要调整，只需要在“模版管理” 调整StorageClass和Pers
-
我的CN1应用程序在这里生成文件filesystemstorage.getinstance（）.getapphomePath（）。我可以正确地读/写那里的文件。 此文件夹名类似于:- 我如何保证这部分保持不变？谢谢你的帮助。
-
本地持久化卷允许用户通过标准 PVC 接口以简单便携的方式访问本地存储。PV 中包含系统用于将 Pod 安排到正确节点的节点亲和性信息。 一旦配置了本地卷，外部静态配置器（provisioner）可用于帮助简化本地存储管理。请注意，本地存储配置器与大多数配置器不同，并且尚不支持动态配置。相反，它要求管理员预先配置每个节点上的本地卷，并且这些卷应该是： Filesystem volumeMode（默
-
持久化存储的相关配置 这里使用的是NFS的方式进行持久化，如果您有自己的持久化方案可以不使用改方案。 $ kubectl apply -f install/kubernetes/storage/serviceaccount.yaml $ kubectl apply -f install/kubernetes/storage/rbac.yaml $ kubectl apply -f install/
-
主要内容：一、数据持久化,二、持久化的形式,三、源码分析,四、总结一、数据持久化 redis做为一种内存型数据库，做持久化，个人感觉略有鸡肋的意思。似乎有一种，别人有，自己不有也不行的感觉。以目前Redis主流的应用方式，如果仔细分析，基本上都是在内存中即可完成，对持久化没要求或者说不大。再举一个反例，如果内存中有几百G甚至更多的数据，真要是整体当机，恢复的时间基本就是灾难。 目前基本应用仍然是以关系型数据库或者其它数据库（如Hadoop，Mysql等）为持久化