Dual-write mode keeps an online source database and a migration destination synchronized by sending each application update to both systems. It prevents writes received during migration from being missed before traffic moves to ScyllaDB. section 12.2.1 section 12.3
Apply dual writing with these operational safeguards:
- Write to the destination only after the primary source write succeeds; otherwise, destination-only data can appear after cutover. section 12.2.1
- Use appropriate ScyllaDB consistency behavior, potentially downgrading consistency and relying on repair and replication when stronger attempts fail. section 12.2.1
- Give migrated rows a USING TIMESTAMP value no later than the beginning of the migration reads, preferably from the source database’s write or modification timestamp. section 12.2.4
- Run the migrator as quickly as possible without harming either database’s workload or data correctness. section 12.2.4
Protecting a concurrently edited row
A migrator reads an article while an editor updates its title through dual writing. If the migrator later inserts the older article with a higher timestamp, last-write-wins behavior can overwrite the editor’s newer update. Supplying the source-derived timestamp prevents the migration insert from stomping newer data. section 12.2.4
Figure 12.4 If you need to keep your application online during a migration, you must also dual-write data to avoid missed writes.
Trace how an application that remains online sends updates to both the source and destination during migration. section 12.2.1
