Databases Reference
In-Depth Information
replication concepts, as well as the specifics of how replication is implemented,
varies by manufacturer.
Basically, replication is the process of copying changes from one table to one
or more other tables. The way this is accomplished varies, with different DBMSs
supporting one or more of the following options for replication type:
▲
Snapshot replication:
a copy is made of the entire table and written as a
whole to the destination, overwriting any data currently in the table, or
creating the table for initial load of a remote database.
▲
Change replication:
also known as
merge replication.
Changed rows in
the source table are written to the destination, overwriting or inserting
data as appropriate, which can result in update conflicts.
▲
Transactional replication:
completed transactions are copied from the
source database's transaction log to the destination transaction logs,
where they are applied to the database tables.
With some replication configurations, you have a single consolidated data-
base with a full set of all rows. This leaves three options for managing updates.
This design decision is made somewhat independent of the replication type. One
option for managing updates is that changes are made to the consolidated data-
base only, and then distributed out to the other copies. This option has the fewest
issues relating to concurrency, but requires access to the consolidated database
to make changes. The next option is to allow changes at the consolidated copy
and the replicated copies. The copies send their changes to the consolidated data-
base where the changes are consolidated and sent back out to the copies. This
allows for local updates but has a somewhat higher risk of concurrency errors
and requires careful management. The third option allows updates at the con-
solidated database and at any copy, but the copies are able to directly update
each other. This method has the highest risk of concurrency errors and the
longest
latency,
the time between when the update is made and when it is repli-
cated throughout the system. However, this third method is sometimes the only
workable solution when you have intermittent or unreliable connections between
the database locations.
The final replication design combines the type and update method. For
example, you might have an environment that uses change replication that per-
mits updates at the copies only, consolidating the changes at the consolidated
database. However, it might be more appropriate to permit updates at the copies,
but then allow the copies to use change replication to update each other (espe-
cially if there is no one consolidated master copy). You can also mix and match
methods. For example, you might use snapshot replication once a month to send
fresh copies out to all of the remote locations to ensure consistency with the
source database.
