We are using Community Edition 5.0.1 build 5003 in a single node deployment running on Windows. This node is running on Windows 10 laptop (for development purposes), but we notice that occasionally the Indexer.exe process will appears to hang. The symptoms we’re seeing are constant ~25% CPU even when there’s no external activity in the database and indexes report 100% complete.
The bigger issue is that when Couchbase gets in this state the indexes fail to update i.e. we insert new data into a bucket and they are not visible via N1QL SELECT queries although we can see the data in bucket. We tried compacting the index, no help. We tried running a N1QL query from the console using ‘request_plus’ scan consistency and the query times out.
The only index we have on the bucket is a simple secondary index with a single, non-unique string (user id) field as the index. The bucket itself has < 1000 items in it.
The only ‘fix’ thus far is to restart the Couchbase service which is not desirable.
Any ideas on the source of this type of issue?
Thanks in advance!
how many buckets you are having and are these buckets having views or sync gateway. Does it happen intermittently or always.
There should not anyway be only one node in a cluster because the complete architecture of any nosql db is always based on RAM. What if the laptop restarts and the data havent seen the disk. So one should have minimum 2 nodes for dev and minimum 3 for production. 4 cores are bare minimum requirement and need not be a server level hardware even commodity hardware will work but nodes should be there.
Thank you for the reply. Our use case is very simple. We have two buckets: one memcache which is truly ephemeral session-level data which is OK to lose and the other bucket we store ‘messages’ as a json blobs. The latter bucket we don’t want to lose data. The bucket type is Couchbase which is persisted as I understand the system.
We are not using views or sync gateway and the issue is intermittent, but I’m wondering if related to the developer shutting down his PC. I see lots of errors in the log file including this:
2018-05-27T17:26:26.083+07:00 [Error] KVSender::sendRestartVbuckets Unexpected Error During ShutdownVbuckets Request for Projector 127.0.0.1:9999 Topic MAINT_STREAM_TOPIC_00408a6d5537c878b92a567f7faf1307. Err projector.topicMissing.
Regarding your comment about “data havent seen the disk” are you saying that Couchbase doesn’t not sync the data to disk immediately with the Couchbase bucket type? I’m not concerned about OS-level data write buffering, but I was under the impression that Couchbase transactionally journals data to disk for this bucket type.
Couch-base does write the data to disk, But it first goes in RAM and then in a several queues for internal replication, XDCR and for persisted storage and then to disk.
Its not like RDBMS where the data is written to disk first and then acknowledgement is sent to the caller. In NoSQL the ack will be done as soon as the data is in RAM and in queues.
@jdelmerico, If you are still facing the problem, Could you please share the indexer and projector logs when the issue occurs to help analyse?