Open gopa-noaa opened 1 month ago
How to set up the XDCR rule: {_default.METAR:development.METAR}
To avoid this you would need to tell cbbackupmgr to ignore the scope IDs and restore the scope in your backup to the scope in your cluster using the --map-data flag e.g. --map-data bucket.testScope=bucket.testScope.
Steps:
Create the backup repo: cbbackupmgr config -a /couchbase/backup/standalone -r vxdatatest --include-data vxdatatest
/opt/couchbase/bin/cbbackupmgr backup --archive /couchbase/backup/standalone -repo vxdatatest --cluster couchbase://adb-cb1.gsd.esrl.noaa.gov --username Administrator --password ####
/opt/couchbase/bin/cbbackupmgr restore --archive /couchbase/backup/standalone -repo vxdatatest --cluster couchbase://adb-cb1.gsd.esrl.noaa.gov --username Administrator --password #### --map-data vxdatatest=vxdatatest
So the current plan is to
Is the discussion here about recreating the bucket with magma storage for issue #409?
The issue description makes it sound like this issue is a continuation of #379.
We may want to revisit the current Couchbase Bucket=>Scope=>Collection hierarchy:
Current hierarchy: vxdata=>development=>[METAR, COMMON, ...] =>integration=>[METAR, COMMON, ...] =>production=>[METAR, COMMON, ...] But given the following documentation on XDCR: https://docs.couchbase.com/server/current/manage/manage-xdcr/replicate-using-scopes-and-collections.html#replicate-data-between-collections-explicitly-with-the-ui This below is important: *** XDCR only permits one replication to be defined, for a given target-bucket.
So either we come up with another mechanism to transition data between development, integration, production other than XDCR OR We move development, integration, production one level up to bucket level.