Details
-
Improvement
-
Resolution: Fixed
-
Critical
-
5.0.0
-
Security Level: Public
-
Cluster Setup:
2 nodes
Node 1: kv index n1ql
Node 2: index
Description
We need a metadata store that is immediately consistent.
The metadata store should begin with nodes, buckets and collections and should eventually include things such as GSI indexes. An example use case for indexing that fails today that this would fix would be as follows:
[GSI] Indexes can be created with duplicate index_names when one of the indexer node is in failed over state
Steps:
1. Configure cluster. Create bucket default and load the bucket with 10k items.
Sample document:
{
|
"name": "pymc0",
|
"age": 0,
|
"index": 0,
|
"body": "VTKGNKUHMP"
|
}
|
2. Create index ind_3 on default(name). It gets created on node 2.
3. Failover Node 2.
4. Create index ind_3 on default(age). It gets created on node 1.
5. Rebalance in Node 2 with full recovery.
Now there are 2 indexes with same name "ind_3" with different index definitions.
when dropping ind_3, later one gets dropped. There is no way of controlling drop behaviour in such cases.
Expectation is, indexes with duplicate index_names shouldn't be allowed to be created.
Snapshot attached.
Log Location:
https://s3.amazonaws.com/bugdb/jira/duplicate_indexes/collectinfo-2016-12-19T082442-ns_1%4010.111.170.101.zip
|
https://s3.amazonaws.com/bugdb/jira/duplicate_indexes/collectinfo-2016-12-19T082442-ns_1%4010.111.170.102.zip
|
Attachments
Issue Links
- blocks
-
MB-24011 Duplicate Indexes with the same name in a cluster
- Closed
-
MB-27384 Rebalance request may ignore recovery nodes if config has not synchronized
- Open
- is cloned by
-
MB-46007 Metadata store that is immediately consistent in which to store Index Definitions
- Open
- relates to
-
MB-31074 After cluster upgrade, clusterCompatibility still at old value
- Closed
- mentioned in
-
Page Loading...