Failed to stop Couchbase Server in docker container

Couchbase Server Kubernetes
1

I’ve a Couchbase Server community 6.5.0 running in a container on top of a Kubernetes cluster.
In a bash shell launched by “kubectl exec $COUCHBASE_SERVER_POD -it – bash” , I tried to shut down the Couchbase Server by means of

root@cb-srv-0:/# systemctl stop couchbase-server

But it failed with

Failed to connect to bus: No such file or directory

I know there’s something to do with the privilege of the container’s shell.

Does anyone have any idea how to resolve the issue?

Thanks in advance.

2

Containers don’t run with systemd so that’s your main problem.

Why are you attempting to stop the Couchbase process?

3

I actually want to know whether the Couchbase Server will be shut down gracefully, if the k8s pod it is running on is deleted (due to any reason.)

4

If the server could not be shut down gracefully, I was thinking about shutting It down explicitly in a preStop hook using

“systemctl stop couchbase-server”

5

Well, the Server process is run with runsvdir which will terminate immediately when Kubernetes sends a TERM signal to it, at which point Kubernetes is free to do any cleanup. So, no I don’t believe it terminates gracefully. However, if you care about data consistency you should be using features such as document durability to ensure it is replicated or flushed to disk, on error the client can just retry. This is fully tested.

I’ll notify someone who has a better understand of these things and they can fill in any blanks or mistakes I’ve made.

6

First, thanks for your quick response.

So the idea is flush the bucket(s) during the “grace” terminating period…

Thanks for your help again.
Really appreciate it.

7

hi @matsunanaro

Popping up a higher level, in Couchbase the most graceful transition is a rebalance. That, for example would always preserve the number of replicas for data safety. It takes a little while, but it’s the intended way to remove a node from a cluster.

It sounds like you’re running in K8S without using the Couchbase Autonomous Operator.

If that is the case, with autofailover and using higher levels of durability on operations that need it (this is where Couchbase doesn’t force you to take on the additional cost for all operations) you would indeed be safe from losing data. It will be a bit app disruptive though. Any operations in flight on a connection may be dropped and the clients will have to adjust topology to get to the new location.

In Couchbase, a “flush” usually means “drop all data”, so probably not. :slight_smile: Check out that durability link to the docs and it may help you understand what the options are relative to what you probably think of as a disk flush or fsync().