Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document couchdb disaster recovery process #4229

Open
piripillo opened this issue May 28, 2020 · 3 comments
Open

Document couchdb disaster recovery process #4229

piripillo opened this issue May 28, 2020 · 3 comments

Comments

@piripillo
Copy link

Description

i have a couchdb 3.1 cluster with 2 nodes VM and i backup daily data and etc folder
i would like to create, starting from backup same servers and data in a new environment (i would like to simulate a complete down on the old infrastructure)
i setup two couchdb, than i restore the 2 folder, than i change the ipaddress under vm.args
i add and remove the ip on the cluster to matching the actual configuration
https://docs.couchdb.org/en/stable/cluster/nodes.html#adding-a-node

in the interface i can see all the databases but are in status [This database failed to load.]
in the log file i have [Failed to ensure auth ddoc _users/_design/_auth exists for reason: read_failure]
if i try to browse _users/_design/_auth i receave
error "internal_server_error"
reason "No DB shards could be opened."
ref 2822102114

there is a step by step guide to do this?

Steps to Reproduce

Expected Behaviour

disaster solution for a cluster starting from backup

Your Environment

  • CouchDB version used:3.1
  • Browser name and version:
  • Operating system and version:ubuntu 18

Additional Context

@wohali
Copy link
Member

wohali commented May 28, 2020

Hi there,

This is not a CouchDB bug. GitHub is for actual CouchDB bugs only. I will, however, keep this open as a request for more documentation.

If you are looking for general support with using CouchDB, please try one of these other options:

  • The user mailing list. Signup instructions are here
  • The Slack/IRC chat room. Joining instructions are here

@wohali wohali transferred this issue from apache/couchdb May 28, 2020
@wohali
Copy link
Member

wohali commented May 28, 2020

The problem you're facing is that the -name parameter that you're changing is used by CouchDB internally for every database to log where the shards are stored.

If your entries in -name were DNS entries, not IP addresses, you'd do exactly what you said, change DNS, and everything would be fine.

If you insist on using IP addresses, you're going to have to edit the _dbs document for every database you have, and change all instances of every IP address for all machines to the new IP address. Not only is this error prone, it's a pain in the arse :)

So, switch to DNS, and always put -name [email protected] in vm.args, not IP addresses.

@wohali wohali changed the title couchdb disaster recovery Document couchdb disaster recovery & -name best practices better May 28, 2020
@wohali wohali changed the title Document couchdb disaster recovery & -name best practices better Document couchdb disaster recovery process Mar 29, 2021
@wohali
Copy link
Member

wohali commented Mar 29, 2021

We addressed the -name portion of this in apache/couchdb-documentation#596.

@big-r81 big-r81 transferred this issue from apache/couchdb-documentation Oct 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants