关于H2数据库中CreateCluster工具的问题
我对 H2 创建集群工具的行为有几个问题。
如果创建一个指定源 A 和目标 B 的集群，H 会让 B 与 A 保持同步吗？换句话说，两者之间是否存在主从关系？
假设数据库 A、B 和 C 属于同一个集群。如果在 A 和 B 上同时执行两个不同的事务会发生什么？ H2 是否会在集群中选出一个领导者来确保集群中的所有数据库都有唯一的执行顺序？
如果H2选举了一个领导者，如果这个领导者消失了怎么办？是否有自动故障转移机制？新领导人是自动选举产生的吗？我还可以
- 如果我使用源 A 创建集群， ？目标 B，然后源 B ->目标C，然后源C ->目标 D，D 是否会从 C 获取要执行的语句，C 从 B 获取要执行的语句，B 是否会从 A 获取要执行的语句？或者 B、C 和 D 会从 A（或当选的领导者）那里得到执行语句吗？换句话说，我们有链式组织还是星形组织？
I have a couple of questions about H2's create cluster tool's behavior.
If a create a cluster specifying source A and target B, is H going to keep B in synch with A? In other words, is there a master-slave relationship maintained between both?
Let's imagine that database A, B and C belong to the same cluster. What happens if two different transactions are executed on A and B simultaneoulsy. Does H2 elect a leader in the cluster to make sure there is a unique execution order for all databases in the cluster?
If H2 elects a leader, what if this leader disappears? Is there an automatic failover mecanism? Is a new leader automatically elected? Can I still
If I create a cluster with source A -> target B, then source B -> target C, then source C -> target D, will D get statements to execute from C, C get executions statements from B and B get statements to execute for A? Or will B, C and D get execution statements from A (or the elected leader)? In other words, do we have a chain or star organization?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
请参阅 H2 网站上的集群文档。
集群节点之间没有主/从，没有领导者，也没有连接。相反，每个客户端都连接到两个集群节点并在两个节点上执行语句。
每个客户端都以相同的顺序在所有集群节点上执行所有语句。每个客户端都有一个集群节点列表，每个集群节点也保存该列表。客户端验证列表是否相同。
没有领导者。故障转移机制是：如果客户端失去与其中一个集群节点的连接，它会从其列表中删除该集群节点，并告诉每个集群节点从列表中删除该集群节点。
这只会扩展列表，以便您获得 A、B、C、D。然后，每个客户端将在每个集群节点上执行所有更新语句。
See the cluster documentation on the H2 web site.
There is no master / slave, no leader, and no connection between the cluster nodes. Instead, each client connects to both cluster nodes and executes the statements on both.
Each client executes all statements on all cluster nodes, in the same order. Each client has a list of cluster nodes, and each cluster node keeps the list as well. The clients verify the list is the same.
There is no leader. The failover mechanism is: if a client loses the connection to one of the cluster node, it removes that cluster node from it's list, and tells each cluster node to remove the cluster node from the list.
This will just expand the list so you get A, B, C, D. Each client will then execute all update statements on each cluster node.