2.7. Upgrading from prior CouchDB releases

2.7.1. Important Notes

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

2.7.2. Upgrading from CouchDB 2.x

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

2.7.2.1. Standalone (single) node upgrades

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

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

2.7.2.2. Cluster upgrades

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

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

If you are running a CouchDB cluster:

  • Backup everything.
  • 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.
  • Stop CouchDB on a single node.
  • Upgrade that CouchDB install in place.
  • Start CouchDB.
  • Double-check that the node has re-joined the cluster through the/_membership endpoint. If your load balancer hashealth check functionality driven by the /_up endpoint,check whether it thinks the node is healthy as well.
  • Repeat the last 4 steps on the remaining nodes in the cluster.
  • Relax! You’re done.

2.7.3. Upgrading from CouchDB 1.x

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

2.7.3.1. couchup utility

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

couchup runs under Python 2.7 or 3.x, and requires the Pythonrequests library, and can optionallymake use of the Python progressbar library.

2.7.3.1.1. Overview

couchup makes it easy to migrate your CouchDB 1.x databases to CouchDB2.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 fromyour 1.x installation (or, if you’ve upgraded in-place, do nothing),ensure the permissions on the files are set so the couchdb user hasproper read/write access, then use commands similar to the following:
  1. $ couchup list           # Shows your unmigrated 1.x databases
  2. $ couchup replicate -a   # Replicates your 1.x DBs to 2.x
  3. $ couchup rebuild -a     # Optional; starts rebuilding your views
  4. $ couchup delete -a      # Deletes your 1.x DBs (careful!)
  5. $ couchup list           # Should show no remaining databases!

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

2.7.3.1.2. Special Features

  • Lots of extra help is available via:
  1. $ couchup -h
  2. $ 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 areidentical 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, tofilter delete documents during the replication process. This canimprove the performance and disk-size of your database if it has a lotof deleted documents.

It is IMPORTANT that no documents be deletedfrom the 1.x database during this process, or those deletions may notsuccessfully replicate to the 2.x database. (It’s recommended thatyou not access or modify the 1.x database at all during the wholecouchup process.)

2.7.3.2. Manual CouchDB 1.x migration

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

The process is similar to the automated approach:

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

原文: http://docs.couchdb.org/en/stable/install/upgrading.html