Replication

One thing that can facilitate highly available networks and services is replication.

In short, replication is just a duplicate of something. So we're taking data and we're making a duplication of it. But not just that — we're actually probably doing it consistently. So whatever is happening to this data over here, we're updating this data at the same time.

A database is a great example of this. One database is going to mimic another database, and one of the ways that we do this is through transaction logs. Transactions are something that gets executed on a database. This is like a set of instructions that say, this data is going to change, and it gets executed on that database. We just do that to both databases to make sure both databases are up to date at any given time.

Replication Is Not a Backup

When we take a backup, it still is a copy of something, but it's a copy in a moment of time. We can actually take this and use it by doing a restore later on. Versus, if we have something that gets executed wrong on this database and it's being replicated, there's potential — probably — that it's going to happen on both databases. So both databases can be corrupted at the same time. This is where we would need something like backup.

A lot of times we like to replicate things to a whole other site so that way, if we need to turn it up, it can be brought up and running. So what does that look like? Here we have a bank of database servers that are being replicated right there. Not only that, but it's being replicated to a hot site as well, so there's a duplicate over there. If we need to fail over, all of that information is live.

This is much different than a backup copy. A backup copy — this is a warm site right here, where maybe we have the servers running and ready to go, we just don't have the database fully functioning. So what happens is we take a backup copy of these databases, we replicate that over to the other site, and then once we need to bring this site live we would do a restore, bringing it up and running. There are some costs to be saved if we do it this way.

What Can Be Replicated

I've been giving the example of databases, but we can also have files and folders. Microsoft has a way that we can set up shares and then replicate it to another site, and it works actually pretty well. Then we also have servers — maybe we replicate whole servers so we have a copy of a server somewhere else, or maybe we're just doing the configurations of those servers or of an application and replicating those, so we have a copy of that over there.

A lot of times we do directory services. I'm thinking of something like Active Directory, where we have a bunch of usernames and passwords at one location and we want to replicate that information to another location, so those people at the other site that are using Active Directory can log in as well using a local server.

There are a lot of different levels we can replicate this at. I mentioned the server, but we could also do it at the disk or the volume or folder or file level. So we just choose what we want to have replicated. Same thing, we could have databases replicated over.

Synchronous and Asynchronous

There is also something called synchronous and asynchronous, and one example of this is databases. I talked about the transaction logs and how they get executed on this database and it happens on both of these databases. If we were to say that this was synchronous, what would have to happen for this to be entered in on this database right here? It needs to be copied over first, and then they get executed onto the database at the same time. This makes it synchronous, so there's no chance that this database gets off or different from this database. The disadvantage is that this copying or replicating over to the other site could take a while. If there's some sort of delay, then this doesn't get executed onto the database in a time-efficient manner, and sometimes that can be very problematic.

Now let's look at asynchronous. Asynchronous solves this problem, because what happens with asynchronous is that the transaction on this site will get executed first and then it will send it over to the other site and get applied whenever it can over on the other site. This is great because it doesn't slow down this process and cause any issues with this being delayed being executed on this database over at site one. But the problem is that if this never makes it over to the second site, now the databases get off and the databases can be different. So there's advantages and disadvantages to the synchronous and asynchronous replication that's happening here.

Unidirectional and Bidirectional

There's also bidirectional replication. If it's just unidirectional, what's happening is whatever gets changed over here on this side will then be replicated over to the other side. Nothing can really change on this side, so it's just a replica of this over here. We see this with like databases where we have a read-only copy. We can read this copy over here, but only changes can happen to one side, one database.

Bidirectional just means that we can have changes in both locations at the same time. A lot of file services will try to do this, although there can be problems with this if somebody's trying to make some changes on one document and then somebody is on another document. A great example of this would be like Google Docs. With Google Docs, people can make changes to both sides at any given time and it works great. But then you've got something like Microsoft OneDrive, which is much better now, but at one point in time it really struggled with these bidirectional changes.

That's where, in the past or even now, we do have something called file locking. That is that when one file is being edited it gets locked, and so the other one cannot be edited at the same time. Then once this has been saved, it will make changes to both documents, it will unlock the documents, and now either document can be changed. So that's one thing that file locking can do: make sure that there's not discrepancies between these two versions, these two replicas.

There are times when I'm using something like Dropbox where two files were being edited at the same time, and it usually handles that pretty well. Although there's been times when there's been conflicts that have happened, and then I will get an extra copy of something in there — it'll actually say conflict on it. What has happened is those two files were edited at the same time, and now we end up with two copies of it because there's two branches from there.

Replicating Disks

We can even replicate disks, and this has also some advantages over RAID. When we're doing RAID configuration, it's replicating a disk, and this is great because if one of the disks goes down, immediately we're still up and running. Actually, it never goes down, because we have a duplicate copy of this, so there is never any downtime. But the problem with this is we can't go any kind of distances with this, where with disk replication we can actually replicate across to a whole other site and then we can bring that whole server up and running and live at the other site. Of course, it might not be instantaneous in that example.