Transfer users to another replica server if main server goes down

#1

I am using Meteor server v1.8.

I want to create a backup server.

If Main server goes down, users should automatically transferred to a backup server, to avoid any down time.

How can I achieve such behaviour.

Thanks in advance.

#2

Interesting. There are 2 parts: Meteor (nodejs) and Mongodb.
Mongodb, you can create a replica set.
Meteor, install multiple Meteor instance on separated machines and use a load load balancing.
You will need 5 servers: 3 for Mongodb and 2 for Meteor. Maybe 1 more for load balancing.

btw, I’ve not done yet. Just read about that :slight_smile:

#3

Currently I just want to have 2 Meteor servers on same machine, as my server application is going down randomly here:

https://forums.meteor.com/t/meteor-server-is-going-down-randomly/47203/42

As I am still debugging the cause so I need to manage this server management setup as soon as possible.

#4

I think that you didn’t understand that @minhna said.

If you need replicate data, you need replicate you mongodb, not to have two installations only. You need replicate your data.

Are you using meteor to start your app in production ? If yes, it is not a goot idea. See here .

You need to install your Mongodb in each machine with replicaset enable. Thus, your data will be replicated.

For app, you need build your app and install as Node app. I use Phusion Passenger for deploy my apps, because it is easier to manage and others features that Passenger give me.

Other option is you use a PaaS as Galaxy, Scalingo or Nodechef to host your Meteor app, and a MongoDB hosting (Atlas, mLab, Compose, Scalegrid). This solutions are more expensive, but you don’t have any worry about scaling, failover and deploy.

If you need more helper, let me know.

2 Likes
#5

I think you need to install a mongodb instance in your server, your app processes will work with this database, not the one included in Meteor.
Then you create at least 2 Meteor processes, run on different ports.
You will need a load balancing, nginx may handle this.
They are all installed in 1 physical server.

#6

Yes you are right. But what is the purpose of replication of Mongodb? Performance or security? Also currently I cannot invest extra on Galaxy etc. Can i use custom deployment or Mup? Or do you strongly recommend phusion passenger for some reason?

#7

What if i want to put the second Meteor process on another server machine? Would nginx handle that from parent server?

I mean i am talking about the concept of Master and slave.

Master server will have mongodb and Meteor process. And slave server will only have Meteor process.

#8

If you host with AWS - use the elastic load balancer (Application Load Balancer) spin up a pair of t2.* instances based on your traffic needs. Roughly how many simultaneous connections are you getting? I’d stay away from the “master slave” concept for your application server. If you are completely certain you want that model, you can use AWS’s DNS failover routing with health checks.

I’d advise NOT running your meteor instances on the same server - it reduces your ability to tolerate OS or hardware level failures, depending on your servers specifications, one greedy meteor process might take down both of your processes (e.g., either processes memory or CPU consumption will affect the other).

For mongo, hosting a replicaset is for reliability - if you host a three member replica set, and one server goes down, you can continue to function fully. If two servers go down, you are reduced to read only. There is the potential for a performance improvement via reduced latency, as each of your application servers can be located in the same availability zone as a mongo server. This also reduces your intra region data usage, which reduces costs.

#9

Thanks for all the help, When you talk about mongodb replica set, does it mean Oplog?

#10

The oplog is mongo’s replication mechanism - a replica set are physical servers that store the data, a replica set must always consist of an odd number of members (to ensure a majority is always possible). If you are going to host this yourself, I’d recommend reading through the documentation VERY carefully, or hiring someone else to set it up for you - there are some gotchas. The alternate is using a service - this is good if you don’t have too much data, it can get quite expensive as your requirements increase.

#11

Replication/redundancy of MongoDB is for high available, performance, security, etc. See here.

You can use MUP to deploy your App, no problems, but you need install a mongodb separately, because I think that MUP not configure mongodb redundancy.

I think that if you want create a app resilient, you need have db redundancy with replication data.

#12

https://docs.mongodb.com/manual/replication/

#13

I use MUP for test environment only. For custom deploy, I prefer Phusion, is simple and resilient. But Phusion doesn’t be a deploy manager as MUP, Phusion is a web app server.

#14

Can I use MUP on local machine? Because first I need to deploy app on Local machine using MUP and then I will deploy on live.

#15

If your local machine is a linux flavor (Ubuntu 14 or 16 ) that supported by MUP, yes. If not, you can install a Virtual Machine to deploy tests.

#16

@hassansardarlecodeur, did you check the prices of scalingo.com ? They have all that you need for App and DB.

1 Like
#17

Thanks for all the help you are putting. I will check scalingo. But currently I need a simplest and quickest solution since my live meteor instance keeps going down again and again.

1 Like
#18

Scalingo is easiest. Do a trial, is very simples. It restart you app automaticly and send mail to you with log of error. It have Mongodb to. I think that you know-how is minor, the best option is put in a PaaS, as Scalingo.

#19

Run multiple node servers within a host (and across multiple hosts) and load balance them using nginx.

Have fun. Keep in mind the SSL stuff is optional.

1 Like
#20

For Mongodb replication you can follow this tutorial: