On 6. Jul 2020, at 10:26, Alan Malta <[email protected]> wrote: > > Dear experts, > > apologies if I'm asking something that has already been asked here, if > so, I'm happy to have just a link to a previous discussion. > > Coming to the problem, over the last week, one of my couch instances > went twice from ?~20GB to ~300GB. The problem is that the compaction > never manages to switch the databases because there are always a few > thousand changes to catch up on (~30k), e.g.: > """ > Compaction file still behind main file (update seq=199559009. compact > update seq=199532061). Retrying. > """ > > By the time it catches up, there is again another 20k or 30k changes to > process. > > I have this setup for many years now (CentOS7, CouchDB 1.6.1, probably > a normal load), so I wonder if this is actually a symptom that > something else is not fine in the system? Besides stopping database > writes, is there anything else that I could do to avoid it?
Stopping database writes is the way to do this in 1.x (which we’ve long stopped supporting). If you have the option to increase IOPS on your system, that might also help. I’d say this is normal and you have reached database sizes where the existing underlying hardware doesn’t suffice to support normal operation. It doesn’t look like something else is not fine. > > Thank you in advance. > Alan. > > PS.: Out of curiosity, is it handled in a different/better way in the > latest CouchDB versions (like 3.1)? From 2.x onwards, databases can be sharded, that is split up into multiple database files (which individually are the same as a single database from 1.x). So for example with four shards, each shard will only receive 1/4th the write load, making it easier to catch up with. Best Jan — Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
