In this video, we walk through 5 ISC practice questions on mirroring and replication. These questions are from ISC content area 1 on the AICPA CPA exam blueprints: Information Systems and Data Management.
The best way to use this video is to pause each time we get to a new question in the video, and then make your own attempt at the question before watching us go through it.
Mirroring and Replication
Mirroring and replication both keep copies of data on more than one storage device or system, so the data stays available when something goes wrong. They overlap in that way, but they serve different main purposes. A mirror is kept on standby, ready to take over if the primary fails. Replicas are sent to other systems or locations, where they’re often put to active use.
Mirroring
Mirroring keeps a full copy of the data on a second storage device, with every change copied to the mirror. The main objective is redundancy. If one drive fails, the other already has the data and can take over, so the data stays available with little or no downtime.
For example, a company might set up its order-processing system so every change is written to two separate drives. If one drive fails, the system keeps running from the other.
Mirroring can also speed up reading data. Since each drive holds the same data, read requests can be split across the drives instead of all going to one.
What mirroring doesn’t do is protect against problems with the data itself. Because every change is copied to the mirror, mistakes are copied too. If a record is deleted, corrupted, or encrypted by ransomware on the primary drive, the same thing happens on the mirror. Recovering from that takes a backup, which is a copy of the data saved at an earlier point in time and kept separately.
Synchronous and Asynchronous Mirroring
Synchronous mirroring confirms each change only after the mirror has received it. If the primary fails, the mirror already holds every confirmed change, so no confirmed data is lost. The tradeoff is that every transaction has to wait on the mirror, and that wait grows with distance.
Asynchronous mirroring writes the change to the primary first and copies it to the mirror shortly afterward. This avoids the wait, which makes it a common choice when the mirror is far away. The risk is that the mirror may temporarily lag behind the primary. If the primary fails during that gap, the most recent changes can be lost.
Replication
Replication copies data from one database to other systems or locations so users there work from the same information. Unlike a mirror, replicas are often actively used, which supports several objectives.
Data distribution puts data closer to where it’s needed. A company with offices in several countries can send copies of its main database to regional servers, so employees there look up information from a nearby copy instead of reaching back to headquarters every time.
Load balancing spreads out the workload. Reports and lookups only read data, so they can run against replicas, while changes are made in the main database. This reduces the load on the main database.
Replication can also keep data available if the main database fails, as long as a replica has been set up to take over. Like a mirror, a replica receives deletions and bad changes from the main database, so it isn’t a substitute for backups.
Types of Replication
Snapshot replication copies the full set of data at set intervals, such as once a night. Between copies, the replica doesn’t reflect new changes, which works for something like a reporting copy that only needs the prior day’s data.
Transactional replication sends changes from the main database out to the replicas as they occur, usually with only a short delay. It fits situations where the copies need to stay close to current, such as warehouses that need to see new orders soon after they’re placed.
Merge replication synchronizes changes made in more than one place into a single database. For example, sales representatives might update customer records on their laptops while offline, and those changes are combined with everyone else’s when they reconnect. If two people changed the same record, the conflict has to be resolved so only one version is kept.
