UpgradeEdit on GitHub
Sync Gateway Admin REST API: Go Python
Couchbase Lite REST API: Java C# Swift Python
This section is an overview of the different options to upgrade a running cluster to the latest version of Sync Gateway and Couchbase Server. For a complete list of instructions, we recommend to follow the upgrade section in the travel sample tutorial. You will learn how to perform a rolling upgrade and enable the shared bucket access introduced in Sync Gateway 1.5 in order to use N1QL, Mobile and Server SDKs on the same bucket.
In each of the scenarios described below, the upgrade process will trigger views in Couchbase Server to be re-indexed. During the re-indexing, operations that are dependent on those views will not be available. The main operations relying on views to be indexed are:
- A user requests data that doesn't reside in the channel cache.
- A new channel or role is granted to a user in the Sync Function.
The unavailability of those operations may result in some requests not being process. The duration of the downtime will depend on the data set and frequency of replications with mobile clients.
|1.4||1.5 xattrs disabled||
|1.5 xattrs disabled||1.5 xattrs enabled||
|1.4||1.5 xattrs enabled||
That being said, it is possible to avoid this downtime by running the 2 upgrade paths mentioned above (first, an upgrade from 1.4 to 1.5, and second, an upgrade from 1.5 to 1.5 with xattrs enabled).
Note: Enabling convergence on your existing deployment (i.e XATTRs) is not reversible. It is recommended to test the upgrade on a staging environment before upgrading the production environment.
All of the different upgrade paths mentioned above assume that Couchbase Server is running a compatible version for Sync Gateway. There are 3 commonly used upgrade paths for Couchbase Server. Depending on the one you choose, there may be additional consideration to keep in mind when using Sync Gateway:
|Upgrade Strategy||Downtime||Additional Machine Requirements||Impact when using Sync Gateway|
|Rolling Online Upgrade||None||Low||
|Upgrade Using Inter-cluster Replication||Small amount during switchover||High - duplicate entire cluster||Using an XDCR (Cross Data Center Replication) approach will have incur some Sync Gateway downtime, but less downtime than other approaches where Sync Gateway is shutdown during the entire Couchbase Server upgrade.
It's important to note that the XDCR replication must be a one way replication from the existing (source) Couchbase Server cluster to the new (target) Couchbase Server cluster, and that no other writes can happen on the new (target) Couchbase Server cluster other than the writes from the XDCR replication, and no Sync Gateway instances should be configured to use the new (target) Couchbase Server cluster until the last step in the process.
|Offline Upgrade||During entire upgrade||None||