Couchbase upgrade path from 6.0.0 to 6.6.0

A couple of months ago I tried upgrading our cluster from community 6.0.0 to 6.6.0 and I failed miserably. Only then I checked the docs to realize there was no direct upgrade path from 6.0.0 to 6.6.0 which means you had to upgrade first to 6.5.0.
Checking the docs now and it does show a direct upgrade path from 6.0.0 to 6.6.0. Is this something you fixed or just a mistake in the docs? Also is there an estimate on when community 6.6.1 will be out and if there will be a direct upgrade path to it from 6.0.0?


@Nemmy_Amzel Yes direct upgrade path is always supported from 6.0.0 to 6.6.0. I am sorry you ran into problems with upgrade. If you can share the details, we can help.

I will check on community 6.6.1 version (generally it is 6 months after the patch release it will be available I will confirm), yes if 6.6.1 is available a direct path will be available. Currently EE users can directly upgrade from 6.0.0 to 6.6.1 and same will be true once CE edition of 6.6.1 will be available

Thanks @raju
OK. I’m happy to hear direct upgrade from 6.0.0 to 6.6.0 is now supported for CE. I just needed to confirm it’s not a typo in the docs.
It hasn’t always been that way. In fact even the docs showed there wasn’t a direct path and you had to go through 6.5.0.
I even have a screenshot of the old docs to prove it…

Thanks @Nemmy_Amzel I can confirm that direct upgrade 6.0.0 to 6.6.0 is supported for CE

Thanks god I didn’t take your word for it and went ahead to verify this first. Unfortunately I can confirm there’s NO direct upgrade from 6.0.0. to 6.6.0.
This misleading information on site can cause some serious damage and I suggest you remove it.
It’s really sad Couchbase is not complaint to the universal understanding of versioning semantics and there’s no compatibility between minor version upgrades and there are breaking changes (not only breaking changes but upgraded nodes are not functional and can not even be downgraded again…)

To check this upgrade path all you need to to is simply create a 2 node cluster with 6.0.0 installed. apply the sample buckets and then try upgrading one of the nodes with the newest 6.6.0 version and you will see the node cannot create vBuckets and is stuck there forever.


@Nemmy_Amzel Happy new year 2021. @ritam_sharma is going to follow up with you on this. He cannot reproduce this issue you are mentioning and it works fine in his tests

1 Like

@Nemmy_Amzel - I am unable to reproduce the issue you have mentioned. I have been successfully able to upgrade from 6.0 to 6.6.

1 Like

I tried it twice on GCP VMs. Installed 2 nodes with 6.0.0 containers and joined them to the same cluster. then applied the sample data buckets. then tried to upgrade one node to 6.6.0 and it will show up again but won’t be able to load the buckets.
If you follow the same exact steps I described here I’m sure you will see the same result I am seeing.
Following the same steps from 6.0.0 to 6.5.0 does work.
Also just making sure you tested the community edition of course…

@Nemmy_Amzel - My tests were on linux and windows. Let me get back to you for GCP.

@ritam_sharma don’t think the cloud provider should make any difference but please use the image containers from docker hub.

@Nemmy_Amzel - We could not reproduce the issue using docker images on gcp. Would you be able to do a cbcollect and share logs.

Machine Type : n2-standard-2 (2 vCPUs, 8 GB memory)
Firewall : Allows HTTP and HTTPS Traffic
Images Used : couchbase/server:community-6.6.0 and couchbase/server:community-6.0.0
Preemptibility : Off
VM Image : debian-10-buster-v20201216
Type : Standard persistent disk
Network tags : http-server, https-server


I don’t know if this is right place to paste this error, I am kind of struggling upgrading Couchbase 6.0.0 CE to 6.6.0 CE.

It is failing every time with below error:

c:/Program Files/Couchbase/Server/var/lib/couchbase/data is not the right path for the dbdir that is I am sure. But the installer is still looking in C: drive (the default data directory)

WixQuietExec64:  D:\Couchbase>if exist "D:\Couchbase\bin\install\..\..\var\lib\couchbase\config" (
WixQuietExec64:  echo "Running cbupgrade --namespace_upgrade_only"  
WixQuietExec64:   "D:\Couchbase\bin\install\..\..\bin\cbupgrade.exe" -c "D:\Couchbase\bin\install\..\..\var\lib\couchbase\config" -a yes --namespace_upgrade_only   || goto :error 
WixQuietExec64:  ) 
WixQuietExec64:  "Running cbupgrade --namespace_upgrade_only"
WixQuietExec64:  Automatic mode: running without interactive questions or confirmations.
WixQuietExec64:  Analysing...
WixQuietExec64:  Previous config.dat file is D:\Couchbase\bin\install\..\..\var\lib\couchbase\config\config.dat
WixQuietExec64:  ERROR: dbdir is not a directory: c:/Program Files/Couchbase/Server/var/lib/couchbase/data
WixQuietExec64:  D:\Couchbase>echo Failed with error 1. 
WixQuietExec64:  Failed with error 1.`Preformatted text`
WixQuietExec64:  D:\Couchbase>exit /b 1 
WixQuietExec64:  Error 0x80070001: Command line returned an error.
WixQuietExec64:  Error 0x80070001: QuietExec64 Failed
WixQuietExec64:  Error 0x80070001: Failed in ExecCommon method
CustomAction StartService returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)