These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
Catalyst is now defunct. The portions of it that were kept are now in Atomix (mostly the buffers) and everything else has been replaced or rewritten.
Serialization was replaced with Kryo, and new messaging APIs for the Atomix use case were created.
Let there be multicast!
Wasn’t too hard to hack together. Seems to work alright. But I suspect the slight rearchitecting of nodes is going to take a little time to settle down.
So, here’s the new architecture:
CORE nodes can store Raft partitions and must be explicitly configured on all other
DATA nodes can store primary-backup partitions and don’t have to be configured, but if
CORE nodes exist they do have to know about them at startup
• Same goes for
CLIENT nodes, which don’t store any data
DATA nodes can run independently of
CLIENT nodes can discover each other through multicast or IPs
It should also be feasible to allow data and client nodes to discover partition groups as well, that way they don’t have to know about the core nodes either. Then, only the core nodes have to know about the core nodes, and data/client nodes can use multicast or IPs to find each other and the core nodes.
DATA, with only one known ip for a cluster, have it get in sync, then transition to a
DATAnodes are prone to network partitions, so that would risk split brain if e.g. two data nodes only see themselves and then switch to
CORE. The core nodes always have to be explicitly listed for that reason.