Data replication creates and continuously maintains synchronized copies of data across multiple locations, providing the redundancy required for high availability and rapid failover. Key concepts include synchronous versus asynchronous replication, bidirectional replication, and file locking.
Data Replication
To create high availability on our networks we need redundancy, and that includes redundancy with our data. Replication helps answer the question of how we are going to create redundancy with our data.
Replication is essentially copying the data. However, it's a little more in-depth than that, otherwise we'd just call it copying. Replication continues to keep its copy updated, so it'll continue to send updates to this other version of itself to keep it up to date.
We can compare this to a backup. When you're talking about a backup, you're creating a copy of it, and it's a point in time that isn't going to change after that, versus a replication, which is going to keep up to date. So if there's a change to your data, that backup is not going to change, however a replica of it will continue to change.
We can see the difference when we're talking about site redundancy. With a hot site, we would be replicating the databases to another location here, and so all the information at any given time is ready to be turned up and ready to go. Versus if we were to use backup instead: we would create a backup, we would ship it over to the other side, and then we would have to restore it to bring this site up and running.
So then the question is, what do we replicate? We could replicate databases, we could replicate files and folders, we could do servers, we could do configurations, directory information. There's a lot of different things that we could replicate, depending on what level you want to replicate at and what technology you're using.
There are different ways that we can implement replication. A good example of machine or disk level replication would be something like VMware, which does a great job at doing that. Microsoft has a Volume Shadow Copy that will do volume level replication. Dropbox does a great job at folder or file replication. And Microsoft SQL Server has availability groups to do database replication.
There is a difference between synchronous versus asynchronous replication. Let's say that there's some sort of record that needs to be added to a database, and then we want it to be replicated to the other side. If this was synchronous, what would happen is the record would not be committed right away; it would be shipped over to the other database, and then they would be committed at the same time, and now you know that both of these databases are exactly at the same level, that nothing is going to get off between these two databases.
Versus asynchronous, which means that it doesn't necessarily have to happen at the same time. This record could be committed to this database, it could be shipped over to the other side at any point in time, and then this record gets committed to this database.
Obviously the ideal is that they get committed at the same time and that you make sure that there is integrity between these two databases. The problem is, if your connection between these two sites is slow, or between these two servers is slow, that could cause problems, because there could be a delay with this record getting shipped over and a delay with it getting committed, therefore this record is being delayed committing to the primary database. So it could become problematic if you have a slow connection.
Sometimes we want to implement bidirectional replication. One thing that happens with a lot of databases is that you just have a primary database that has all of the records on it, and then it gets replicated over to a secondary database, that way we have some sort of ability to fail over to this other database. Perhaps files are the same way.
However, sometimes we want to be able to access both files from two different locations, and there we need a bidirectional replication, where changes get replicated in both directions, therefore we can make changes on both documents. A great example of this is Dropbox. With Dropbox, whatever location you have your Dropbox folders at, you can make changes to either one and it gets replicated to the other copy.
Creating changes to two different copies can cause problems, and there are some systems that actually do really well at overcoming those problems, while other systems aren't quite as good at overcoming those issues. You get conflicts when you have a change that's made to one document that conflicts with a change made to another document.
So one thing that we can do is something called file locking. File locking is the idea that when a document or a file is opened, we lock that document so changes can't happen from one direction to the other. Once that is done with this document, it can unlock that document, and now changes can be made in the other location and this would get locked, so that way you can't make changes in this location.
Replication is making a copy and keeping that copy updated. We talked about what to replicate and at what level you would want to replicate things out. We talked about synchronous versus asynchronous — whether we commit the changes to the copies at the same time, or we can do it at different times. We talked about bidirectional replication, whether you just have a primary copy and a secondary copy, or if you can change either document or either file at the same time. And then, some technologies don't really handle bidirectional replication all that well, and so we have something called file locking, where we lock one of the files so that you can't change it on the other side.
TechKnowSurge builds IT and cybersecurity professionals through hands-on, concept-first training built around real understanding — not memorization. Free interactive tools, structured programs, and 25+ years of real-world experience, all in one place.
Explore free tools and programs →