Full support for DB numbers other than zero in cluster mode. #410
Conversation
allenss-amazon
changed the title
|
Fixes issue #204 |
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
src/schema_manager.h
Outdated
| The SchemaManager uses the MetadataManager to manage a single name space of | ||
| indexes, i.e., map<string, GlobalMetadataEntry>. |
There was a problem hiding this comment.
Appreciate the thought going into this. The interoperability is a headache
One question: when someone creates an index in db_num > 0 on Valkey 9, how would a shard running on Valkey 8 behave? I am guessing it would crash, right? I guess that behavior is fine, but we should document this
Another option I guess is that we have namespaces in the metadata manager. Right now we use "vs_index_schema". We could move to "vs_index_schema2"? Nodes on the old versions would just not get the index definitions for those created with vs_index_schema2, which should be fine, and we can register for callbacks of "vs_index_schema" in the new node for backwards compat. Probably a bit more work, but it would prevent the Valkey 8.0 nodes from crashing in such cases
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
|
Revised to reject RDB or cross-shard metadata that contains any object with a semantic version higher than what's understood by the current code. |
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
Signed-off-by: Allen Samuels <[email protected]>
2 participants
fixes #204