Uploaded image for project: 'Couchbase Server'
  1. Couchbase Server
  2. MB-43580

Multiple partition indexes are getting created after restoring scheduled partitioned indexes

    XMLWordPrintable

Details

    • Untriaged
    • Centos 64-bit
    • 1
    • Unknown

    Description

      Steps to reproduce

      1. Create a cluster of 2 nodes
      2. start creating 10 partitioned indexes concurrently for scheduled indexes
      3. backup using rest endpoints  or cbbackupmgr while indexes are being created some scheduled indexes should be present in the backup
      4. query stats from /getIndexStatus
      5. delete all the backed up indexes
      6. restore the backup using rest endpoints or cbbackupmgr
      7. query stats from /getIndexStatus
      8. check UI for multiple index creation and stats for duplicate index entries

      Only scheduled indexes have multiple instances after restore

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          Amit Kulkarni, I've attached the logs for your reference. Let me know if you need anything more.

           

          node1-cb600-centos7.vagrants.zip

          node2-cb600-centos7.vagrants.zip

          test.log

          hemant.rajput Hemant Rajput added a comment - Amit Kulkarni , I've attached the logs for your reference. Let me know if you need anything more.   node1-cb600-centos7.vagrants.zip node2-cb600-centos7.vagrants.zip test.log
          amit.kulkarni Amit Kulkarni added a comment - - edited

          Looking at the output in the test.log,

          There aren't any duplicate indexes. We are setting 2 entries because the partitions are distributed across two different nodes in the cluster.

          At the time of backup, there were scheduled create tokens for the partitioned indexes. During restore, these indexes will be restored in created state.

          This is expected behaviour.

          One observation I can see is the instance Ids are different for the same index on two different nodes. Need to verify if this is expected.

          amit.kulkarni Amit Kulkarni added a comment - - edited Looking at the output in the test.log, There aren't any duplicate indexes. We are setting 2 entries because the partitions are distributed across two different nodes in the cluster. At the time of backup, there were scheduled create tokens for the partitioned indexes. During restore, these indexes will be restored in created state. This is expected behaviour. One observation I can see is the instance Ids are different for the same index on two different nodes. Need to verify if this is expected.

          Build couchbase-server-7.0.0-4683 contains indexing commit 2aa8707 with commit message:
          MB-43580: Avoid running planner if there are no indexes to restore

          build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.0-4683 contains indexing commit 2aa8707 with commit message: MB-43580 : Avoid running planner if there are no indexes to restore

          Build couchbase-server-7.0.0-4683 contains indexing commit d9638e6 with commit message:
          MB-43580: Fix instId during restore of sched tokens for partitioned index

          build-team Couchbase Build Team added a comment - Build couchbase-server-7.0.0-4683 contains indexing commit d9638e6 with commit message: MB-43580 : Fix instId during restore of sched tokens for partitioned index

          Validated with 7.0.0-4732

          hemant.rajput Hemant Rajput added a comment - Validated with 7.0.0-4732

          People

            amit.kulkarni Amit Kulkarni
            bhargava.yadavalli Bhargava Yadavalli (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes

                PagerDuty