> MemoryDB solves this by intercepting the Redis replication stream, redirecting it to the transaction log, and converting it into synchronous replication
Replication is eventually consistent in Redis - is it saying that it’s intercepting the stream at the source and blocking the write from completing until replication completes? Cause intercepting it at the point it’s going out (which is what the word interception implies to me) wouldn’t get you strong consistency I would think.
"Due to our choice of using passive replication, mutations are
executed on a primary node before being committed into the trans-
action log. If a commit fails, for example due to network isolation,
the change must not be acknowledged and must not become visible.
Other database engines use isolation mechanisms like Multi-Version
Concurrency Control (MVCC) to achieve this, but Redis data struc-
tures do not support this functionality, and it cannot be readily
decoupled from the database engine itself. Instead, MemoryDB
adds a layer of client blocking. After a client sends a mutation, the
reply from the mutation operation is stored in a tracker until the
transaction log acknowledges persistence and only then sent to the
client. Meanwhile, the Redis workloop can process other operations.
Non-mutating operations can be executed immediately but must
consult the tracker to determine if their results must also be delayed
until a particular log write completes. Hazards are detected at the
key level. If the value or data-structure in a key has been modified
by an operation which is not yet persisted, the responses to read
operations on that key are delayed until all data in that response is
persisted. Replica nodes do not require blocking as mutations are
only visible once committed to three AZs"
> MemoryDB solves this by intercepting the Redis replication stream, redirecting it to the transaction log, and converting it into synchronous replication
Replication is eventually consistent in Redis - is it saying that it’s intercepting the stream at the source and blocking the write from completing until replication completes? Cause intercepting it at the point it’s going out (which is what the word interception implies to me) wouldn’t get you strong consistency I would think.
"Due to our choice of using passive replication, mutations are executed on a primary node before being committed into the trans- action log. If a commit fails, for example due to network isolation, the change must not be acknowledged and must not become visible. Other database engines use isolation mechanisms like Multi-Version Concurrency Control (MVCC) to achieve this, but Redis data struc- tures do not support this functionality, and it cannot be readily decoupled from the database engine itself. Instead, MemoryDB adds a layer of client blocking. After a client sends a mutation, the reply from the mutation operation is stored in a tracker until the transaction log acknowledges persistence and only then sent to the client. Meanwhile, the Redis workloop can process other operations. Non-mutating operations can be executed immediately but must consult the tracker to determine if their results must also be delayed until a particular log write completes. Hazards are detected at the key level. If the value or data-structure in a key has been modified by an operation which is not yet persisted, the responses to read operations on that key are delayed until all data in that response is persisted. Replica nodes do not require blocking as mutations are only visible once committed to three AZs"