1.7. Upgrading from prior CouchDB releases

1.7.1. Important Notes

  • Always back up your data/ and etc/ directories prior to upgrading CouchDB.
  • We recommend that you overwrite your etc/default.ini file with the version provided by the new release. New defaults sometimes contain mandatory changes to enable default functionality. Always places your customizations in etc/local.ini or any etc/local.d/*.ini file.

1.7.2. Upgrading from CouchDB 2.x

If you are coming from a prior release of CouchDB 2.x, upgrading is simple.

1.7.2.1. Standalone (single) node upgrades

If you are running a standalone (single) CouchDB node:

  1. Plan for downtime.
  2. Backup everything.
  3. Check for new recommended settings in the shipped etc/local.ini file, and merge any changes desired into your own local settings file(s).
  4. Stop CouchDB.
  5. Upgrade CouchDB in place.
  6. Start CouchDB.
  7. Relax! You’re done.

1.7.2.2. Cluster upgrades

CouchDB 2.x is explicitly designed to allow “mixed clusters” during the upgrade process. This allows you to perform a rolling restart across a cluster, upgrading one node at a time, for a zero downtime upgrade. The process is also entirely scriptable within your configuration management tool of choice.

We’re proud of this feature, and you should be, too!

If you are running a CouchDB cluster:

  1. Backup everything.
  2. Check for new recommended settings in the shipped etc/local.ini file, and merge any changes desired into your own local settings file(s), staging these changes to occur as you upgrade the node.
  3. Stop CouchDB on a single node.
  4. Upgrade that CouchDB install in place.
  5. Start CouchDB.
  6. Double-check that the node has re-joined the cluster through the /_membership <api/server/membership> endpoint. If your load balancer has health check functionality driven by the /_up <api/server/up> endpoint, check whether it thinks the node is healthy as well.
  7. Repeat the last 4 steps on the remaining nodes in the cluster.
  8. Relax! You’re done.

1.7.3. Upgrading from CouchDB 1.x

CouchDB 2.x fully supports upgrading from CouchDB 1.x. A data migration process is required to use CouchDB 1.x databases in CouchDB 2.x. CouchDB 2.1 supplies a utility, couchup, to simplify the migration process.

1.7.3.1. couchup utility

The couchup utility is a Python script that supports listing CouchDB 1.x databases on a CouchDB 2.x installation, migrating them for use with CouchDB 2.x, rebuilding any database views after migration, and deleting the 1.x databases once migration is complete.

couchup runs under Python 2.7 or 3.x, and requires the Python requests library, and can optionally make use of the Python progressbar library.

1.7.3.1.1. Overview

couchup makes it easy to migrate your CouchDB 1.x databases to CouchDB 2.x by providing 4 useful sub-commands:

  • list - lists all CouchDB 1.x databases
  • replicate - replicates one or more 1.x databases to CouchDB 2.x
  • rebuild - rebuilds one or more CouchDB 2.x views
  • delete - deletes one or more CouchDB 1.x databases

Once you have installed CouchDB 2.x, copy the .couch files from your 1.x installation (or, if you’ve upgraded in-place, do nothing), ensure the permissions on the files are set so the couchdb user has proper read/write access, then use commands similar to the following:

$ couchup list           # Shows your unmigrated 1.x databases
$ couchup replicate -a   # Replicates your 1.x DBs to 2.x
$ couchup rebuild -a     # Optional; starts rebuilding your views
$ couchup delete -a      # Deletes your 1.x DBs (careful!)
$ couchup list           # Should show no remaining databases!

The same process works for moving from a single 1.x node to a cluster of 2.x nodes; the only difference is that you must complete cluster setup prior to running the couchup commands.

1.7.3.1.2. Special Features

  • Lots of extra help is available via:
$ couchup -h
$ couchup <sub-command> -h

  • Various optional arguments provide for admin login/password, overriding ports, quiet mode and so on.

  • couchup delete will NOT delete your 1.x DBs unless the contents are identical to the replicated 2.x DBs, or you override with the -f/--force command (be VERY careful with this!!)

  • couchup replicate supports an optional flag, -f/--filter-deleted, to filter delete documents during the replication process. This can improve the performance and disk-size of your database if it has a lot of deleted documents.

    It is IMPORTANT that no documents be deleted from the 1.x database during this process, or those deletions may not successfully replicate to the 2.x database. (It’s recommended that you not access or modify the 1.x database at all during the whole couchup process.)

1.7.3.2. Manual CouchDB 1.x migration

If you cannot use the couchup utility, or prefer to migrate yourself, a manual migration is also possible. In this process, a full-featured HTTP client such as curl is required.

The process is similar to the automated approach:

  1. Copy all of your 1.x .couch files to the CouchDB 2.x data/ directory and start CouchDB (2.x).
  2. Set up replication for each database from the node-local port (default: 5986) to the clustered port (default: 5984). This can be done via the /_replicate endpoint or the replicator database.
  3. Rebuild each view by accessing it through the clustered port.
  4. Confirm that all databases and views can be accessed as desired.
  5. Remove the 1.x databases via a DELETE request on the node-local port (default: 5986).