具有多进程应用程序的 ChronicleMap Recovery
ChronicleMap Recovery with multi process application
我们正在评估 ChronicleMap，我们的应用程序运行集群模式，节点数从 5 到 45 个不等。计划将 ChronicleMap 持久保存在共享 NFS 文件夹中，以便所有节点都可以 read/write。
在 read/write 操作的过程中，个别节点更有可能因各种原因宕机。我有一些问题
- 如果node-1在写操作的过程中宕机，集群中另一个健康的node-2是否还能继续read/write 到文件？
- 假设我们实现了一些逻辑来检测服务器崩溃并在重启时调用 .recoverPersistedTo()。当集群中的其他健康节点对文件 reading/writing 时，这会导致任何问题吗？我问这个问题的原因是文件说
“You must ensure that no other process is accessing the Chronicle Map
store when calling .recoverPersistedTo()”
- 我读到使用 .recoverPersistedTo() 代替 createPersistedTo() 不是一个好的做法，但是什么是缺点？
首先，我们 (Chronicle) 不支持将 Chronicle Map 文件放在 NFS 上（因为我们使用内存映射，而 NFS 已知会导致问题）。此外，尝试在 NFS 上使用恢复将导致数据损坏，因为 NFS 上没有足够的文件锁定，并且恢复会尝试锁定文件以防止多个进程同时恢复。一般来说，开源 Chronicle Map 应该被同一主机上的多个进程使用。
您的问题解决方案是商用Map Enterprise，支持节点间地图复制，详情请联系sales@chronicle.software
我们正在评估 ChronicleMap，我们的应用程序运行集群模式，节点数从 5 到 45 个不等。计划将 ChronicleMap 持久保存在共享 NFS 文件夹中，以便所有节点都可以 read/write。
在 read/write 操作的过程中，个别节点更有可能因各种原因宕机。我有一些问题
- 如果node-1在写操作的过程中宕机，集群中另一个健康的node-2是否还能继续read/write 到文件？
- 假设我们实现了一些逻辑来检测服务器崩溃并在重启时调用 .recoverPersistedTo()。当集群中的其他健康节点对文件 reading/writing 时，这会导致任何问题吗？我问这个问题的原因是文件说
“You must ensure that no other process is accessing the Chronicle Map store when calling .recoverPersistedTo()”
- 我读到使用 .recoverPersistedTo() 代替 createPersistedTo() 不是一个好的做法，但是什么是缺点？
首先，我们 (Chronicle) 不支持将 Chronicle Map 文件放在 NFS 上（因为我们使用内存映射，而 NFS 已知会导致问题）。此外，尝试在 NFS 上使用恢复将导致数据损坏，因为 NFS 上没有足够的文件锁定，并且恢复会尝试锁定文件以防止多个进程同时恢复。一般来说，开源 Chronicle Map 应该被同一主机上的多个进程使用。
您的问题解决方案是商用Map Enterprise，支持节点间地图复制，详情请联系sales@chronicle.software