_global_changes is growing fast and others questions #3822
-
|
Hi, we are using a 3 node cluster with q=8 and n=3 with an infrastructure for a telephony ip centrex called kazoo. We see that the _global_changes is the one responsible of the size. Can we delete it? Other question, we clone the VMs in a test env and we did delete the db directories of the 2 nodes of 200gb so they start resync and now they are 20gb each. Is this the correct procedure? We lost anything? thanks for help |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
Yes, if you don't use the _db_updates endpoint you can delete this database.
The individual shard replicas are only eventually consistent with one another; in an environment where you are regularly writing to a given database deleting 2 out of 3 copies does run the risk of losing updates that were reported as committed. It's a low risk, though, as CouchDB does eagerly try to write to all 3 copies on every update request. The internal sync process that restored your data is similar to DB compaction in that it skips the document bodies for all older revisions, so it's entirely possible that you could delete 200GB worth of files on disk and end up with 20GB of disk space consumed when the restoration is complete. |
Beta Was this translation helpful? Give feedback.
Yes, if you don't use the _db_updates endpoint you can delete this database.
The individual shard replicas are only eventually consistent with one another; in an environment where you are regularly writing to a given database deleting 2 out of 3 copies does run the risk of losing updates that were reported as committed. It's a low risk, though, as CouchDB does eagerly try to write to all 3 copies o…