Aerospike Application Logic and Data Migration: Ensuring Rollback Safety During Bin Evolution

Ensuring Read-Consistency During Rollbacks

To ensure read-consistency when rolling back to an application version that is unaware of new bins, you must implement Dual-Write synchronization. The application version introducing the new bin must write updates to both the legacy bin and the new bin simultaneously.

The Rollback-Safe Strategy

The recommended approach follows a strict sequence to ensure that no version of the application ever encounters a "missing" value for a required field:

1. Phase 1 (Expand): Deploy the new application version. It reads from the new bin (falling back to the old bin if the new one is null) but writes to both the old and new bins.
2. Phase 2 (Migrate): Run a background process (e.g., using Aerospike Scan) to copy data from the old bin to the new bin for records not yet updated by the application.
3. Phase 3 (Contract): Only after the new version is verified as stable and the migration is complete, deploy a version that reads and writes exclusively to the new bin.

If a rollback occurs during Phase 1 or 2, the previous application version will continue reading from the old bin, which has been kept current by the dual-write logic of the failed deployment.

Handling Orphan Bins and Storage Bloat

Orphan bins (legacy bins no longer used by the current application logic) should be removed only after the rollback window has closed. Because Aerospike is schema-less, these bins occupy space per record and can impact read latency if the record size increases significantly.

Cleanup Workflow

• Verification: Use aql or astool to sample records and confirm that the new bin is populated and the old bin is no longer being updated.
• Scoped Deletion: Use a background scan to explicitly remove the old bin from records. This prevents a sudden spike in disk I/O that could occur if a massive batch delete is attempted.
• TTL Management: If the legacy data has a natural expiration, you may allow the TTL to expire the records naturally, though this does not remove the bin from active records.

Verification Commands

To verify that dual-writes are functioning before proceeding to the "Contract" phase, use aql to inspect a record:

# Check if both bins exist and contain the expected values
aql -c "SELECT * FROM test.demo WHERE pk = 'user123'"

Critical Diagnostic Detail

Are you using Aerospike Check-and-Set (CAS) or optimistic locking for these updates? If not, concurrent writes during the migration phase may lead to the legacy bin containing a newer value than the new bin (or vice versa), breaking the consistency required for a safe rollback.