I have a 5-node couchbase v2.2.0 community edition (CE) server deployed on Windows 2008) used by both a C# and a Java application.
The C# application uses .net SDK 1.3.12. The Java application uses java SDK v1.4.3.
My development environment differs from the production environment only by the number of nodes in the cluster - reducing the number of nodes from 5 down to 1.
I upgraded the Couchbase cluster to version 5.1 (CentOS 7) (community edition) by using XDCR.
I then shutdown the apps, updated the DNS to point to the new Couchbase Server, and restarted the apps.
But the two apps were unable to connect to the new server, and I suspect that it has to do with the new role-based access control (RBAC)
What is the least invasive way to get my apps talking to Couchbase CE on Linux? (I would consider using Couchbase CE version 4.5 instead of 5.1.)
Do I just need to change the connect strings in the code?
Do I just need to upgrade the SDKs? If so, can the 2.x library function as a drop-in replacement for the 1.3.12 library, or would I have to change the code in some way to use the 2.x libraries?
I also speculate that another way to do this might be to XDCR from v2.2.0 to v4.5.1, and then upgrade to v5.1 by adding v5.1 node(s) to the cluster, and then removing the v4.5.1 node(s) from the cluster, as this might setup RBAC correctly for v5.1 nodes.
I would definitely recommend taking both those steps (updating connection config information and upgrading the SDK), in order to take full advantage of the new features that 5.x has to offer.
If RBAC is an issue, a quick & dirty fix is to create a user in Couchbase 5 with the same name as the bucket. Then your SDK should continue to work as before.
You suggest that the quick and dirty fix (if RBAC is an issue) is to create a user in CB v5.1 with the same name as the bucket. I tried to do so, but was unable to because the UI requires that all users have passwords, and the bucket doesn’t have a password!
Obviously the new features of CB v5.1 are cool, and obviously I’d have to have a newer version of the SDK to use such coolness BUT! I haven’t any way to use those cool things right now in my app, so as a separation of concerns, I’d like to first upgrade the server, and once that is stable and running, I’d upgrade the SDK.
So in summary my new questions are:
is it possible to upgrade from server v2.2.o to server v5.1 without upgrading the SDK?
You suggest that I need to change the connect string. What is the difference between the connect strings for SDK 1.3.12 + Server v.2.2.0 and the connect strings for SDK 1.3.12 + Server v5.1?
how do I create users in 5.1 to match buckets on server v2.2.0 if the buckets have no passwords?
Maybe. I suspect @jmorris can give you a definitive answer.
Actually, you might not need to change the connection string. I guess I would need to see the connection string you are currently using. If it’s as simple as “http://someurl:8091”, then you are probably fine.
When you create a user, you give that user a password. So let’s say in CB 4, you have a bucket called “matt” with a password of “12345”. In 5.x+, you can still have a bucket called matt. But now also create a user called “matt” and give matt a password of “12345”. This will give you a quick way to switch to RBAC without changing your client code.
Correct me if I am wrong, but it seems to me that if I popped into the server v2.2.0 and added a password to a bucket, say SCMS, the application would suddenly not be able to access the SCMS bucket, until I updated it to know about the new password.
By extension, if I add user “SCMS” with a password in server v5.1, the code still would not be able to access the SCMS bucket, unless I updated it to know about the new password, right? So wouldn’t I still have to update all places that access the bucket to know about the new password?
Is there anyway (perhaps by writing a small little app using .NET SDK v1.3.12, or Java SDK v1.4.3) to create a new user in the v5.1 server with username “SCMS” and no password?
Hey Matthew, it looks like my connect string is http://couchbase1:8091 so I’m not sure why it couldn’t connect to the v5.1 server, since couchbase1 now points to the couchbase v5.1 server…
1- No, the SDK must be upgraded to support RBAC (among other changes).
2- No, its not necessarily a connections string issue - the configuration itself is completely different between 1.x and 2.x. Connection strings for the .NET SDK didn’t happen until 2.5.X (iirc).
3-For what @matthew.groves is suggesting, you would have to be using .NET SDK 2.5.x, which specifically supports RBAC.
In summary, you will need to upgrade your code as well from .NET SDK 1.3.X to 2.5.X; I suggest using 2.5.12 which is the last release for 2.5.X or go directly to 2.6.0. Note that the API’s are different and you’ll have to change your code to support the different API’s.
The change from Java 1.4.3 to 2.X will require similar code changes because the API’s also changed between majors.
Thanks to all those who provided input on this post.
I discovered that the minimal code changes required to upgrade from v1.4 to v2.6 were along these lines:
// to get a value
Object value = getValue(key) --> Object value = bucket.get(key, LegacyDocument.class).content(); // obviously this might get a NPE...
// to save a value
setValue(key, value, expiration) --> bucket.upsert(LegacyDocument.create(key, value, expiration);
// to connect: v1.4
List<URI) uris; // load this list with the urls of the servers in the cluster, e.g., http://server:8091/
client = CouchbaseClient(uris, bucketName, "");
// to connect v2.6
List<String> serverAddresses; // load this with the servers from the cluster, e.g., "server1.your.domain.com", "server2.yourdomain.com" etc.
Cluster cluster = CouchbaseCluster.create(serverAddresses);
Bucket bucket = cluster.openBucket(bucketName, "");
What I ended up learning was that Java Client v1.4.3 and .NET client v1.3.12 CAN connect to server v4.5.1 w/o change.
So the least invasive change was to upgrade the server to v4.5.1 and leave the code alone, which is the route I took.
BUT! I haven’t any way to use those cool things right now in my app, so as a separation of concerns, I’d like to first upgrade the server, and once that is stable and running, I’d upgrade the SDK.