tokumx and mongodb are incompatible; you couldn't build a mixed replica-set because they had different storage engines and spoke different replication languages. But PSMDB seems to have closed this gap (with pluggable storage engines, at least, which can allow wiredTiger). Does this mean they can now also be mixed (i.e. have the differences in replication-language also been rectified?) I ask because I've got a very old tokumx system with important data on it and MUST bring it into a mongodb cluster, but there seems to be no simple way to do this. If I can migrate tokumx->PSMDB->mongodb, that would be fantastic! Any help would be appreciated!
I've got a very old tokumx system with important data on it and MUST bring it into a mongodb cluster, but there seems to be no simple way to do this.
TokuMX's replication protocol is not compatible with MongoDB or Percona servers, so migrating from TokuMX will unfortunately require dumping and restoring your data. Outside of replication, there are also some incompatible TokuMX index options to remove before restoring into MongoDB.
See Migrate from TokuMX to Percona Server for migration approaches & scripts to help with this.
If I can migrate tokumx->PSMDB->mongodb, that would be fantastic!
If your goal is to migrate to MongoDB Community or Enterprise edition, an intermediate migration via PSMDB will not provide any benefit. PSMDB uses replication code from the upstream MongoDB community server, but does not provide any special migration path from TokuMX.
Related
Is it possible, and if so how, to use an Azure MongoDB as the backend for my Meteor Application.
I have added the connection string from my database into the MONGO_URL variable with no success. I have found some previous threads over Stack Overflow and on here about incompatibility related to oplog errors, but they seem to be using DocumentDB instead of Azure's MongoDB (which I think is newer than a few years ago).
In your example, you're actually using DocumentDB with MongoDB compatibility. You're not using native MongoDB (nor is this native MongoDB as-a-service).
DocumentDB (even with MongoDB compat) does not provide an oplog. And since Meteor has a dependency on reading the oplog, you wouldn't be able to point Meteor at DocumentDB.
In your case, you'd need to either run native MongoDB on your own (e.g. in VMs) or take advantage of a 3rd-party MongoDB hosting solution which provides MongoDB support within the same region as your app. (ok, yes, you can run your app in a different region, but you'd see latency along with data egress charges).
I have a mongo 2.4.8 database setup and running in a live environment. I am wanting to add a replica however I would like to use the latest version 3.2.9 for the replica.
Is the only way for me to do this to upgrade the current node to version 3.2.9 then add the replica?
My plan would be sync all the data to the new node make it primary then update the old node to the latest version is this possible?
yes, you can create a new node and make a replica, and update the old node.
few things to keep in mind are:-
The default storage engine for 3.2.9 will be wiredtiger and for 2.4.8 it will be mmapv1, so you would have to change the configuration so that you can keep on using mmapv1 as your storage engine.
Do replication very carefully. if not done properly, there are chances that the whole database is blown. i recommend you to take the backup of the database before doing replication
I would definitely go with the first method that you mentioned. Upgrade the current stand alone database and then create a replica set. I tried to find the best practice from Mongodb, but I couldn't find an answer. So, I asked Adam ex employee of MongoDB and creator M202 course to find his opinion.
Source: Adam, ex employee of Mongodb
I have gone with the route of a full mongo backup then restore into the new nodes.
The replication old to new was very fragile plus the backup is very fast to do as long as you allowed to bring the server down.
MonogDB's dynamic schema design is driving me towards it to replace MySQL in a production site. But this project runs on only 1 dedicated server (with 2 hard drives).
Docs about "MongoDB for production" recommends multiple servers. This makes me wonder if MongoDB is only suited for large commercial projects?
Anyways... I am wondering if the live database data can be replicated to the second hard drive for backup & recovery (to recover from corrupt data due to hard stop).
Any thoughts against the use of MongoDB in a single server environment is also appreciated. In this project, the biggest database will be less than 7GB.
Thanks
I want to create a database replication, like a Master/Slave Databases for my play 1.2.4 framework app. I'm using PostgreSQL. Any guidance in this regard would be highly appreciated
You could use the native replication from PostgreSQL (available as of version 9.0), works fine. repmgr makes things easier to setup and maintain, also for automatic failover.
PostgreSQL supports asynchronous replication (as of 9.0) and synchronous replication (as of 9.1).
Since you mention Play 1.2, you may be using the default in-memory H2 database that comes with it and want to replicate data to PostgreSQL. In any case, take a look at SymmetricDS an open-source database replication engine that supports most databases, including H2 and PostgreSQL. It supports master/slave and also multi-master with conflict management. It is asynchronous replication that can work across a WAN, so it won't slow down your application if the network is slow or intermittent. Since it supports replication between different database systems, you can change your platform in the future if needed.
Is MongoDB for Azure production ready ?
Can anyone share some experience with it ?
Looks like comfort is missing for using it for prod.
What do you think ?
Edit: Since there is a misunderstanding in my question i will try to redefine it.
The information i look into from the community is sharing an info of someone who is running mongo on windows azure to share experience from it.
What i mean by experience is not how to run it in the cloud(we already have the manual on 10gens faq) nor how many bugs it have(we can see that in mongo-azure jira).
What i am looking for is that how it is going with performance ?
Are there any problems(side effects) from running mongodb on azure ?
How does mongodb handle VM recycling ?
Does anyone tried sharding ?
In the end, is the mongo-azure worker role from 10gens stable for using it in production ?
Hope this clears out.
A bit of clarification here. MongoDB itself is production-ready. And MongoDB works just fine in Windows Azure, as long as you set up the scaffolding to get it to work in the environment. This typically entails setting up an Azure Drive, to give you durable storage. Alternatively, using a replicaset, you effectively have eventual consistency across the set members. Then, you could consider going with a standalone (or standalone with hot standby). Personally, I prefer a replicaset model, and that's typical guidance for production MongoDB systems.
As far as 10gen's support for Windows Azure: While the page #SyntaxC4 points to does clarify the wrapper is in a preview state, note that the wrapper is the scaffolding code that launches MongoDB. This scaffolding was initially released in December 2011, and has had a few tweaks since then. It uses the production MongoDB bits (and works just fine with version 2.0.5 which was published on May 9). One caveat is that the MongoDB replicaset roles are deployed alongside your application's roles, since the client app needs visibility to all replica set nodes (to properly build the set). To avoid this limitation, you'd need to run mongos and the entry point (and that's not part of 10gen's scaffolding solution).
Forgetting the preview scaffolding a moment: I have customers running MongoDB in production, with custom scaffolding. One of them is running a rather large deployment, with multiple shards, using a replicaset per shard.
So... does it work in Windows Azure? Yes. Should you take advantage of 10gen's supplied scaffolding? If you're just looking for a simple way to launch a replicaset, I think it's fine. If you want a standalone model, or a shard model, or if you need a separate deployment for MongoDB, you'd currently need to do this on your own (or modify the project 10gen published).
MongoLab is now offering Mongo as a service on Azure MongoLab Blog
Free Demo account is 0.5 GB storage are available in the Windows Azure Store
The warning message on their site says that it's a preview. This would mean that there would be no support for it at a product level in Windows Azure.
If you want to form your own opinion on a comfort level, you can take a look at their bug tracking system and get a feeling for what people are currently reporting as issues.