The replication capability of has the following features:

• One master, one slave: A replicated database resides in two locations and is managed by two different instances. One of these instances has the master role for this database, and the other has the slave role. Typically, the master and slave run on different nodes, but this is not a requirement. Together, the master and its associated slave represent a replication pair.
• Roll-forward shipped log: Replication is based on shipping the transaction log from the master to the slave, and then rolling forward the operations described in the log to the slave database.
• Asymmetry: Only the master processes transactions. The slave processes no transactions, not even read operations.
• Asynchronicity: Transactions are committed on the master without waiting for the slave. The shipping of the transaction log to the slave is performed regularly, and is completely decoupled from the transaction execution at the master. This may lead to a few lost transactions if the master crashes.
• Shared nothing: Apart from the network line, no hardware is assumed to be shared.
• Replication granularity: The granularity for replication is exactly one database. However, one instance may have different roles for different databases. For example, one instance may have the following roles, all at the same time:
  • The master role for one database D1 replicated to one node
  • The slave role for a database D2 replicated from another node
  • The normal, non-replicated, role for a database D3

Replication builds on 's ability to recover from a crash by starting with a backup and rolling forward 's transaction log files. The master sends log records to the slave using a network connection. The slave then writes these log records to its local log and redoes them.

If the master fails, the slave completes the recovery by redoing the log that has not already been processed. The state of the slave after this recovery is close to the state the master had when it crashed. However, some of the last transactions performed on the master may not have been sent to the slave and may therefore not be reflected. When the slave has completed the recovery work, it is transformed into a normal instance that is ready to process transactions. For more details, see .

Several properties allow you to specify the size of the replication log buffers and the intervals between log shipments, as well as whether replication messages are logged. See the for details.

You can perform replication on a database that runs in either embedded mode or Network Server mode.