> Not. The data-preserving mechanisms (e.g. view/epoch IDs) are so easy to implement in this case that leaving them out is unjustifiable. You even seem to be coming around to that view yourself when you say "in the future yes" but apparently you can't bring yourself to admit that it was always the right choice.
It's up to you to form your opinion, but here are the facts:
1) Before diskless replication: even a master with persistence turned down, had to persist on disk, in order to support slaves.
2) Because of "1", it looked like futile to support this model of operations.
3) "1" is no longer true, I merged the diskless replication stuff just this morning.
Still I don't think you can form a fully informed idea unless you consider this: if you have persistence turned on in a setup which uses replication, like in most deployments using replication, you absolutely want the old behavior of Redis, of slaves reconnecting and replicating again on master restarts.
So when I say, in the future this could change, it is just as an opt-in option in order to support this new use case, not to say, the old behavior was crazy.
It's up to you to form your opinion, but here are the facts:
1) Before diskless replication: even a master with persistence turned down, had to persist on disk, in order to support slaves.
2) Because of "1", it looked like futile to support this model of operations.
3) "1" is no longer true, I merged the diskless replication stuff just this morning.
Still I don't think you can form a fully informed idea unless you consider this: if you have persistence turned on in a setup which uses replication, like in most deployments using replication, you absolutely want the old behavior of Redis, of slaves reconnecting and replicating again on master restarts.
So when I say, in the future this could change, it is just as an opt-in option in order to support this new use case, not to say, the old behavior was crazy.