How do I upgrade from mongo version 2 to version 3 ?
I am trying to upgrade from mongo 2.x.x to the latest version (which at the time is 3.2.x).
The official (3.2 upgrade) instructions say I need to go to version 3.0.x first and so that is all i'm trying to achieve right now - to get from version 2 to version 3.
First try : apt-get
I first tried using apt-get, following these instructions (linked to from this page, which was linked to from these official (3.0 upgrade) instructions).
That all appeared to work alright, however my version ($ mongo --version) number didn't change, so no upgrade actually happened at all.
Second try : mongod-10gen
I then found these instructions and followed them.
This time, again, every step was successful but the end result was that my version has now gone down! (from 2.6.1 to 2.4.14)
I've also tried following the instructions in this SO answer, which are essentially the same as the other instructions - and gave the same result - success on every step, but the final result is still a v2 mongo.
Third try : copy the binaries
The official (3.0 upgrade) instructions actually first suggest downloading and copying over the binaries (but I tried the auto install instructions first because that seemed easier).
My binaries are all actually directly in /usr/bin/.
Get the url for the binaries for your system (for the curl command below) from the download binaries page.
(For me it was for Ubuntu 14, for previous release, v3.0.14)
Then download the binaries, and copy them directly into /usr/bin/.
Like so:
$ curl https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu1404-3.0.14.tgz -o mongo_3.0.14.tgz
$ tar -xvf mongo_3.0.14.tgz
$ sudo service mongod stop # stop DB
$ sudo cp mongodb-linux-x86_64-ubuntu1404-3.0.14/bin/* /usr/bin
$ sudo service mongod start # and restart
$ mongo --version
MongoDB shell version: 3.0.14
Success!!
So, the correct approach was to follow the initial instructions - however it was not obvious to me what "copy the binaries" meant at first, and the alternative auto install with apt-get I really thought would be the simple and right way to go (why doesn't that work??) - I suspect others will come across this problem so I will put this third try as an answer and still post the question
Related
Good evening people, I am trying to install pgadmin4 on fedora 36, I followed all the steps in the documentation and pgadmin4 and its dependencies were installed correctly but I do not know how to start it, or open it and it does not let me configure it on the web because I do not create the directory described in the final step to configure the web version.
I had the same problem. I solved it installing pgadmin4 from linux-pachages
https://linux-packages.com/fedora-36/package/pgadmin4-qtx86-64
I followed the same instructions but mistakenly changing "yum" to "dnf" out of force of habit. I found I got an install out of it which seemed OK at a glance, but it was just documentation and not an executable, and there was no shortcut added to run pgAdmin. Perhaps you might have inadvertently done something similar? After uninstalling, I tried again using "yum" exactly as documented and the latest executable installed without any issue. So the steps to install that would work for me were as follows. (Desktop version in my case.)
sudo rpm -e pgadmin4-fedora-repo
sudo rpm -i https://ftp.postgresql.org/pub/pgadmin/pgadmin4/yum/pgadmin4-fedora-repo-2-1.noarch.rpm
sudo yum install pgadmin4-desktop
The QT workaround also mentioned as an answer worked for me, but I wanted to avoid that since it is an earlier release (6.9) than the current 6.11, isn't officially supported and fires a warning about that every time on start up saying some functionality may be missing, which is not good for clients to see potentially in my case.
Same problem - couldn't open it after installing. You have to install pgadmin4-desktop not pgadmin4.
I run a MongoDB replica set in a containerization environment orchestrated by Rancher.
After rolling out the latest update, MongoDB as been upgraded from 3.6.x to 4.0.x (latest).
No upgrade path has been followed and, as a result, when trying to bind the volume holding the database storage, the service fails to start, exiting with the following exception:
STORAGE [initandlisten] exception in initAndListen: MustDowngrade: Collection does not have UUID in KVCatalog. Collection: admin.system.version, terminating
I get the same outcome even attempting to launch mongod with the --repair option.
I have also tried to rollback the container to MongoDB 3.6.16, but the journal version is now incompatible.
We don't have snapshots of the volume, hence restoring the data is not an option (this is not a production environment). The only solution I've found online is not applicable, since it suggests to leverage mongodump and mongorestore, requiring a running database with the data storage attached.
I'm running out of ideas, any advice about how to fix this?
A bug report on this issue recommended following the full upgrade path and that worked for me. I was able to go back to my old version when I ran into this error, and then upgrade properly.
Specifically: upgrade just one major version at a time and check the prerequisites and upgrade steps carefully. The most important part of this is checking your compatibility with db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) and make sure it matches the current version before upgrading to the next version. Update it with command like db.adminCommand( { setFeatureCompatibilityVersion: "3.6" } )
Read the full docs at pages like https://docs.mongodb.com/manual/release-notes/3.6/#upgrade-procedures https://docs.mongodb.com/manual/release-notes/4.0/#upgrade-procedures etc
I was updating MongoDB from 3.6 to 4.2 with Homebrew on Mac OS, and ran into this similar situation.
Since formula mongodb was removed from homebrew-core, the team of mongodb maintained a custom Homebrew tap.
Following steps is my solution for upgrading MongoDB from 3.6 to 4.2 with Homebrew:
Uninstall old version mongodb from Homebrew
# If you run mongodb in background service, stop it first.
brew services stop mongodb
# If you have multiple version of mongodb, you might need to add `--force` option for deleting all of them at once.
brew uninstall mongodb
Install new mongodb from custom Homebrew tap
brew tap mongodb/brew
brew install mongodb-community#3.6
Add mongodb-community#3.6 to your PATH
echo 'export PATH="/usr/local/opt/mongodb-community#3.6/bin:$PATH"' >> ~/.bash_profile
Restart your terminal, and run mongod
Open another tab or terminal windows to run mongodump
Terminate mongod
Uninstall mongodb-community#3.6 and reinstall mongodb-community
brew uninstall mongodb-community#3.6
brew install mongodb-community
Delete old data with old mongo data structure
rm -rf /data/db/*
Run mongod
Open another tab or terminal windows to run mongorestore dump/
Once mongorestore completed, mongod will be terminated.
And you can run mongodb as a background service or just run mongod again. Open MongoDB with mongo or Robo 3T(formerly Robomongo), you will see your data is good as usual.
Hope it helps.
Alright after about 3hours of trying to fix exactly what you are describing, here are the steps I took. Here I will show how to retain the data while downgrading to 3.6 and also how to update it 4.0 with the retained data.
The reason this happens for mac users is because there was an update for people using brew can no longer download Mongodb directly from brew. Then people tend to download the newer community edition instead from brew which then gets in conflict the old version of 3.6 db folder still present in the directory. Instead you would need to download it from the actual mongodb website:
https://www.mongodb.com/download-center/community
Here what you would want to do, is download everything manually. Follow these instructions here, but do this with the 3.6 version:
https://medium.com/#saurabhkumar_4718/install-mongodb-without-homebrew-on-mac-os-2a98b68ab09c
NOTE: when you copy .bash_profile please make sure export commands are not
Once you have successfully installed 3.6 manually you can mongodump to be safe, and or export all your mongo data into json with mongoexport for any data that you must really really save.
After that you can fresh install 4.0 manually again by following exactly the same steps as previously done for 3.6
This worked for me without having to do any 'mongorestore' as the 'db' folder was left alone and all my data was there, but maybe extra steps might be needed to restore the data. Worst comes to worst you have .jsons that needs to be rewritten. 'mongo --version' also showed the right version :) Hope it helps
Backing-up all the databases (using mongodump)
Removing every file in /data/db, due to their incompatibility with the newer version: rm -rf /data/db/*
Restarting the MongoDB service by mongod
Restoring all the databases (using mongorestore)
https://dba.stackexchange.com/a/252393
For Docker:
I had this issue when I was upgrading a project that used Docker from 3.6 to 4.2 (and 4.4).
The way the project is set up means I don't have a physical /data/db directory to purge.
However, there is a volume defined that acts as the /data/db directory.
In this case all you need to do is backup any data you need and remove the associated volume.
If using vs code with the docker extension, you can simply open your docker tab in the sidebar, expand the volumes section, locate the volume in question (for me it was called mongo-4-2-upgrade-test_mongo-data which depends on how your various containers are named for your project), right-click and remove.
Ensure that the containers that use this volume have been properly shut down or you'll get a 409 conflict error. I did the same as above but found my mongo container (in the containers section of the docker tab) instead. then when I restarted my docker-compose file the new version of mongo was installed and ran as expected.
I'm running Centos 6.7 on my server and am trying to install Erlang/Rabbitmq following these instructions:
Erlang Installation
RabbitMQ Installation
The trouble is that at time of writing these install Erlang 19.0 with RabbitMQ 3.6.3, which leads to a pretty major bug as far as my client who occasionally looks at the management interface to monitor queues is concerned.
The guidance in the error ticket is not to use erlang 19 until RabbitMQ 3.6.4 is released. But how can I install a specific version of Erlang?
These steps worked for me:
Go to the download page here: https://packages.erlang-solutions.com/erlang/
Select your appropriate package -- you can copy/peek the link then download it using wget.
Install it using rpm.
Example:
# Download erlang 19
$ wget http://packages.erlang-solutions.com/site/esl/esl-erlang/FLAVOUR_1_general/esl-erlang_19.0~centos~7_amd64.rpm
# Install
rpm -Uvh esl-erlang_19.0~centos~7_amd64.rpm
You can always build install from source.
Go to the Erlang.org Downloads page, pick your version from the right side.
From there you can follow the instructions. Although they are for Ubuntu, the commands are the same except for the dependencies part where you can use the command below to install what you need:
sudo yum install g++ openssl-devel unixodbc-devel autoconf ncurses-devel
Another option would be to use kerl, which is similar to rvm in some sense and very (very!) easy to use. It will let you install different Erlang versions and switch between them any time you want.
I prefer this approach instead of looking up packages myself (with possible incompatibilities in the dependencies required) or downloading and compiling everything myself every time I want to try a new Erlang version.
I am new to Linux and I found it really difficult to install older version of postgresql (along with postgis). I have uninstalled everything I could find connected to postgresql in aptidude. As only the newest version is available through apt-get install, I have went through several tutorials how to get 9.1 installed.
Example: https://wiki.postgresql.org/wiki/Apt (with 9.1 at the end, not 9.3)
After I was done with this tutorial, pgAdmin III is still showing 9.3 as version.
What's the correct way to dump 9.3 and install 9.1 as well as postgis 1.5?
I am using Mint 17
Okay. First off it is perfectly fine to run multiple versions of postgresql alongside one another. You can have more than one cluster on a box, and each cluster can run different versions. The debian pacakges are very well designed to make this easy to do.
However since you've indicated you're a newby to linux/postgresql it's probably best to get 9.3 completely cleaned from your system to avoid frustrating hiccups which will take you a long time to figure out.
To do this you need to:
Purge all postgresql 9.3 packages from dpkg
Manually delete any 9.3 data and configuration for 9.3 cluster
Make sure you've created a 9.1 cluster
Step 1 – purge DPKG
DPKG manages the packages on your system. APT acts as a mechanism for getting packages to install. A lot of DPKG functionality is available through apt, but some things are just easier on dpkg. In your comments you've shown that DPKG is still showing remnants of 9.3. When you uninstall a package some parts of it may hang around (such as configuration files). You can remove multiple packages in one command. To get rid of these completely you can tell dpkg to purge them dpkg --purge <package name>. You can remove multiple packages in one command and it's best to do so.
dpkg --list will list everything on your system. dpkg --list | grep postgresql searches this list for postgresql.
Step 2 – Manually delete data and configuration from the old 9.3 cluster.
When you first install postgresql it creates a cluster for you; no questions asked. This trips up a lot of new users because they neither knew that it happened nor how to replace it. Now that 9.3 is uninstalled you can go ahead and simply delete the configuration and data:
If there was anything you wanted to keep in the installed 9.3 database DO NOT run the following commands
sudo rm -rf /etc/postgresql/9.3 Removes the configuration.
sudo rm -rf /var/lib/postgresql/9.3 Removes the data.
Step 3 – Create a new cluster
You've indicated in comments that postgresql 9.1 is installed. Before you run this command it's worth reading the manual. man pg_createcluster.
sudo pg_createcluster 9.1 <think up a name>
Now you should be able to start up postgresql sudo service postgresql start
Edit
If pg_config is still listing the incorrect version then... this can be a result of remnants of 9.3 still left on your system. This may not be a problem. To allow multiple versions to run along side one another pg_config is a wrapper script which searches for the latest (highest version) of /usr/lib/postgresql/*/bin/pg_config. So what you're seeing is the result of running /usr/lib/postgresql/9.3/bin/pg_config. If 9.3 is completely cleaned from your system then /usr/lib/postgresql/9.3 should have gone.
If you want to see the configuration of 9.1 then try running:
/usr/lib/postgresql/9.1/bin/pg_config.
The wrapper scripts which starts the server will use the file structure of /etc/postgresql and use the apropriate version. So /etc/postgresql/9.1/main will startup version as 9.1.
How can I get PDO to work on my mac (os x 10.5)? I'm using the built in php and php in Zend/Eclipse. Can't seem to find useful drivers for it at all.
I had to install the PDO_PGSQL driver recently on Leopard, and I ran across a multitude of problems. In my search for answers, I stumbled across this question. Now I have it successfully installed, and so, even though this question is quite old, I hope that what I've found can help others (like myself) who will undoubtedly run into similar problems.
The first thing you'll need to do is install PEAR, if you haven't done so already, since it doesn't come installed on Leopard by default.
Once you do that, use the PECL installer to download the PDO_PGSQL package:
$ pecl download pdo_pgsql
$ tar xzf PDO_PGSQL-1.0.2.tgz
(Note: you may have to run pecl as the superuser, i.e. sudo pecl.)
After that, since the PECL installer can't install the extension directly, you'll need to build and install it yourself:
$ cd PDO_PGSQL-1.0.2
$ phpize
$ ./configure --with-pdo-pgsql=/path/to/your/PostgreSQL/installation
$ make && sudo make install
If all goes well, you should have a file called "pdo_pgsql.so" sitting in a directory that should look something like "/usr/lib/php/extensions/no-debug-non-zts-20060613/" (the PECL installation should have outputted the directory it installed the extension to).
To finalize the installation, you'll need to edit your php.ini file. Find the section labeled "Dynamic Extensions", and underneath the list of (probably commented out) extensions, add this line:
extension=pdo_pgsql.so
Now, assuming this is the first time you've installed PHP extensions, there are two additional steps you need to take in order to get this working. First, in php.ini, find the extension_dir directive (under "Paths and Directories"), and change it to the directory that the pdo_pgsql.so file was installed in. For example, my extension_dir directive looks like:
extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20060613"
The second step, if you're on a 64-bit Intel Mac, involves making Apache run in 32-bit mode. (If there's a better strategy, I'd like to know, but for now, this is the best I could find.) In order to do this, edit the property list file located at /System/Library/LaunchDaemons/org.apache.httpd.plist. Find these two lines:
<key>ProgramArguments</key>
<array>
Under them, add these three lines:
<string>arch</string>
<string>-arch</string>
<string>i386</string>
Now, just restart Apache, and PDO_PGSQL will be up and running.
Take a look at this PECL package: PDO_PGSQL
I haven't tried it myself, but I've been interested in playing with Postgres as an alternative to MySQL. If I have a chance to try it soon, I'll throw my results up here in case it helps.
I'm not sure this will help with the PDO drivers specifically, but you might look into BitNami's MAPPStack.
I had a ton of trouble with Postgres, PHP, and Apache on my Mac, some of it having to do with 64- vs 32-bit versions of some or all of them. So far, the BitNami MAPPStack install is working nicely in general. Maybe it will help with your PDO issues as well.
Install new php version via brew and restart server, and php -v, all issues are removed.
This is what worked for me
brew install php55-pdo-pgsql
This installs PHP 5.5.32 and PostgreSQL 9.5. I already had PostgreSQL 9.4 installed so I uninstalled the homebrew version with:
brew uninstall postgres
You then have to update /etc/apache2/httpd.conf to point to the correct PHP version and restart Apache:
LoadModule php5_module /usr/local/Cellar/php55/5.5.32/libexec/apache2/libphp5.so
My OSX version is Yosemite.