Upgrades are more straightforward, you only update the software. CouchDB 2.3 can read databases made with CouchDB 2.2 (and earlier). What you've done is unusual, created a new, separate CouchDB server and moved all the database files over by an external method.
The procedure outlined is not ideal but it should work. The best way to do it is to copy the .couch files for the database under shards/ and the corresponding document from the '_dbs' database (which is reachable at localhost:5986 not :5984). This method does not require downtime as long as there was no existing database of the same name on the destination server (if there is, you can delete it before copying over the _dbs document). Again, for version upgrades, you don't have to move a thing, just update the software and restart couchdb. For moving data, we recommend replication (which works if the source or target is couchdb 1.x, 2.0, 2.1, 2.2, 2.3, and so on). B. -- Robert Samuel Newson rnew...@apache.org On Wed, 13 Feb 2019, at 06:58, jtuc...@objektfabrik.de wrote: > So here is something that seems to work: > > * install couchdb on Windows Machine > * set up as single node > * create a db of the same name as the one of the origin machine (Linux > based in my case) > * stop CouchDB service > * copy all of the .couch files from the /data/shards directory from > the linux machine to local machine > * move them one by one to the /data/shards directory on the target machine > * replace the numeric part of the pre-existing shard files > (mydb.1550039930.couch) with the one of the files that were created > when you created the database on the Windows machine > * restart CouchDB service > > Fauxton can see the database and lists the number of documents. > Attachmants can be opened with Fauxton. Our Application can open > documents and read attachments. > > So this seems to work. But as I understand it, this is *not* a > recommended strategy for backup/restore and transport of data. Too bad > the single file thing doesn't work any more... This might especially be > a bad idea whenever you update CouchDB I guess. > > > Joachim > > > > > > > > Am 12.02.19 um 21:09 schrieb Krawetzky, Peter J: > > Is it possible the encode or character set is unreadable to the windows > > instance? These two OS's are completely different and in some cases I've > > had issues copying from one OS to another and vice versa. > > > > > > > > Proprietary > > > > -----Original Message----- > > From: Joachim Tuchel <jtuc...@objektfabrik.de> > > Sent: Tuesday, February 12, 2019 3:03 PM > > To: user@couchdb.apache.org > > Subject: [EXTERNAL] Re: Restoring a 2.2 CouchDB on a newly installed 2.3 > > > > **** External Email - Use Caution **** > > > > Thanks for the info. Seems like a little more complex than before... > > > > So the first thing I’ll try is copying the full /data directory (I need to > > get this running now). > > > > Replication is a bit difficult if you cannot open ports and the dev > > machines don’t have a fixed ip. > > > > Does anybody have recipes for such scenarios? I also wonder what a simple > > backup/restore looks like.. > > > > Joachim > > > >> Am 12.02.2019 um 20:16 schrieb Robert Newson <rnew...@apache.org>: > >> > >> since 2.0 there is more to this than copying the dbname.couch file around. > >> For one thing, every database is now sharded, so you have several .couch > >> files to copy (even if you only have one node). So make sure you've copied > >> them all and kept their directory hierarchy. In addition there is a meta > >> database called '_dbs' which is how couchdb knows where the shards of all > >> databases are. In your old install, you will have a document in _dbs > >> database named after the database you copied. You'll need to copy it to > >> your new cluster and modify the node names embedded in the by_node and > >> by_range attributes (assuming your new machine _has_ a different name. if > >> they're both 'couchdb@127.0.0.1' you won't need this step). > >> > >> We recommend replication as the means to move data from one couchdb > >> instance to another rather than moving database files around by hand. > >> > >> B. > >> > >> -- > >> Robert Samuel Newson > >> rnew...@apache.org > >> > >>> On Tue, 12 Feb 2019, at 18:57, jtuc...@objektfabrik.de wrote: > >>> Hi, > >>> > >>> > >>> we have a 2.2 instance running on Ubuntu Linux. It is a single node setup. > >>> > >>> I am setting up a new Windows Development machine and tried copying > >>> the .couch file from a backup to this new machine. On the CouchDb > >>> website, only 2.3 is available for download for Windows. > >>> > >>> So I copied the .couch from Linux to this Windows Machine into > >>> C:\CouchDB\data. it is readable (no permission problems). But the > >>> database doesn't show up in Fauxton, no matter how often I restart > >>> the CouchDb service or WIndows. > >>> > >>> The new machine is also set up as a single node and this way of doing > >>> things has been working for years now (just the path where the > >>> databases are has changed). If I create a database using Fauxton, it > >>> doesn't show up in /data, but in the /shards subdirectories. But I > >>> don't have any /shard files on the production Linux box. > >>> > >>> So how can I restore this single database in a Windows Development > >>> machine? > >>> > >>> > >>> I am sure I forgot to mention something important about my versions > >>> and setup. Sorry for that, please ask... > >>> > >>> > >>> Thanks > >>> > >>> > >>> Joachim > >>> > >>> > > This e-mail may contain confidential or privileged information. If you > > think you have received this e-mail in error, please advise the sender by > > reply e-mail and then delete this e-mail immediately. Thank you. Aetna > >
