Our Data API checks scopes, collections, and indexes for each JVM type and creates them if necessary. Then awaits for all indexes to be online before proceeding. It seems that concurrent index creations may initialize indexes with the same name in Couchbase 7.0 Beta.
For Exception there were actually 3 indexes with the same name and one of them was alternating between ready and error state.
Not all of our indexes end it this way but seems like that the retry mechanism behind index creation or concurrency would do such a thing.
Hi @zoltan.zvara, thanks for posting this.
I think the possible bug due to duplicate index name is fixed with Loading....
I request you to attach following information so that I can analyse this further.
-
Output of following n1ql query:
select * from system:indexes;
-
Output of following curl command:
curl -X GET -u <couchbase-admin-username>:<couochbase-admin-password> http://<any-indexer-node-ip>:9102/getIndexStatus
-
indexer.log files from all indexer nodes in the cluster.
Having said this, starting with 7.0, I suggest you to check for the message (substring) The index is scheduled for background creation in the response. If this message is seen, there is no need to retry the index creation immediately. You can track the progress of creation of that index using n1ql by checking the state of the index in the output of select * from system:indexes;
Thank you!
@amit.kulkarni, thanks, we are checking background creation, but I think the index was not “registered” for a long time, thus, our mechanism retried to create it many times, because it did not show up in records.
Due to these ocurring, we moved the “database setup” tests (tests that create a lot of collections/indexes in a short period of time) into a single-node server that is always empty initially, just for this purpose. We have not seen these errors ever since.
Then should we wait for the new Beta release to come out?
