These are chat archives for atomix/atomix
Compactcommand that can be submitted by a
compact()method call on the client. The internal
ServerStateMachinehas access to the log and can just call
log.compactor().compact(). The only question is whether the client should be notified when compaction is complete. That would require the servers send an event back to the client, which is fine.
[Set(name, gardner), Delete(name, gardner), Set(name, john)]I would like to be able to pick an arbitrary offset
[1, 2, 3]and view the state machine at that point.
Committo essentially say it's still relevant to the state machine and shouldn't be compacted. A
Committhat's never released will never be compacted. But the contract is that the state machine is responsible for a commit until it has been released, and thereafter Copyat will ensure that its compacted from the log when it's safe to do so. When it's safe depends on the command's
CompactionModetoo. This is the more advanced compaction stuff. For
Snapshottablestate machines, by default commands can be compacted once a snapshot is taken. If a command uses some other
CompactionModeit just depends, e.g. a
TOMBSTONEhas to be held in the log and replicated until it's applied on all servers to make sure state is deleted on all servers, but a normal
QUORUMcommand can be compacted as soon as it's committed and released by the state machine, indicating it's no longer needed. The simplest thing to do is just implement
Snapshottableand immediately release all commands since they're presumably covered by the snapshot. Atomix uses the incremental compaction stuff. Basically, if a map key
foois overwritten by a later map key
foo, the first
foocommand can be released. But you could do version of by instead retaining it in an in-memory log.
SNAPSHOTcommands... The server may just automatically assume they can be compacted on the next snapshot.
CompactionMode.SNAPSHOT. That means commands are retained until the next snapshot and until events published by the state machine up to that index are acknowledged by all clients to ensure fault tolerance for events. If a state machine doesn’t implement
Snapshottable, commands default to
CompactionMode.QUORUMand the state machine is responsible for calling
Commits applied to the state machine to indicate when it’s safe to compact the command from the log. But for those types of state machines, if the state machine doesn’t properly set the
CompactionModefor a tombstone it could result in inconsistent state. If a tombstone is only applied on a majority of servers and not all servers, the state may be retained e.g. on a partitioned server if the tombstone is compacted from the log too soon and thus is never applied on that server. So
CompactionMode.TOMBSTONEis used to ensure those types of commands are handled properly. All that’s in the architecture documentation on log compaction, but it’s pretty heavy.
SEQUENTIALto replicate what I’m doing in zookeeper, aka a log with
[1, 2, 3, 4, 5]should never see 3 snapshotted before 1 or 2.