So the first thing we're going to discuss is master back up replication, sometimes called master stand
by replication.
And the idea here is you have one leader digging a base node that accepts rights and except grill operations
such as create table or alternative database stuff that you change in the database, create a new database
right versus right, where you're inserting Neuros in a table or updating in your arrow or deleting
rows.
These are called DM's.
So you do all your rights in one master node and there will be a lot of read only stand by Oracle back
up nodes which will receive those rights from the master node.
So that's the idea.
You don't write to those notes yourself as a client.
You always write to the master and the master replicates the data to the standby notes the beautiful.
This is like it's very simple to implement because you don't have conflicts is as one node that takes
rights and that's at nobody else is going to to have rights as well.
Right in the same time.
So here's how it looks like.
So this is the red one is the master node and the green ones are the stand-by replica nodes.
And if I want to insert or update or even create a new table or even to create a database or do anything,
I always do it to the master of the red database instance and that the act of doing that will propagate
those right to the back and nodes because there is a TCP connection between the replica node and the
master node that is like full bidirectional ready with a specific database user as well.
And this is the same thing here.
So anything you do here, this master node will push it to the child nodes or they call stand by nodes.
And and so that's that's beautiful.
So you want to have questions like Hosain does.
Does the client have to wait for these changes to be pushed to the back end or does it immediately if
it's written to the master?
Can I just immediately get back at once?
It's written to the writer said, look, this is another kind of debate and discussion and people are
already doing PhDs.
And what is best this is called synchronous versus asynchronous one I'm going to talk about in the other
room.
So in master backup or application, the beauty of this, if you're doing a read, you can either do
a read against the master.
You're going to get the fresh Aldo's up to date data, but you can always read against the replicas
again, the standby data.
That's absolutely fine.
You can read against those, but you cannot try to those.
The beauty of this is like if this is in a region, a specific region in Asia and this is in a specific
region in Europe and this is in America, you can still do that.
Yeah, the propagation will take time.
But if you if you can take the hit on this consistency, the eventual consistency, and that's what
the model is.
Yes, relational database is half eventual consistency, not just no sequel.
This is a relational database model, yet it has eventual distances.
So those clients will see that that might see the updates a little bit later.
If you can live with that, that's fine.
If you don't, there are ways to solve those, obviously.
But that's the idea here.
So you can you can scale horizontally.
And that's a beautiful this.