I would be interested to know the cases where you encountered data loss while doing swap rebalance in case of 2.2. Knowing the SDK version would be useful too.
If you’re planning to go for offline upgrade from v2.2 to v3.0.1, then I would recommend:
- 1st option(using
cbbackup and node upgrade):
- Stop traffic to couchbase cluster, make sure disk queue items have dropped down to 0. Disable auto-failover.
cbbackup snapshot of your data to have a backup in case something bad happens.
- Upgrade the cluster nodes one by one, using either(if you’re running on linux):
rpm -U couchbase-server-architecture_meta_current_version.rpm
dpkg -i couchbase-server-architecture___meta_current_release.deb
Post this cluster nodes will warm-up and you could monitor the status using
cbstats utility. Once all nodes are online, start ramping up production traffic to v3.0.1 cluster.
Stop traffic to couchbase cluster, make sure disk queue items have dropped down to 0.
Create another cluster with similar specs as current one running on v3.0.1
cbtransfer utility to transfer data from original cluster to new cluster. Might take some time depending on your dataset.
Once transfer is done, change your couchbase connection string to point to the new cluster running on v3.0.1.
I’ll not suggest XDCR on v2.2 to transfer data to v3.0.1 cluster because of some known issues and it needs close assistance from Couchbase Support.