Couchdb 1.x removed from my server, reinstalled Couchdb 3.x, how do I get my old files with the .couch extension to work with it? - couchdb

Good morning.
We have been running couchdb for quite some time on our Ubuntu (18.04) server with no problem. Unfortunately, the IT department recently performed a number of updates that messed with a lot of things on the server. We've managed to get most of it back up and running, but we are still struggling with couchdb.
Our Python flask website did not load and the error log showed that it was unable to access couchdb. After investigating, we realised that couchdb was completely removed from the server.
We reinstalled couchdb but the version that was installed is version 3, and according to the prompt we got during installation our files in /var/lib/couchdb are for version 1, for which they recommend to use the replicator tool to upgrade them to version 3.
We've been trying to do this without success by following this guide and this one.
I could be wrong because I'm not a couchdb expert, but it looks like the problem is that these tutorials tell us how to replicate a database from an already running couchdb, which we do not have a the moment (only the newly installed version with no database in it).
Currently, Python flask is able to connect to couchdb (the newly installed one) but does not find any database, and when trying to access the databases manually using couchdb commands, we are just prompted with:
{"error":"not_found","reason":"Database does not exist."}
We have a backup of the couchdb files, they look like a bunch of files with .couch extension. They also still are in /var/lib/couchdb.
The question is, how can we make these .couch files work with our newly installed version of couchdb?
Thanks in advance to anyone who can help with that.

I finally managed to do it, and this is how:
I installed an older version of Ubuntu server on a virtual machine (I used VirtualBox) and installed couchdb 1.6. I manually added my .couch files into /var/lib/couchdb using FileZilla. I tested that everything worked fine and it did.
After that I upgraded couchdb 1.6 to couchdb 2.3 and used the couchup tool that comes with couchdb 2 (note that couchdb 2 and 3 require you to set an admin password). This page shows how to use it. The couchup script is located in /opt/couchdb/bin.
I navigated to this folder and I ran the following:
$ python couchup list # Shows your unmigrated 1.x databases
$ python couchup replicate -a --login admin --password password # Replicates your 1.x DBs to 2.x
$ python couchup rebuild -a --login admin --password password # Optional; starts rebuilding your views
$ python couchup delete -a --login admin --password password # Deletes your 1.x DBs (careful!)
$ python couchup list # Should show no remaining databases!
It turns out that couchdb 2.x databases work just fine with couchdb 3 so there wasn't anything else needed. I uploaded the replicated databases to my deployed server and it worked right away.
INFO: note that with couchdb 1, each database you create appears as one single file. (e.g. db1.couch, db2.couch, etc.), but with couchdb 2 and 3 they are all located in the file _dbs.couch (you may want to transfer shards, _users.couch and the other files in /var/lib/couchdb to ensure everything works well).
INFO 2: the couchup utility is only installed by default with couchdb 2, you won't have it if you jump straight to couchdb 3. However, couchup is just a python script and I believe it is possible to download it from this github page, so you may not even need to install couchdb 2 (I have not tried it this way, so no guarantees).

Related

Upgrading MariaDB on AWS Linux machine

I have a moodle site which runs on a linux AWS box and I'm trying to upgrade it. I need to have MariaDB 10.3 on there, and I currently have 10.2.10
I've followed the instruction for upgrading using yum from this webpage https://www.ryadel.com/en/mariadb-10-upgrade-10-3-without-losing-data-how-to/ and all goes fine until I get to Running Transaction Check and Running Transaction Check at which point I get the following
Transaction check error:
file /etc/my.cnf from install of MariaDB-common-10.3.27-1.el7.centos.x86_64 conflicts with file fr
om package mariadb-config-3:10.2.10-2.amzn2.0.3.x86_64
file /usr/lib64/libmysqlclient.so.18 from install of MariaDB-compat-10.3.27-1.el7.centos.x86_64 co
nflicts with file from package mariadb-libs-3:10.2.10-2.amzn2.0.3.x86_64
I'm not sure what to do now? Any help or pointers would be appreciated.
EC2 is not designed for database specifically
You seem to be installing and running your database on EC2 (what you call a linux AWS box), this means you can SSH into the instance and install software manually and carry out updates and edit configuration files and settings etc.
RDS is designed for Database
RDS also has other really convenient features like automatic version upgrade and maintenance window management.
If your situation allows I would suggest to use a tool designed for database instead of having to configure things manually. It will save you a lot of time and troubleshooting, it is also more secured.

Installing JavaComm API on Ubuntu

I know this question has been asked several times around the internet, but I have spent about a week trying to solve this problem with little luck.
I am trying to install JavaCommAPI (an archived Java package to allow communication with rs232) on a remote linux Ubuntu 11.0, 32-bit server in order to deploy a web project which I have developed on a local apache server on my windows PC.
The thing that puzzles me is, I am able to get the .war web project to deploy on a local apache server on a separate 32-bit LinuxMint16 PC by correctly placing the javax.comm.properties, comm.jar, and libSerialParallel.so files in their respective places.
I use System.getProperty("java.library.path"); in order to find the correct library path in order to install correct files.
On my LinuxMint16:
javax.comm.properties -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib
comm.jar -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib/ext
libSerialParallel.so -- /usr/lib/jvm/java-7-openjdk-i386/jre/lib/i386
....works!
On my remote Ubuntu server I did the exact same for its reported library path
(for example: /usr/local/jdk/jdk1.7.0_45/jre/lib/javax.comm.properties ;
/usr/local/jdk/jdk1.7.0_45/jre/lib/ext/comm.jar ;
/usr/local/jdk/jdk1.7.0_45/jre/lib/i386/libSerialParallel.so)
...fails =(
Things of note: I added the needed apache jars and comm.jar to my libraries in Eclipse using the BuildPath wizard (right click on project --> Build Path-->add external jars) which points to local files on my PC which I obviously cannot use for a remote server which I am only accessing through command line. May this is affecting it somehow?
I tried to get error output (System.err) from the Java Console printed to a separate file for my remote server as that feedback was very helpful in getting all the files sorted on my LinuxMint PC.
PrintStream ps = new PrintStream(pathName);
System.setOut(ps);
System.setErr(ps);
Which again, is oddly working beautifully to print the stream to a local .txt file on my LinuxMintPC but not to the one I designate on my remote ubuntu server.
I am really at a wits end here!! Am I mixing and matching appropriate versions of Systems prohibiting things to run smoothly? I am not sure how to proceed from here, if anyone has any insights I would die of happiness. Thanks
I needed to install OPEN JDK7 on my ubuntu, put files in appropriate library paths (as described above) and now it works.

How to upgrade couchdb 0.11.0 to 1.2.0

I have a database on couchdb 0.11.0 in a debian 6 box - I have been struggling to transfer this database to another debian (7) box with couchdb 1.2.0. The error seems to be around 'content type ' specification.
The apache-couchdb documentation talks about 'simply applying a patch to the replicator to allow content type: application/json'. But how do you do this? Any help deeply appreciated
You could just copy the db file instead of using the replication. By default (on Centos) this file it can be find under /var/lib/couchdb/ path. Once you copy it to couchdb 1.2.0 folder it should notice the old database file format and upgrade it.
Note: You might have to restart the database to make it notice the new file, although I'm not sure if this step is necessary.

Liferay 5.2.3 to 6.0 Upgradation steps (Windows + Tomcat + MySql)

I have taken the backup of my live portal and I want to upgrade it to newer version in localhost and then move the upgraded version to my live site.
I followed the steps in the link http://www.liferay.com/community/wiki/-/wiki/Main/Upgrade+Instructions+from+5.2+to+6.0. and my stpes are :
1) I have setup the new liferay 6.0 on my localhost
(successful installation of liferay 6.0 with inbuilt Hypersonic database )
2) I have imported MySql database of live system to the local MySql Server.
3) After stopping the tomcat server, I have changed the configuration file portal-ext.properties for the MySql database details.
4) Then, I have started the start.bat file. It is showing upgrade process well but after few minutes window is closed
Can anyone help me in this regard where I have done some mistake or am I missing something during the upgration. If anyone has some idea then please share their steps.
Thanks in advance
You don't mention that you also copy your document library / image gallery folder to the new installation. This typically (unless configured otherwise) sits in your "data" folder. Just importing the MySql database isn't enough, as it contains only the metadata for doclib & image gallery.
You'll have to take this into account for backups also - ideally you'd read about backup and set up a second 5.2.3 instance (and make sure it runs) from your backup, then start upgrading. I typically forbid to call something a backup if nobody ever demonstrated, that they can use it to successfully restore in a completely new environment. This is your chance to ultimately test your backup procedure.

Restore AdminParty state on CouchBase Single Server?

I'm using a local machine for development that needs to allow Admin Party (everyone is an admin). When I first installed CouchBase Single Server, it was working, but I created a user and that turned Admin Party off. I've re-installed multiple times. Killed off everything I can find associated with couchbase, but every re-install retains the Admin Party off configuration, and remnants of my old database(s).
For reference:
Host: OS X 10.7.2
CouchBase Single Server Binary (not installed from source)
CouchBase SS Version: 1.2
I've tried blowing away the following:
/Applications/Couchbase\ Single\ Server.app/*
~/Library/Application\ Support/CouchbaseServer/*
but things must still be being stored elsewhere. lsof doesn't yield anything except for files in those locations and this:
/private/var/db/dyld/dyld_shared_cache_x86_64
Thanks!
UPDATE
Fixed this on my own. After more find/grepping for [Cc]ouch, i found the following files:
/Users/redacted/Library/Caches/com.couchbase.couchbase-server
/Users/redacted/Library/Caches/com.couchbase.couchbase-server/Cache.db
/Users/redacted/Library/Logs/Couchbase.log
/Users/redacted/Library/Logs/Couchbase.log.old
/Users/redacted/Library/Preferences/com.couchbase.couchbase-server.plist
/Users/redacted/Library/Preferences/com.couchbase.couchbase-server.plist.lockfile
/Users/redacted/Library/Preferences/couchbase-server.ini
/usr/local/Library/Formula/couchdb-lucene.rb
/usr/local/Library/Formula/couchdb.rb
Because I'm re-installing couch anyway, there is no reason for me to keep anything couch related. I blew all of these away, reinstalled and Admin Party was re-enabled. Somehow it still has record of my old DB names, but at least admin part is back in action.
Found a solution other than re-installing the server:
Remove (or move) ~/Library/Preferences/couchbase-server.ini
Then, finally, my Admin Party came back!
Search inside your CouchDB configuration files (local.ini, default.ini, local.d/*, ... usually under /etc/couchdb or similar) for the [admins] section and comment out all the users defined there (use ; character).
Restart your CouchDB server and you'll be back in Admin Party mode.

Resources