Maybe a stupid question, but does Couchbase handle SIGTERM or SIGKILL in Docker container?
I have a Docker Couchbase container running in production environment, currently it has range 8 milion documents. And sometime I run docker container restart <couchbase_name> because of some reasons.
So if I run docker container restart <couchbase_name while Couchbase is handling a write data to disk instruction, etc, does Couchbase lost data?
" The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored."
Other than that, each service is an independent process that handles signals differently. You’re obviously concerned about services that persist data.
If the 10 seconds after the SIGTERM is sent by Docker elapses and the processes are killed with SIGKILL, recovery would obviously be necessary for an interrupted write. Couchbase services are generally tolerant of abrupt termination as the product is designed to handle issues with individual nodes.
That said, I’m not an expert in the services with persistent data, so I’ll defer the actual answer to the main point of your question to others.
We made some improvements to our containers earlier this year, to gracefully handle a SIGTERM, meaning that Couchbase Server should shut down cleanly.
On DockerHub, this change is in container images for 7.2.5+ and 7.6.0+, and on the Red Hat Container Catalog, all containers built since March 15 this year, including security rebuilds, will have have this behaviour.
Thank you for suppling useful information.
But my Couchbase is running on production, so I concern about update Couchbase from 7.1.6 to 7.2.5+.
If I decide update Couchbase server from 7.1.6 to 7.2.5, can I only down Couchbase container, edit image tag, and up it again?
By the way, Is Couchbase 7.1.6 safe to run docker stop or docker restart.
We actually made some changes in Server 7.2.0 to make these kinds of Docker upgrades safe/stable, as we recognised that being able to “upgrade in place” was very useful (and analogous to our documented “offline upgrade” approach).
The changes were related to some default config files present under /opt/couchbase/etc/, and our stance from 7.2.0 onward is that as long as you preserve the contents of /opt/couchbase/var/ (e.g. with a mounted volume in Docker), then it is safe to stop the container, then restart it with a newer image.
While you are running pre-7.2, I would suggest that you swap rebalance out the 7.1.6 node for a new 7.2.x. container instead, if at all possible. I can’t offer any guarantees, but I suspect if you simply restart the 7.1.6 container with a 7.2.x image it would most likely be OK, but without knowing your environment it’s hard to say for sure.
