A downgrading consistency policy retries a failed request with a weaker consistency level. For example, a follow-up attempt can change a write from ALL to QUORUM after at least one node responds. section 10.5.3
Use the policy with care:
- Treat it as an exception rather than the default, because weaker consistency during failures can violate the application’s consistency expectations. section 10.5.3
- Apply it when a secondary database must keep receiving successful primary writes during an online migration or comparison. section 12.2.1
- Rely on ScyllaDB repair and replication to propagate data to its owning nodes after a weaker-consistency write succeeds. section 12.2.1
Dual-writing during migration
An application writes to a primary database and a destination ScyllaDB cluster while the source remains online. The destination write should occur only after the primary succeeds; downgrading consistency options can retry the secondary write with increasingly weaker requirements until it succeeds. section 12.2.1
Figure 12.4 If you need to keep your application online during a migration, you must also dual-write data to avoid missed writes.
The figure shows why online migration requires dual writes: otherwise updates made during migration can be missed. section 12.2.1
