The classic case of database replication is found in applications that connect a primary storage location and a secondary location that is often off site. While fast transactions and queries are a major reason to employ database replication, having multiple copies of databases is also valuable for testing and operational reporting. Overall, distributed database management systems (DDBMS) work to ensure that changes, additions and deletions performed on the data at any given location are automatically reflected in the data stored at all the other locations. In this video, Scott Golightly walks through a transactional replication setup for SQL Server. Such methods help ensure up-to-date data is available in multiple locations. Early instances of database replication were typically described as master-slave configurations, but comparable descriptions today tend to have database replication described using master-replica, leader-follower, primary-secondary, server-client and other terminology. While remote office database replication may have been the canonical example of replication for many years, fail-safe and fault-tolerant database backup schemes have also arisen as drivers of replication activity, as have horizontally scaling distributed database configurations on premises and on cloud computing platforms. Replication details vary between such relational systems as IBM DB2, Microsoft SQL Server, Sybase, MySQL and PostgreSQL.