G->TechLink: G->Pointer's Technology Link

By default a domain controller is a read/write domain controller. So, it can be used to authenticate against it, but also to e.g. set a new password. That password will then be replicated out to other domain controllers on your network. Why would you need a read-only domain controller now? In short: for security reasons (not performance, availability, ...). The assumption is that remote offices will be less secured than the company headquarters for many reasons (e.g. reducing IT costs on security). As such it is handy to have a local domain controller that clients can use to authenticate on-site. Yet, those should not be allowed to replicate data back to the central system, as they are assumed to be more vulnerable to attacks and breaches than the (hopefully) fortified HQ. Sources: Introduction to Active Directory Infrastructure in Windows Server 2012 @ ~20:00

Transactional replication typically starts with a snapshot of the publication database objects and data. As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed. Transactional replication is typically used in server-to-server environments and is appropriate in each of the following cases: You want incremental changes to be propagated to Subscribers as they occur. The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber. The application requires access to intermediate data states. For example, if a row changes five times, transactional replication allows an applic...

Merge replication, like transactional replication, typically starts with a snapshot of the publication database objects and data. Subsequent data changes and schema modifications made at the Publisher and Subscribers are tracked with triggers. The Subscriber synchronizes with the Publisher when connected to the network and exchanges all rows that have changed between the Publisher and Subscriber since the last time synchronization occurred. Merge replication is typically used in server-to-client environments. Merge replication is appropriate in any of the following situations: Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers. Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers. Each Subscriber requires a different partition of data. Conflicts might occur and, when they do, you need the ability to detect and resolve th...