Critical Description
There are two different but related scenarios here:
The initial set up configuration is the same for both:
1) Spin up a new CB 5.0.1 node (with the 3 services, Index,Data, and Query running). Create a new bucket, name it "oldBucket".
2) [Optional] Fill up the bucket with random JSON data
opt/couchbase/bin/cbworkloadgen -i 1000 -j -u Administrator -p password -b oldBucket
|
3) Create an index on any field on the bucket "oldBucket".
4) Create a backup directory "mkdir backup".
5) Configure the backup repository with cbbackupmgr
/opt/couchbase/bin/cbbackupmgr config --archive /home/vagrant/backup --repo example
|
6) Run the backup command
/opt/couchbase/bin/cbbackupmgr backup --archive /home/vagrant/backup --repo example --host couchbase://127.0.0.1 -u Administrator -p password
|
7) Create a new bucket, call it "newBucket".
The rest of the steps are different for each scenario:
The original bucket is deleted from the cluster at the time of using restore with the --map-buckets option
8) Delete the bucket "oldBucket", keeping only the bucket "newBucket" on the cluster.
9) Restore using the --map-buckets option, mapping "oldBucket" to the "newBucket"
/opt/couchbase/bin/cbbackupmgr restore --archive /home/vagrant/backup --repo example --include-buckets "oldBucket" -c couchbase://127.0.0.1 -u Administrator -p password --map-buckets "oldBucket=newBucket"
|
As the tool seems to be trying to restore the indexes on bucket "oldBucket", we get an error:
Error restoring cluster: Internal server error while executing "POST http://127.0.0.1:9102/restoreIndexMetadata?bucket=newBucket" check the server logs for more details
|
The original bucket exists on the cluster at the time of using restore with the --map-buckets option
Similar to what is mentioned above, the tool seems to be trying to restore the indexes on the bucket "oldBucket". Since "oldBucket" exists, the tool will actually attempt to restore the indexes to the oldBucket on the cluster. I'm mapping to a new bucket, so indexes should not be restored for the "oldBucket"
The same restore command (step 9 above) is ran, although with this scenario we skip step 8 above.
—
Expected: Depending on the solution implemented, but I would expect to see no error messages, instead, a message to indicate that indexes won't be restored (if we decided to do that way), or, which seems a more proper solution, is for the restore to behave the same for data and indexes. So since we won't attempt to restore the data for oldBucket, we shouldn't be attempting to restore the data for its indexes, since its mapped for a different bucket. Instead, the indexes would be created on the newBucket.
