The article didn't go into depth of the server architecture. But in general all instances i wrote about were setted up as a classical Master <-> Slave connection. Sometimes with multiple slaves.
Related to persistence: It depends. It depends on your tooling around.
E.g. If you have a Master <-> Slave setup with persistence enabled, you have multiple options. BGSAVE on master only. BGSAVE on slave only. A seperate slave without traffic only for BGSAVE (to avoid the forking issue, many companies doing this) or BGSAVE on every node.
BGSAVE on every node can make sense of you have a running sentinel that propagades the slave as the new master once the master failed.
IMO it depends. We are running master <-> slave envs with persistence enabled on every node.
Were we don't need persistence there we are running only single instances that are combined by the client to a consistent hashing ring.
Does this answer your question? Any questions left i can answer?
The article didn't go into depth of the server architecture. But in general all instances i wrote about were setted up as a classical Master <-> Slave connection. Sometimes with multiple slaves.
Related to persistence: It depends. It depends on your tooling around. E.g. If you have a Master <-> Slave setup with persistence enabled, you have multiple options. BGSAVE on master only. BGSAVE on slave only. A seperate slave without traffic only for BGSAVE (to avoid the forking issue, many companies doing this) or BGSAVE on every node.
BGSAVE on every node can make sense of you have a running sentinel that propagades the slave as the new master once the master failed.
IMO it depends. We are running master <-> slave envs with persistence enabled on every node. Were we don't need persistence there we are running only single instances that are combined by the client to a consistent hashing ring.
Does this answer your question? Any questions left i can answer?