Now with capped collections out of the way, let's turn towards replica sets. Replica sets are something you
would create and manage as a database or system administrator
but what are replica sets?
Let's say we have our client, either the mongo shell we're using or some native driver for Node, PHP, C++,
whatever it is. Now we want to write some data to our database and hence we send our write,
our insert operation to the mongodb server which in the end talks to the primary node you could
say. Now important is a node here simply is a mongodb server,
so what we use thus far with this mongod command gave us a node, the only node we had.
So the mongodb server is technically attached to that node but it's a bit easier to understand it like
this, I believe. So we have that primary node and that is basically the setup we used for this entire
course, we have our server which is one node.
Now you can add more nodes, so-called secondary nodes,
so these are additional database servers
you could say you start up
which are all tied together though in a so-called replica set.
Now the idea here is that you always communicate with your primary node automatically,
you don't need to do that manually, this happens automatically, if you send an insert command to your
connected mongo server,
it will automatically talk to the primary node but behind the scenes, the primary node will asynchronously
replicate the data on the secondary nodes and asynchronously simply means that if you insert data, it's
not immediately written to the secondary nodes but relatively soon.
So you have this replication of data,
now why do we replicate data?
Well we do replicate data
so that in this set up here,
that if we read data and for some reason, our primary node should be offline, that we can reach out to
a secondary node that will be then the elected new primary node, the secondary nodes in a replica set hold
a so-called election when the primary node goes down to elect and select a new primary node
and then we talk to that new primary node until our entire replica set is restored.
So we get some fault tolerance in here because even if one of our servers you could say goes down, we can
talk to another instance another node in that server network, in that cluster so to say to still read data
and as a new primary, we can then also not just to read but also write data.
So this is why we use replica sets, we have the back up and fault tolerance and we get better read performance
as well and
that is something I haven't talked about yet,
we talked about the backup of data and therefore, the possibility to read data and also then to write
to a new primary,
well if we have this set up, this is of course fine if the primary node is online but even if it does
not go offline, you can configure everything such that your backend will automatically distribute incoming
read requests across all nodes and now we're talking just about read requests.
The writes will always go to the primary node but read requests can be if the server is configured appropriately
and that is a task of your system or database admin and that the reads can also talk to secondary nodes
and the idea here is of course clear. You want to ensure that you can read your data as fast as possible
and if you have an application where you have thousands of read requests per second, then it is awesome
if you can read not just from one node which is still one computer who has to handle all of that but if you
can read from multiple computers and therefore, you kind of split the load evenly.
So that's the idea behind replica sets,
we get the backup, the fault tolerance
and we can even use the nodes and the replica set for improved read performance.
Now how do you create such a replica set? Again
this is an administrative task, we'll not go through that in this course since it's well a bit more advanced,
not really something you'll have to worry about as a developer but when we deploy a mongodb
solution.
I will also show you a way of easily getting such a replica set up and running,
so there I will cover that too.