Skip to end of metadata
Go to start of metadata

Overview

This page gives some guidance on how to maintain and troubleshoot a CouchDB installation for the Chef Server.

It is not meant to be comprehensive, merely to cover the common topics that users will encounter when working with CouchDB and Chef.


For full details about CouchDB, please see its project page.

RESTful API

CouchDB has a RESTful API. This means you can interact with it using any tool that speaks HTTP. For example, curl.

Compaction

CouchDB stores a revision for every document when it is updated. When the Chef Client runs, it saves the node data to the server multiple times. Each time it saves, CouchDB creates a new revision. Over time with a number of clients, this can add up and cause the CouchDB database to become quite large.

CouchDB has a feature called Compaction that can be used to remove older revisions of documents. To compact a growing database, use curl to POST on the server:

Since this is a common thing to do on a Chef Server, the Opscode chef-server cookbook does this in its default recipe.

Use of the Opscode chef-server cookbook means that every time Chef runs on the Chef Server with the default Recipe for CouchDB compaction, it will compact the database. In addition to compacting the database, the default recipe also compacts the views.


Compact the Views
If you are managing the CouchDB compaction yourself (rather than using the chef-server cookbook cookbook to compact the database and the views), be sure to run compaction on the individual views as well as the database.

The Opscode chef-server cookbook contains the default recipe which compacts both the database and the views. You can review it as an example on one method for compacting the views. Without compaction, the views may eventually consume all available disk space.

Administrative Interface

CouchDB comes with a web interface for administration. It can be accessed via http://localhost:5984/_utils. Obviously since this is running on localhost by default, it won't be accessible from your management workstation, so create an SSH tunnel to the server to forward the port. If your Chef server is chef.example.com:

Then point your local system's web browser to http://localhost:5984/_utils.

Client/Node ID from CouchDB

To get the ID of a client/node from CouchDB execute

The returned data should look something like







Chef Indexer


Backing Up Chef Server



Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Feb 04, 2012

    wheezy and sid users, debian provides couchdb 1.1.1 compiled with --enable-js-trunk.
    recent spidermonkey doesn't work well with couchdb 1.1.1 and chef (see http://tickets.opscode.com/browse/CHEF-2827?focusedCommentId=21164&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-21164)
    you'll have to recompile it without this option. (remove --enable-js-trunk from debian/rules, and replace libmozjs-dev by libmozjs185-dev in debian/control, you might also want to edit the debian/changelog before rebuilding your own package)

    squeeze users might encounter this issue : https://gist.github.com/1726030 (it looks like https://issues.apache.org/jira/browse/COUCHDB-893)
    I've managed to workaround the issue by using the couchdb replicator to copy from my 0.11.0 server to a new 1.1.1 server. (iow, i had to upgrade to couchdb 1.1.1)