> ## Documentation Index
> Fetch the complete documentation index at: https://cockroachlabs.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Phased Delta Migration with Failback Replication
export const InternalLink = ({version, path = "", children, ...props}) => {
let detectedVersion = version || "stable";
if (typeof window !== 'undefined' && !version) {
const match = window.location.pathname.match(/\/docs\/([^/]+)/);
if (match) {
detectedVersion = match[1];
}
}
const normalizedPath = path.startsWith("/") ? path.slice(1) : path;
return
{children}
;
};
A *Phased Delta Migration with Failback Replication* involves migrating data to CockroachDB in several phases. Data can be sliced per tenant, per service, per region, or per table to suit the needs of the migration. **For each given migration phase**, you use MOLT Fetch to perform an initial bulk load of the data, you use MOLT Replicator to update the target database via forward replication and to activate failback replication, and then you cut over application traffic to CockroachDB after schema finalization and data verification. This process is repeated for each phase of data.
* Data is migrated to the target in phases.
* This approach utilizes continuous replication.
* Rollback is achieved via failback replication.
This approach is comparable to the Delta Migration, but dividing the data into multiple phases allows each downtime window to be shorter, and it allows each phase of the migration to be less complex. Depending on how you divide the data, it also may allow your downtime windows to affect only a subset of users. For example, dividing the data per region could mean that, when migrating the data from Region A, application usage in Region B may remain unaffected. This approach may increase overall migration complexity: its duration is longer, you will need to do the work of partitioning the data, and you will have a longer period when you run both the source and the target database concurrently.
Failback replication keeps the source database up to date with changes that occur in the target database once the target database begins receiving write traffic. Failback replication ensures that, if something goes wrong during the migration process, traffic can easily be returned to the source database without data loss. Like forward replication, in this approach, failback replication is run on a per-phase basis. It can persist indefinitely, until you're comfortable maintaining the target database as your sole data store.
This approach is best for databases that are too large to migrate all at once, and in business cases where downtime must be minimal. It's also suitable for risk-averse situations in which a safe rollback path must be ensured. It can only be performed if your team can handle the complexity of this approach, and if your source database can easily be divided into the phases you need.
This page describes an example scenario. While the commands provided can be copy-and-pasted, they may need to be altered or reconsidered to suit the needs of your specific environment.
## Example scenario
You have a moderately-sized (500GB) database that provides the data store for a web application. You want to migrate the entirety of this database to a new CockroachDB cluster. You will divide this migration into four geographic regions (A, B, C, and D).
The application runs on a Kubernetes cluster with an NGINX Ingress Controller.
**Estimated system downtime:** 3-5 minutes per region.
## Step-by-step walkthroughs
The following walkthroughs demonstrate how to use the MOLT tools to perform this migration for each supported source database:
* Phased Delta Migration with Failback Replication from PostgreSQL
* Phased Delta Migration with Failback Replication from MySQL
* Phased Delta Migration with Failback Replication from Oracle
For CockroachDB-to-CockroachDB migrations, contact your account team for guidance.
## See also
* Migration Overview
* Migration Considerations
* Classic Bulk Load Migration
* MOLT Fetch
* MOLT Verify