This is what I got back for my case from couchbase support. I also asked them to try to keep the upgrade process for docker users more simple than currently advised.
The issue here comes from the fact that from a Couchbase Server installation perspective, an upgrade wasn’t performed. Instead, a new instance running the upgraded version started up, and ran with the config files of the previous version. This will cause an issue when a change between versions requires the upgrade processing to run - in this case, this is due to a change in the data file format. As Couchbase Server 6.6 expects the files to have been migrated to the new format before it starts, it is unable to read the files in the older version.
We are looking into any changes we can make to our documentation in order to make the upgrade steps clearer when using Docker. In the meantime however, for any future upgrades you should approach these by adding a new node to the cluster on the upgraded version and then removing the older node.
In order to recover the one node cluster you currently have, you should be able to execute the following command within the container :
# /opt/couchbase/bin/cbupgrade -a yes --namespace_upgrade_only -c /opt/couchbase/var/lib/couchbase/config/ && pkill memcached
This will manually trigger the data file upgrade and then kill the Data Service, forcing it to restart and pick up the change. It should be noted that this is provided as a workaround only, and should not be used as a routine step for any future upgrades. Before running this command, you should back up the container’s mapped config directory .