Updated DEB / RPM packages and container images for 3.2.1

Hi all, we’ve published updated convenience binaries and images for CouchDB 3.2.1 to Artifactory (DEB/RPM) and Docker Hub. Notable changes include - Upgrading Erlang 20 to Erlang 23 - Upgrading Debian 10 to Debian 11 as the base for the Docker image - Adding ppc64le support (alongside amd64 and

Re: Setting up smoosh for database compaction

Hi Paul, sorry to hear you’re finding it a challenge to configure. The default configuration described in the documentation does give you an example of how things are set up: https://docs.couchdb.org/en/3.1.1/maintenance/compaction.html#channel-configuration Cross-referenced from that section

Re: CouchDB and RabbitMQ clusters

That’s typically how it works for a well-behaved Erlang application, yes. CouchDB does work this way; I’m not 100% certain about RabbitMQ but it probably does as well. Cheers, Adam > On Jul 15, 2021, at 5:11 AM, Andrea Brancatelli > wrote: > > Hello everybody, > > I have a general Erlang

Re: couchdb 3.X partitioning

The tricky part is that partitioned databases have a hard requirement on document IDs to have a “:” in them to demarcate between the partition and rest of the document ID. Replication can’t change document ID, but if the source database happens to fulfill that requirement for all of its

Re: How to work with Indexes

Hi Piotr, To first order, yes, I’d try to have every query an application issues be satisfied by an index. If you’ve got some queries that you run infrequently in the background those may not warrant an index, as the resources required to keep the index up-to-date would be greater than the

Re: running couchdb on a .app domain (https enforced)

This means something else is already listening on one of the ports that CouchDB is trying to use. Adam > On Aug 12, 2019, at 3:24 AM, Rene Veerman wrote: > > eaddrinuse

Re: High memory consumption of a single node CouchDB server

;>>>>>>>> ... and we are experiencing the problem on both setups. We've >>>> been >>>>>>> having >>>>>>>>> this problem for at least 3-4 months. >>>>>>>>> >>>>>>>>>

Re: High memory consumption of a single node CouchDB server

13118, > ... > > Adrien > > Le ven. 14 juin 2019 à 15:11, Jérôme Augé a > écrit : > >> Ok, so I'll setup a cron job to journalize (every minute?) the output from >> "/_node/_local/_system" and wait for the next OOM kill. >> >>

Re: High memory consumption of a single node CouchDB server

Hi Jérôme, Thanks for a well-written and detailed report (though the mailing list strips attachments). The _system endpoint provides a lot of useful data for debugging these kinds of situations; do you have a snapshot of the output when the system was consuming a lot of memory?

Re: Help in understanding an error message

Hi Andrea, That message is a timeout from one of the workers tasked with reading a database shard and responding with that shard’s portion of the response to an _all_docs request. CouchDB spins up redundant workers for each copy of a shard when you make a request to _all_docs, so it’s

Re: How to notify when an update happened in the document

Hi, The /db/_changes endpoint will inform you of updates to documents in CouchDB. If you want the content of the current “winning” revision of the document to be included with the notification, add include_docs=true to the query string when you make the request. Cheers, Adam > On May 13,

Re: Shards-directory still big after deleting big database in Fauxton

Hi Frank, Thanks for the followup. Definitely appreciate that the clustering feature adds complexity and is not appropriate for everyone. The only problem with running 1.x is that we are not providing any updates at all to that release series - even security patches. Was there something in

Re: Disk full

pacting because I thought it was useless in our case since > the db's and the docs are so small. I do wonder how it is possible for a db > to grow so much when its being deleted several times a week. What is all > the 'air' ? > > On Thu, 2 May 2019 at 18:31, Adam Kocoloski wrote: &g

Re: Disk full

Hi Willem, Compaction would certainly reduce your storage space. You have such a small number of documents in these databases that it would be a fast operation. Did you try it and run into issues? Changing cluster.q shouldn’t affect the overall storage consumption. Adam > On May 2, 2019, at

Re: [DISCUSS] On the _changes feed - how hard should we strive for exactly once semantics?

Bah, our “cue”, not our “queue” ;) Adam > On Mar 7, 2019, at 7:35 AM, Adam Kocoloski wrote: > > Hi Garren, > > In general we wouldn’t know ahead of time whether we can complete in five > seconds. I believe the way it works is that we start a transaction, issue a > bunc

Re: [DISCUSS] On the _changes feed - how hard should we strive for exactly once semantics?

me issue for _all_docs and _view and _find, in that the user >> might ask for more data back than can be sent within a single FDB >> transaction. I suggest that's a new thread, though. >> >> -- >> Robert Samuel Newson >> rnew...@apache.org >> >> On Th

[DISCUSS] On the _changes feed - how hard should we strive for exactly once semantics?

Hi all, as the project devs are working through the design for the _changes feed in FoundationDB we’ve come across a limitation that is worth discussing with the broader user community. FoundationDB currently imposes a 5 second limit on all transactions, and read versions from old transactions

Re: Can a couched 2.3.0 be downgraded to 2.1.1 without changes to the data

Ah, we need to do a better job documenting this for sure. I think you _cannot_ do an in-place downgrade because the on-disk header format changed to v7 to include some metadata needed for the purge feature that was re-introduced in 2.3.0: https://github.com/apache/couchdb/commit/78a388d

Re: How many replications per server?

find anything here: > http://docs.couchdb.org/en/stable/replication/replicator.html > > Neither here: > http://docs.couchdb.org/en/stable/api/server/common.html#replicate > > --- > > Andrea Brancatelli > > On 2018-10-30 17:17, Adam Kocoloski wrote: > >>

Re: How many replications per server?

kill_or_start(something) > > } > > } > > sleep(interval) > > } > > > > Is this correct? > > > > --- > Andrea Brancatelli > > On 2018-10-30 17:17, Adam Kocoloski wrote: > >> Hi Andrea, your numbers don't sound crazy for

Re: How many replications per server?

Hi Andrea, your numbers don’t sound crazy for an out-of-the-box setup. Worth noting that in CouchDB 2.1 and above there is a replication scheduler which can cycle through an ~unlimited number of continuous replications within a defined resource envelope. The scheduler is documented here:

Re: View Issues Upgrading From 2.0.0 to 2.2.0

Hi Maggie, The mailing list strips out attached images, so that part didn’t come through. However, I think the stack trace is sufficient to figure this out. I suspect the `node2@dev02` node is still running 2.0.0, while elsewhere in the cluster an _all_docs HTTP request landed on a node in the

Re: couchdb erlang reduce - aggregate object

Hi David we added that in version 2.0: https://github.com/apache/couchdb/commit/5a2ec4f50 The behavior is documented on master: http://docs.couchdb.org/en/master/ddocs/ddocs.html#reduce-and-rereduce-functions

Re: Sharding: all databases or just one?

> > n=3 Any 2 nodes can be down > > I believe this is only true if you have as many nodes as shards (8 per > default)? > > Ulrich > > Am 12.01.18 um 03:11 schrieb Adam Kocoloski: >> Hi Ulrich, sharding is indeed per-database. This allows for an important >> d

Re: Sharding: all databases or just one?

Hi Ulrich, sharding is indeed per-database. This allows for an important degree of flexibility but it does introduce maintenance overhead when you have a lot of databases. The system databases you mentioned do have their own sharding documents which can be modified if you want to redistribute

Re: include_docs and no doc issue

Hiya Carlos, yes, the race condition definitely still exists. As far as I know the guidance in the wiki is still accurate. The brute force way to eliminate the issue is to emit the doc directly in the view definition and skip include_docs altogether, but of course that has a whole set of

Re: Many logs since Couchdb 2.1.1

Those log messages seem to be truncated before they get to the names of the actual database and associated index. Is it the same one every time in your logs? Adam > On Dec 15, 2017, at 8:11 AM, Frédéric Alix wrote: > > Hi, > > Since I updated from CouchDB 2.0 to 2.1.1,

Re: Difficulty replicating behind a proxy server

potentially implement a fix for > this issue. > Thanks again, > Jake Kroon > > On 2017-12-14 05:57, Adam Kocoloski <k...@apache.org> wrote: >> Hi Jake, ugh, yes, I think you?019ve hit the nail on the head. In your first >> configuration, CouchDB is seeing an HTTP-based ta

Re: Difficulty replicating behind a proxy server

Hi Jake, ugh, yes, I think you’ve hit the nail on the head. In your first configuration, CouchDB is seeing an HTTP-based target and assuming it needs to use the proxy. Your second configuration fails because the replicator does not yet work with local clustered databases. I think the quickest

Re: Automatic Compaction of _global_changes

. So I'll > have each node's config only be aware of the full paths of the local shards. > > Thanks again, hopefully a bug fix will be provided soon. > > /mel > > -Original Message- > From: Adam Kocoloski [mailto:kocol...@apache.org > <mailto:koco

Re: Automatic Compaction of _global_changes

curity vulnerability. We'll upgrade to > CouchDB 2.1.1 soon. Fortunately this is an internal database on a firewalled > corporate network so we have a bit more time. > > -Original Message- > From: Adam Kocoloski [mailto:kocol...@apache.org] > Sent: Friday, December 08,

Re: Automatic Compaction of _global_changes

Hiya Melvin, this looks like a bug. I think what’s happening is the compaction daemon is walking the list of database *shards* on the node and comparing those names directly against the keys in that config block. The shard files have internal names like

Re: 100% CPU on only a single node because of couchjs processes

Hi Geoff, a couple of additional questions: 1) Are you making these view requests with stale=ok or stale=update_after? 2) What are you using for N and Q in the [cluster] configuration settings? 3) Did you take advantage of the (barely-documented) “zones" attribute when defining cluster members?

Re: Armhf Snap for Couchdb

> On Dec 1, 2017, at 5:11 PM, Dave Cottlehuber wrote: > > On Fri, 1 Dec 2017, at 22:06, Ryan J. Yoder wrote: >> I'm trying to install couchdb via snap on a raspberrypi. I've installed >> on my laptop, so i know the snap is in the store, but the armhf snap >> doesnt appear to be

Re: CouchDB sync error net::ERR_CONNECTION_RESET

ve >> using Node.js >> >> Regards, >> >> *Yvonne Aburrow* >> Applications Developer >> Information Systems Team >> *IT Services <http://www.brookes.ac.uk/obis/>* >> Oxford Brookes University <http://www.brookes.ac.uk/> >> >

Re: CouchDB sync error net::ERR_CONNECTION_RESET

Hi Yvonne, It looks like you’re trying to make an HTTPS connection to port 5984. Did you customize the server config? The default CouchDB configuration us port *6984* for HTTPS. Cheers, Adam > On Nov 28, 2017, at 9:37 AM, Yvonne Aburrow wrote: > > I am trying to sync

Re: Strange Errors After Reboot

Hi Steven, cryptic isn’t it? The “undef” error means that the VM cannot find the function couch_httpd_auth:basic_authentication_handler/1. Sure enough, that function is not defined in that module, nor is it listed in the default server configuration. Your configuration has a customized

Re: CouchDB 1.6 changes feed throughput decrease

Hi Carlos, I think the ML might have stripped the screenshot. I know there have been a couple of bugs that caused exactly that behavior in the past. Will see what I can dig up from JIRA. Cheers, Adam > On Jun 28, 2017, at 12:03 PM, Carlos Alonso wrote: > > Hi guys,

Re: _global_changes purpose

The guarantee on the per-DB _changes feed is much stronger — if you got a 201 or 202 HTTP response back on the updated documents will always show up in _changes eventually. It'd be nice if we could offer the same guarantee on _db_updates but there are some non-trivial technical challenges

Re: Stale mango queries?

Hi Assaf, Mango does not support stale queries at this time. COUCHDB-3209 is filed for that enhancement. The indexing performance is approximately equivalent to Erlang views, not JS. Cheers, Adam > On Jun 12, 2017, at 9:42 AM, aa mm wrote: > > Hi. > > Does mango

Re: _all_docs consistency in cluster

Hi Carlos, yes … The _all_docs, _changes, _view and _find endpoints do *not* apply any quorum to their results. They generate a merged result set from exactly one copy of every shard, and the copy that is selected is not always stable. So this is the defined (if admittedly unexpected)

Re: How scalable is replication?

Hi Simon, it is definitely possible for a single cluster to manage thousands of replication jobs simultaneously — we have done this in production — but it does introduce scalability challenges and quite a bit of computational overhead. There’s a lot of work happening to improve CouchDB’s

Re: Pagination recipe, Do you really need to keep updating the start key?

No, the “startkey_doc_id” is only considered after the start key is applied. For example: key=[02134], id=123 key=[02134], id=567 <- your second query starts from here … key=[02134, Jackson], id=234 <- not here Make sense? In other words, the view is actually indexed under the hood by the

Re: views failing due to fabric_worker_timeout and OS process timed out

Hi Gustavo, there are a couple of things going on here. Let’s address them individually: > On Feb 21, 2017, at 6:17 PM, Gustavo Delfino wrote: > > Hi, I am evaluating using CouchDB and all worked well with a small test > database. Now I am trying to use it with a much

Re: Relaxo Ruby gem no longer targets CouchDB

Hi Samuel, thanks for sending this note. I have to admit that I find some of the feedback confusing — a new query server was one of the headline features of 2.0 — but that’s neither here nor there. It’s good of you to provide a clear statement about the future of the Relaxo projects. Cheers,

Re: Storing mango indexes in the ddoc

Hi Stefan, Yes, Mango indexes are stored in design documents. The POST /db/_index endpoint accepts a “ddoc” query parameter that allows you to specify the ID of the document where you want to store the index. If you don’t specify that parameter a new doc is created automatically:

Re: Is there any technical reason why _revisions cannot be returned with _changes and/or views?

Hi Robert, that seems like a fine idea. I think the lack of _revisions support in the changes feed is largely a historical artifact. Once upon a time the seq_tree that powers the changes feed only had access to the leaf revisions of each document as opposed to the full revision tree. If you

Re: 2.0 _purge returning "not implemented"

Today there is not, but I’m keenly interested in pursuing this option. It’s technically feasible — the full deletion would be done by the compactor — but we want to be fairly careful in minimizing the ramifications for replication if a user configures this option. My ideal scenario is that we

Re: 2.0 _changes request returning all changes

Hi Geoff, did you add ?filter=_doc_ids to the query string parameters? http://docs.couchdb.org/en/2.0.0/api/database/changes.html#post--db-_changes Cheers, Adam > On Nov 9, 2016, at 12:19 AM, Geoff Bomford

Re: 2.0 _purge returning "not implemented"

Hi Geoff, Hmm, no … purge does not work at the clustered database level in the 2.0 release. It looks like we may have failed to document this change beyond the API response that you got. There are some subtleties in how we have to manage that operation in a cluster. For example, if you happen

Re: Modifying a cluster

e. I can see how do it with the other user > databases but not the system databases. > > Thanks, > Simon > > > -Original Message- > From: Adam Kocoloski [mailto:kocol...@apache.org] > Sent: Tuesday, 1 November 2016 10:44 PM > To: user@couchdb.apache.org > Subje

Re: Modifying a cluster

Hi Simon, that sounds more or less correct. I think you meant the “_dbs/” endpoint instead of “_all_dbs”. I’d agree that the process you outlined is a lot of manual labor. This is part of the price that we pay for having the flexibility to define a different sharding topology for each database

Re: Node names and cluster with CouchDB 2.0

suggest a couple > of tweaks to the documentation via a PR . > > Thanks again, > Simon > > > -Original Message- > From: Adam Kocoloski [mailto:kocol...@apache.org] > Sent: Wednesday, 26 October 2016 2:39 AM > To: user@couchdb.apache.org > Subject: Re:

Re: Node names and cluster with CouchDB 2.0

Hi Simon, if your nodes need to find each other by IP address you should use -name. You can specify it in VM.args like -name couchdb@ There shouldn't be a need to change the "couchdb@" element for each node unless you want to run multiple nodes on the same IP (not recommended). When you add

Re: CouchDB at ApacheCon EU / Apache BigData EU

Hi Jan, awesome - thanks for representing CouchDB! Wish I could be there, I’m especially interested in that second talk :) Cheers, Adam > On Oct 23, 2016, at 7:52 AM, Jan Lehnardt wrote: > > Hey all, > > I’m pleased to announced that I’ll be speaking at ApacheCon EU >

Re: CouchDB 2.0 Command Line Options

hanks for your help! > > -Original Message- > From: Jiang, Maggie > Sent: Thursday, October 06, 2016 5:27 PM > To: user@couchdb.apache.org > Subject: RE: CouchDB 2.0 Command Line Options > > Thanks Adam and Jan. We were able to have a few instances running with the

Re: CouchDB: 2.0 & 1.6.1 database compatibility

Lots of good questions there. On the storage size, note that even when you write only one revision of each document the database will accumulate some wasted space. Inserts to the database cause internal btree structures to be updated, and due to the copy-on-write nature of the storage engine

Re: CouchDB 2.0 Command Line Options

l.ini files on start up). Without the -a option, I'd have to >> build CouchDB 2.0 3 times (for example) in order to be able to start up 3 >> instances of it on a dev server. >> >> Maggie >> >> -Original Message- >> From: Adam Kocoloski [mailto:k

Re: CouchDB 2.0 Command Line Options

Hi Maggie, You’re right, the “-a” switch is ignored in 2.0. That’s a miss on our part. I filed https://issues.apache.org/jira/browse/COUCHDB-3183. You can still drop files in the local.d directory and they should take precedence over any files in default.* as well as local.ini. There are

Re: Sharding question for clustered CouchDB 2.0

Hi Peyton, It’s expected. The global_changes DB contains one document for every other database in the cluster. If you’re primarily writing to one database the associated doc in global_changes DB will have a ton of revisions and the shard hosting that doc will grow quickly. Other shards of

Re: CouchDB 2.0 and zones

Yes, it does. The API has changed a bit, though. You need to label each of the nodes in the /nodes database with a “zone” attribute and then define a config setting like [cluster] placement = metro-dc-a:2,metro-dc-b:1 which will ensure that two replicas for a shard will be hosted on nodes with

Re: 2.0 Clustering Data Encryption

The data exchange between nodes uses the Erlang distribution protocol, not HTTP. It’s an unencrypted TCP channel by default but as Bob mentioned it is possible to configure the distribution to use TLS. We could do more to document the minimal steps required to enable this in CouchDB. Adam >

Re: Leap year bug?

Definitely a bug. We set the favicon.ico to expire “one year from now”, and we do that by incrementing the year by one and keeping all other elements of the date the same :) https://github.com/apache/couchdb/blob/1.6.1/src/couchdb/couch_httpd_misc_handlers.erl#L49

Re: Couchdb Attachments architecture

Yes, actually we do have something in the works related to COUCHDB-769 to offload attachments to an external object storage system. We preserve the CouchDB API so an end user can’t tell if the offloading is happening. I’m overdue to get the code posted, and it’s only a prototype so it’ll need

Re: Query view with keys, is order guaranteed?

Yes, that’s the defined behavior, and it will persist in 2.x. You need to take this into account when you write your map function; e.g. if you `emit([“keyB”, “keyA”], “value);` and then query for [“keyA”,”keyB”] you will not get a match. Regards, Adam On Aug 22, 2015, at 8:02 AM, Stefan

Re: Starting couchd 2.0 under diverse network infrastructures

Good question. The node name is set by the vm.args file. It defaults to “-name couchdb” which will cause CouchDB to try to discover the system hostname, but you could set that value directly as “-name couchdb@FQDN” or even “-name couchdb@IPV4”. The key point is to set it to something that can

Re: CouchDB Filtered Replication - Group of Doc's Don't appear to be batched

Hi Bob, The replicator will dynamically choose _bulk_docs batch sizes based on the number of documents that are ready to be transmitted to the source. It’s possible to set an upper bound on the size of the batch, but at this time it’s not possible to set a lower bound. It sounds like what’s

Re: High CPU after loading 15K documents

Hi Kiril, no it’s not normal. Did you mean `couchjs` when you said `couchdb`? If so it’s likely related to indexing. Do your views have custom reduce functions? A poorly-behaved custom reduce function (e.g. one that doesn’t really “reduce” its output) could yield very slow indexing. Does the

Re: Recover space imposed by 4K minimum document size?

the button, the spinner in the UI never stops, but I did check that compact_running was false for the DB in question - so I assumed it finished. I suppose some issue with _utils could instead mean it never started? Is there some way to distinguish the two cases? On Mon, Jun 29, 2015 at 5:49 PM, Adam

Re: Recover space imposed by 4K minimum document size?

back. See this thread with the similar question: http://qnalist.com/questions/5836043/couchdb-database-size Question why is still open for me, but at least solution there is. -- ,,,^..^,,, On Tue, Jun 30, 2015 at 3:49 AM, Adam Kocoloski kocol...@apache.org wrote: Database compaction

Re: Recover space imposed by 4K minimum document size?

Database compaction should absolutely recover that space. Can you share a few more details? Are you sure the compaction completes successfully? Cheers, Adam On Jun 29, 2015, at 8:19 PM, Travis Downs travis.do...@gmail.com wrote: I have an issue where I'm posting single smallish (~500 bytes)

Re: CouchDB utc_id behavior

be the hardware clock is off and it takes time until ntpd syncs it and CouchDB starts in between. *With best regards,* Kiril Stankov, On 17-Jun-15 6:41 PM, Adam Kocoloski wrote: Do you happen to know if either one

Re: DB size question

Yep, it’s normal. The wasted space is due to the purely copy-on-write nature of the btree indexes that the database maintains. Two main things you can do to reduce the overhead: * use the _bulk_docs endpoint * choose a long common prefix for the _ids of the documents in a given payload Yes,

Re: CouchDB utc_id behavior

Do you happen to know if either one of these was correct-ish? Do you see any timestamps in the access logs that are also “off”? 05188de92ef02f - Mon, 15 Jun 2015 12:51:05 GMT 05188e0805067f - Mon, 15 Jun 2015 12:59:42 GMT Adam On Jun 16, 2015, at 12:44 PM, Kiril Stankov ki...@open-net.biz

Re: a case for couchdb

, — Adam Kocoloski IBM Distinguished Engineer CTO, Cloud Data Services On Jun 12, 2015, at 12:19 PM, Francesco Zamboni f.zamb...@mastertek.it wrote: Hello to everybody. My company is evaluating the use of couchdb for a new project. The set of features that couchdb have on paper matches

Re: Ordered changes feed in v2.0

A few scenarios here: * Any v2.x database with no replicas (N=1) and only one shard (Q=1) will recover the v1.x behavior exactly. * Any database with replicas but only one shard will have roughly ordered events. If a replica dies and gets repopulated from its peers you may see some reordering.

Re: Spring Data Adapter for CouchDB: CouchRepository

Hi Rodrigo, thanks! I know Spring Data support is something that has come up in conversations with Cloudant prospects. Cheers, Adam On Jan 14, 2015, at 5:10 AM, Rodrigo Witzel rwitze...@googlemail.com wrote: Hello Couch-er if you are a Java Developer and you want to use the Spring Data

Re: understanding couchdb errors

Hi Cory, line 440 in the 1.2.1 release of Apache CouchDB looks like this: {ok, RawBin:TotalBytes/binary} = file:pread(Fd, Pos, TotalBytes), Your initial mail reported a 'badmatch' error on this line and indicated a response of the form {ok, Bin}. The match that's failing is therefore the

Re: How get results in reversed order by date and without id field (stackoverflow)

Indeed, it may be a bit quirky but if you do what it asks you should get what you're looking for: myview?startkey=[3566120224,{}]endkey=[3566120224]descending=true That is, CouchDB always wants to start the traversal at the start key and finish at the end key. If you're supplying

Re: Help understanding crash log

On May 1, 2014, at 8:47 AM, Interactive Blueprints p.van.der.e...@interactiveblueprints.nl wrote: 2014-05-01 13:14 GMT+02:00 Herman Chan herman...@gmail.com: Thanks Adam, It seems like it is happening again, with more info this time. It looks like I am hitting some sort of system limit,

Re: Help understanding crash log

] [0.27768.43] Closing index for db: group_56a0df90-c79e-4863-ae71-2bde3cb0d801 idx: _design/hub sig: 4f6edcabc4b7a6357b714e1391ed93ac On 2014-05-01, at 9:18 AM, Adam Kocoloski kocol...@apache.org wrote: On May 1, 2014, at 8:47 AM, Interactive Blueprints p.van.der.e...@interactiveblueprints.nl

Re: Help understanding crash log

crazy. Adam On May 1, 2014, at 12:24 PM, Herman Chan herman...@gmail.com wrote: Thanks Adam, We just tried that and it seems to hold up. Just wondering if there is some kind of formula on what to set ERL_FLAGS to? Herman On 2014-05-01, at 10:51 AM, Adam Kocoloski kocol...@apache.org wrote

Re: Help understanding crash log

create something like 800,000 processes (we have around 800,000 db on this box), which is higher than what we set on ERL_FLAGS. Thanks for your help! Herman On 2014-05-01, at 2:31 PM, Adam Kocoloski kocol...@apache.org wrote: Sure, here are a few rules of thumb: * 1 process per inbound

Re: CouchDB load spike (even with low traffic)?

:54 PM, Adam Kocoloski kocol...@apache.org wrote: Hi Marty, the mailing list stripped out the attachments except for spike.txt. I don't know if they're the cause of the load spikes that you see, but the eaddrinuse errors are not normal. They can be caused by another process listening

Re: BigCouch merge - conflict management

Hi Klaus, N is the number of replicas of each document, not the number of nodes in the cluster. You could have a 30 node cluster with N=1 and spread a database across all those nodes (Q = 30). With N=1 you'll still have the consistency properties that you desire. Regards, Adam On Apr 30,

Re: Compaction halted right away

Hi Boaz, ugh. It looks like you're using deflate-1 for the file compression, right? Were you ever using snappy on this database? You say the compaction stops right away; is there a .compact file? If there is, can you remove it and try again? Adam On Apr 30, 2014, at 1:30 AM, Boaz Citrin

Re: Help understanding crash log

The process that manages the .ini configuration information inside the server was taking longer than 5 seconds to respond to requests. This caused other processes to crash. Eventually the death rate for processes in the supervision tree grew large enough that the VM decided to nuke the entire

Re: CouchDB load spike (even with low traffic)?

Hi Marty, the mailing list stripped out the attachments except for spike.txt. I don't know if they're the cause of the load spikes that you see, but the eaddrinuse errors are not normal. They can be caused by another process listening on the same port as CouchDB. Fairly peculiar stuff. The

Re: Compaction of a database with the same number of documents is getting slower over time

To first order it shouldn't be the case. Is the number of deleted documents growing with time? That'd have an impact. Adam On Apr 22, 2014, at 8:06 AM, Boaz Citrin bcit...@gmail.com wrote: Hello, Our database contains more or less the same number of documents, however the documents

Re: Compaction of a database with the same number of documents is getting slower over time

, but total number don't change that much. On Tue, Apr 22, 2014 at 4:41 PM, Adam Kocoloski adam.kocolo...@gmail.comwrote: To first order it shouldn't be the case. Is the number of deleted documents growing with time? That'd have an impact. Adam On Apr 22, 2014, at 8:06 AM, Boaz Citrin

Re: Issues with terabytes databases

Hi Jean-Yves, welcome! Always nice to hear reports from production deployments. Replies inline: On Apr 22, 2014, at 10:09 AM, Jean-Yves Moulin jean-yves.mou...@eileo.com wrote: Hi everybody, we use CouchDB in production for more than two years now. And we are almost happy with it :-) We

Re: Compaction of a database with the same number of documents is getting slower over time

...@gmail.com wrote: You got it right. How can I only replicate non deleted docs? בתאריך 22 באפר' 2014 17:15, Adam Kocoloski kocol...@apache.org כתב: Sorry, just so we're super clear -- the doc_count is roughly constant but the doc_del_count is rising? Compaction time scales with the sum of those

Re: Reseting DB Sequence Number

Hi Behrad, no, there's no way to reset that sequence number. How many deleted docs do you have in your DB? Is the aim behind your question to avoid sending those deleted docs through the view generation process? Note that the actual number of entries in the index is going to be significantly

Re: Replication vs. Compaction

On Feb 18, 2014, at 11:38 AM, Jan Lehnardt j...@apache.org wrote: On 31 Jan 2014, at 20:08 , Jason Smith j...@apache.org wrote: However there is a pathological situation where you are updating faster than the compactor can run, and you will get an infinite loop (plus very heavy i/o and

Re: Revisions lost on CouchDB 1.2.0

On Jan 31, 2014, at 6:36 PM, Luca Morandini lmorand...@ieee.org wrote: On 31/01/14 19:42, Robert Samuel Newson wrote: As Simon says, this is the normal and expected behavior of CouchDB after database compaction (or replication). CouchDB is not a revision control system, it only keeps the

Re: Replication of attachment is extremely slow.. LOGGED INFORMATION

Well how about that. Go Nick! Adam On Jan 24, 2014, at 7:31 PM, Paul Davis paul.joseph.da...@gmail.com wrote: Interesting note, this is fixed by applying the patch to COUCHDB-1953. On Fri, Jan 24, 2014 at 3:03 PM, Rian R. Maloney rian.malo...@yahoo.com wrote: Will do Dave. Thanks again

Re: Number of surviving revisions after compaction

On Jan 20, 2014, at 11:29 AM, Vladimir Ralev vladimir.ra...@gmail.com wrote: Hello all I was reading about _revs_limit http://wiki.apache.org/couchdb/HTTP_database_API#Accessing_Database-specific_options which defaults to 1000 or so here

Re: Errors when trying to compact

Hi Vladimir, compaction is an asynchronous process and so only a small subset of the possible errors that could occur during a compaction will surface in time to be reported as part of the response to your POST request. Adam On Jan 20, 2014, at 5:05 PM, Vladimir Ralev vladimir.ra...@gmail.com

Re: Clarification on UUIDs Configuration

On Jan 20, 2014, at 3:36 PM, Jens Alfke j...@couchbase.com wrote: On Jan 20, 2014, at 12:19 PM, Stefan Klein st.fankl...@gmail.com wrote: a performance impact of random document ids. If the document ids are not sequential larger portions of the b-tree need to be rewriten. Is this related

Re: A CouchDB/Cloudant Scale Authorization question

Hi Andy, you're right that a DB per user-feature is currently the way to go to achieve the kind of access control granularity that you have in mind. 100k databases in a Cloudant account is not all that uncommon. Cheers, Adam On Jan 9, 2014, at 8:55 AM, Andy Dorman ador...@ironicdesign.com

  1   2   3   4   >