Is it possible to install a mongo db version greater than 3.2 on raspberry pi with RASPBIAN JESSIE LITE installed on the pi?
I only succeed to have the version 2.1 using this tutorial.
http://www.widriksson.com/install-mongodb-raspberrypi/
I tried a lot of tutorial but impossible to find one which work for greater versions.
As it was already written in the comments, you are limited to the 32-bit version.
Which comes with severe drawbacks:
The data which can be stored is less than 2Gb (potentially a lot less), since WiredTiger is not available and MMAPv1 is limited to a maximum file size of 2Gb since it makes heavy use of memory-mapping. It simply has a very limited addressable space on 32-bit machines
The WiredTiger storage engine is not available. It allows compression and hence would be especially interesting for limited resources.
MongoDB needs RAM. The more, the better. Indexes need it, connections need it desperately, and hm, the memory mapping makes good use of it. And well, we are only on 32bits. MongoDB Inc decided against creating workarounds for a dying technology. So do not expect this to change
The biggest drawback, however, is that journaling and replication are basically No-Gos since the further limit the amount of data you can store. No journaling translates to limited durability of your data (unless you are willing to force the data to be synced to disk for each write by using an according write concern), while the lack of replication and the resulting lack of failover capabilities most likely is less of a concern on a Raspi.
MongoDB Inc strongly advises against using the 32-bit version for other than testing purposes. And they do so for a good reason. Personally, my generated test data by far exceeds the limitations of the 32-bit version.
So yes, it should be technically possible (and even with no package at hand: compiling MongoDB is no rocket science). Is it a good idea? Well, not so much, if you ask me.
I am the author of the blog http://www.clarenceho.net/2015/12/building-mongodb-30x-for-arm-armv7l.html mentioned by #user3343399
Just to add that Arch Linux ARM latest build of MongoDB 3.2.0 seems to be working fine. Except that the default storage engine was compiled as WiredTiger although there is no 32-bit support from WiredTiger. You will need to add parameter --storageEngine=mmapv1
Related
Lately I have been experiencing general crashed as freezes, so I ran a MemTest86, which failed. Seems like there are a small portion of RAM that have faulty bits, which are likely the cause.
Is there some way to disable this region of memory either in BIOS or in the OS (Win10, currently)?
The firmware might technically support something to exclude faulty RAM; but if it does it's not working.
I don't think Windows supports anything to exclude faulty RAM.
Linux does supports this; if and only if the memory isn't used before the kernel sets up its memory management. The problem would be installing an OS when the installer will probably use the faulty memory.
If you can get Linux to work, then you can install Windows inside a virtual machine running on Linux. Of course then there's still no way to determine how long it's going to last before more RAM becomes faulty.
Mostly; the easiest and safest option is to replace the faulty RAM.
We have an app that uses the C# Mongodb client lib from mongo, version 1.1.0.4184
This code currently runs against mongodb 2.6.4
We would like to stand up a new mongodb server, the current version (3.2.11). Will our code run against newer mongodb?
It really depends what you mean by "will it run". The MongoDB v1.1.0.4184 C# driver was released in June, 2011 and dates to roughly the MongoDB 1.8 server release timeframe. This driver version is certainly no longer tested or supported, and will not be fully compatible with newer server features like the WiredTiger storage engine (default in MongoDB 3.2+) or SCRAM-SHA-1 authentication (default in MongoDB 3.0+).
The MongoDB documentation includes a reference table with recommended version(s) of the drivers for use with a specific version of MongoDB: C#/.NET Driver Compatibility.
If this is a production system I would strongly recommend taking the time to update and test a supported version of the C# driver for use with MongoDB 3.2 (eg. the v1.11 C# driver). I suspect it is very likely you will encounter fixed (or novel) bugs/behaviour using a driver that is more than five years old. Your application won't be able to take advantage of many of the newer server features, and this obsolete driver predates specifications such as standard Server Discovery and Monitoring (SDAM) behaviour.
That said, assuming you aren't using any features the driver isn't aware of your code may continue to run (or at least appear to run) successfully. In my opinion doing so is a high risk deployment strategy.
Yes, i am using it, but however we have to chek on specific features, which you were using. using MongoDB latest driver is much better in terms of latest features and there are few features were removed(like 'eval()').
I've got two PostgreSQL 9.2.4 servers running on 32-bit Suse.
Failover is configured using a shared storage device.
I'd like to upgrade to 64-bit Ubuntu machines using PostgreSQL's streaming replication while keeping the database service available. To do that would mean temporarily having failover between a 32-bit and 64-bit system.
I've read a lot of documentation for PostgreSQL & PostgreSQL replication.
It's clear that PostgreSQL doesn't handle streaming replication between 32 & 64 bit systems. It's not as clear if it can handle shared storage between 32 & 64 bit systems. I'm pessimistic, but wanted to check.
Yes, you can - with the caveat that you must use a 32-bit PostgreSQL build on your 64-bit system, it must be the same major release (e.g. both 9.2 or both 9.3) and it must be compiled with the same settings for integer_datetimes etc.
Modern Debian/Ubuntu, like all 64-bit Red Hat variants, supports a multi-arch install where 32-bit and 64-bit binaries can live side by side. So you should be able to simply apt-get install the 32-bit PostgreSQL on your 64-bit system.
That said, I strongly suggest relying on streaming replication instead. Shared-storage failover is very risky - if you have any problems with fencing access and STONITH, you will get extremely severe data corruption. It also protects against fewer classes of problems.
Actually, it's even possible that 32-bit Suse's version of PostgreSQL and 32-bit Ubuntu's aren't compatible. Not likely, but it depends on what options they chose during compilation.
So - no.
If you really want to have complete availability you'll need to look at one of the trigger-based replication systems (slony / londiste / bucardo). These can replicate between different installations of PostgreSQL regardless of on-disk format.
Of course, this means having two sets of data.
It does allow you for an uninterrupted upgrade though, so you can consider switching to the latest 9.3 at the same time.
Has anyone had any success running mongodb on the beaglebone black? do I have to install a different flavor of linux to get this to work or can I use angstrom.
MongoDB (as at 2.4) does not officially support ARM processors. You can watch/upvote SERVER-1811 in the issue tracker, however I wouldn't expect this to get much traction until there are 64-bit server-class ARM processors commonly available.
In general a 32-bit low power ARM processor with limited memory (512Mb RAM on the BeagleBone Black) is not a great fit for a memory-mapped database server like MongoDB. Due to the use of memory-mapped files, 32-bit versions of MongoDB are also limited to about 2GB of data and indexes.
There are some extremely old versions of MongoDB that have been hacked to work on ARM to some extent (eg: MongoDB 2.1.1-pre), which is a very early development release of MongoDB 2.2. I wouldn't recommend this unless you're extremely desperate; likely you will spend far more time trying to get things working than writing productive code.
Better approaches would be to either:
use a database which is designed for lightweight environments (eg. SQLite)
use your BeagleBone to run a MongoDB client application rather than a server
I've done some research and it seems to imply that at least in 2011, the big endian/little endian problem prevented this since PPC cores were not compatible with the MongoDB server.
Has this changed? Or is it still impossible to get it running on an IBMi?
I'm confused since Zend seems to be supporting MongoDB now and is a major part of a web framework on an IBMi server.
It appears that using mongodb entirely on the IBMi is out of the question, is there a reliable NoSQL alternative with collections that would work? Perhaps one with a SAVF or RPM so it works out of the box?
The MongoDB core server is little endian.
What you can do is have the drivers on the IBMi, as most of them are big endian, and the Mongo DB core servers on a little endian machine (AMD64 or Intel x86_64)