2.7. Upgrading from prior CouchDB releases
2.7.1. Important Notes
- Always back up your
data/
andetc/
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 inetc/local.ini
or anyetc/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 databasesreplicate
- replicates one or more 1.x databases to CouchDB 2.xrebuild
- rebuilds one or more CouchDB 2.x viewsdelete
- 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 thecouchdb
user hasproper 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 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:
- $ 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 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