Package: couchcopy
Create an archive of a running CouchDB node, saving CouchDB filesdata/.shards,data/_dbs.couchanddata/shardsin this order.
To allow backup of a running CouchDB, files are copied before archive creation.Restore an archive of a CouchDB node to a new CouchDB. The new CouchDB can be a
cluster of multiple nodes.
The new CouchDB configuration should already be done before using Couchcopy,
however, all existing data will be deleted.
During restoration, CouchDB will be stopped and restarted on each cluster
nodes.LimitationsTested with CouchDB 3.1.1 only.To restore an archive, Couchcopy needs to stop and start CouchDB. It assumes
that CouchDB is controlled by systemd. If you don’t use systemd you can
change parameters--couchdb-startand--couchdb-stop.Your CouchDBnvalue should be higher or equal to the number of nodes in
your CouchDB cluster.
Otherwise saving shards from one node would not be enough to save and restore
all databases.
SeeCouchDB documentationfor more
details on replicas and nodes.The number of shards per database, i.e. the value ofq, should be the same
for the origin CouchDB and the destination CouchDB.
Otherwise,tree /data/shardsis not the same.Couchcopy assumes you have read and write permissions on CouchDB data
directories. If you don’t have them, you can try to use the--use-sudooption.Get startedInstall Couchcopy:pipinstall--usercouchcopyMake a backup tobackup.tar.gz, from machineold-serverwith CouchDB
data at/var/lib/couchdb:couchcopybackupold-server,/var/lib/couchdbbackup.tar.gzRestore a backupbackup.tar.gzto a 3-node CouchDB cluster where machines
are accessible via SSH atcluster_vm1,cluster_vm2,cluster_vm3:couchcopyrestorebackup.tar.gzadmin:password@cluster_vm1,/var/lib/couchdb\admin:password@cluster_vm2,/var/lib/couchdb\admin:password@cluster_vm3,/var/lib/couchdbQuickly access data from a backup, by spawning a CouchDB instance:couchcopyloadbackup.tar.gzImprovecouchcopy loadloading time by preconfiguring CouchDB metadata, so
that theUpdating CouchDBmetadata...step is not needed:couchcopyunbrandslow_backup.tar.gzquick_backup.tar.gzFor more options:couchcopy-hcouchcopybackup-hcouchcopyunbrand-hcouchcopyload-hcouchcopyrestore-hOn Fedora, CouchDB can be installed and configured with the following :sudodnfcoprenable-yadrienverge/couchdbsudodnfinstallcouchdbsudosh-c'echo "admin = password" >> /etc/couchdb/local.ini'sudosystemctlrestartcouchdbIf you work with remote machines, CouchDB needs to listen to remote IPs on
each machine. You can enable it with the following (for security, revert it
afterwards):sudosed-i's/;bind_address = 127.0.0.1/bind_address = 0.0.0.0/g'/etc/couchdb/local.iniImplementation detailsDuring restoration, if the new CouchDB nodes names are not the same as the
old CouchDB, nodes names are updated using  CouchDB/_node/_local/_dbsendpoint. See CouchDB/_node/_local/_dbsendpoint documentation.During restoration, Couchcopy first updates one CouchDB node metadata (i.e. the
list of nodes names) then it lets CouchDB itself synchronize metadata to the
other nodes.
Couchcopy exits when the synchronization is finished for all nodes, using
undocumented CouchDB/_dbsendpoint to monitor CouchDB nodes
synchronization.
You can skip that part if you want, i.e. you can exit Couchcopy safely when the
following log trace is displayed[Waiting for CouchDB clustersynchronization...].
For a CouchDB of 10^5 databases, updating the first node metadata takes 35
minutes then metadata synchronization to the other nodes takes 6 minutes.
For a CouchDB of 100 databases only, both operations are nearly instantaneous.Developer notesTo speed up CouchDB nodes synchronization it is possible to:Disable compaction daemon during synchronization (for 10^5 databases, nodes
synchronization goes from 6 minutes down to 4 minutes).Copy the saved_dbs.couchon every machine, but it sounds dangerous, it
sounds better to let CouchDB rebuild these files itself (for 10^5 databases,
nodes synchronization goes from 6 minutes down to 0 seconds).Machines disk IOPS consumption is around 1200 IOPS during restoration.Sometimes, the nodes synchronization, instead of taking 6 minutes for 10^5
databases, takes more than 3 hours. I wasn’t able to find the cause or
eliminate this bad performance reliably. I advise using fast machines on the
same local network, and disable compaction.Interesting discussions on CouchDB:On nodes renaming afterdata/*copy for a backup restoration:https://github.com/apache/couchdb/discussions/3436#discussioncomment-494504On CouchDB cluster internal backfill for a backup restoration:https://www.mail-archive.com/user@couchdb.apache.org/msg30003.htmlUnanswered questions about nodes renaming speed, and backup feasibility:https://www.mail-archive.com/user@couchdb.apache.org/msg29982.htmlhttps://github.com/apache/couchdb/discussions/3383Build and publishpythonsetup.pysdisttwineuploaddist/*LicenseThis program is licensed under the GNU General Public License version 3.