Database Replication

Database replication maintains copies of database data across database instances, infrastructure environments, or geographic locations. It usually begins with an initial copy, followed by a mechanism that transfers subsequent inserts, updates, and deletes. Replication can operate at the storage, transaction-log, or logical-data level, and it can cover an entire database or selected tables. Its main purposes include migration, high availability, disaster recovery, and read scaling.

For cloud migration, replication is useful when a database is too large or too business-critical for a lengthy offline transfer. For example, an organization moving an on-premises order database to a managed cloud database can load existing records into the target while customers continue placing orders on the source. Change data capture, often abbreviated CDC, then transfers ongoing changes from the source transaction logs. This approach reduces downtime, but it does not automatically eliminate the need for a controlled cutover.

A practical cutover involves validating the target, stopping or restricting source writes, allowing outstanding changes to reach the target, and redirecting application connections. Engineers should check replication lag, data correctness, application compatibility, permissions, and connection configuration before switching traffic. A rollback plan must account for writes accepted by the new target; simply reconnecting applications to the old source can lose access to those changes unless reverse synchronization or another reconciliation process exists.

Replication can support either a same-engine migration or a migration between different database engines when tooling supports that combination. A same-engine move generally requires fewer application changes. A cross-engine move can also require schema conversion, SQL changes, data-type mapping, and replacement of stored procedures or engine-specific features. Replication moves supported data changes; it does not automatically make incompatible database engines or application code compatible. It is a migration technique, not a complete migration strategy by itself.

Synchronous replication makes write completion depend on acknowledgment from designated replicas or a quorum, according to the system's rules. It can strengthen durability guarantees but adds communication latency and may reduce write availability during connectivity failures. Asynchronous replication lets the source commit without waiting for replicas, improving write responsiveness but allowing replication lag. Applications reading a lagging replica might not immediately see a recently committed update, and failover can lose changes that never reached the replacement.

Replication should not be confused with backup. An accidental deletion or harmful update can propagate to replicas, so independent backups and point-in-time recovery remain important. A replica also does not necessarily accept reads, support automatic failover, or increase write throughput. Those capabilities depend on the database architecture and configuration.

Operational planning includes network bandwidth, transfer charges, replica capacity, encryption, access control, and monitoring. Log retention must accommodate outages so replication can resume without requiring another full load. For migration exam scenarios, recognize ongoing database replication as a way to keep a target current while the source remains operational, followed by a planned, validated cutover.