Foundational data architecture patterns - Making Sense of NoSQL - page 49

include these types of functions, then RDBMS solutions might be a better match to
your needs.

3.4.4 RDBMS replication and synchronization

As we've mentioned, early RDBMS s were designed to run on single CPU s. When orga-
nizations have critical data, it's stored on a primary hard disk with a duplicate copy of
each insert, update, and delete transaction replicated in a journal or log file on a sep-
arate drive. If the database becomes corrupt, a backup of the database is loaded and
the journal “replayed” to get the database to the point it was when it was halted.
Journal files add overhead and slow the system down, but they're essential to guar-
antee the ACID nature of RDBMS s. There are situations when a business can't wait for
the backup to restore and the journal files to be played. In these situations, the data
can immediately be written not only to the master database but also to a copy (or mir-
ror) of the original database. Figure 3.8 demonstrates how mirroring is applied in
RDBMS s.
In a mirrored database, when the master database crashes, the mirrored system
(slave) takes over the primary system's operations. When additional redundancy is
required, more than one mirror system is created, as the likelihood of two or more sys-
tems all crashing at the same time is slim and generally sufficient security for most
business processes.
The replication process solves some of the challenges associated with creating
high-availably systems. If one of the master systems goes down, the slave can step in to
take its place. With that being said, it introduces database administration staff to the
challenges of distributed computing. For example, what if one of the slave systems
crashes for a while? Should the master system stop accepting transactions while it waits
for the slave system to come back online? How does one system get “caught up” on the

The application reads and
writes only to the master database.

Application

Any changes to the master are
immediately copied to the slave servers.

Master database

Slave database Slave database

Figure 3.8 Replication and mirroring—how applications are
configured to read and write all their data to a single master
database. Any change in the master database immediately
triggers a process that copies the transaction information
(inserts, updates, deletes) to one or more slave systems that
mirror the master database. These slave servers can quickly
take over the load of the master if the master database
becomes unavailable. This configuration allows the database to
provide high availability data services.