asmhatreandClaude Sonnet 5
e478eafda3
Companion code for Zero-Downtime Database Migrations: Expand-Contract in Practice with Spring Boot: a full expand/migrate-writes/migrate-reads/contract sequence run as an actual rolling deploy across two live replicas, with a load generator sending continuous HTTP traffic through all four deploys (99.98% success, every residual error traced to a root cause rather than left unexplained). Findings include a real NOT NULL constraint trap in the expand migration, a backfill-window bug in the read switch, H2's AUTO_SERVER=TRUE single-point-of-failure behavior under a rolling restart, the drain-before-SIGTERM fix needed to close a health-check gap during graceful shutdown, and H2 silently discarding a concurrently committed INSERT during an ALTER TABLE ADD/DROP COLUMN rebuild - confirmed, by primary source, to be an H2-specific behavior rather than a property of the technique itself. Co-Authored-By: Claude Sonnet 5 <[email protected]> Claude-Session: https://claude.ai/code/session_019Fb7vW8vLyLKngBc4R3huA
42 lines
2.3 KiB
Markdown
42 lines
2.3 KiB
Markdown
# 5. The read switch
|
|
|
|
[← 4. The dual write](04-the-dual-write.md) · [Next: 6. The NOT NULL trap →](06-the-not-null-trap.md)
|
|
|
|
Deploy 3 changes exactly one thing from Deploy 2: where reads come from. In
|
|
[`CustomerService.findById`](https://ankurm.com/git.app/asmhatre/spring-boot-demo/src/branch/main/db-migrations-expand-contract/src/main/java/com/ankurm/expandcontract/customer/CustomerService.java):
|
|
|
|
```java
|
|
String sql = switch (stage) {
|
|
case 1, 2 -> "SELECT id, name, email AS email FROM customers WHERE id = ?";
|
|
case 3 -> "SELECT id, name, COALESCE(email_address, email) AS email FROM customers WHERE id = ?";
|
|
case 4 -> "SELECT id, name, email_address AS email FROM customers WHERE id = ?";
|
|
default -> throw new IllegalStateException();
|
|
};
|
|
```
|
|
|
|
Stage 1 and Stage 2 read the same column: only *writes* changed between them. Stage 3
|
|
is the read switch, and it's a separate deploy from Stage 2 for a reason that isn't
|
|
obvious until you say it out loud: **the write switch and the read switch cannot be
|
|
the same deploy**, because a rolling deploy is not instantaneous. Deploy 2's own
|
|
rollout has a window — anywhere from seconds to minutes, depending on fleet size —
|
|
where some replicas are still Stage 1, writing only `email`. If Deploy 3's read
|
|
switch were bundled into that same deploy, a Stage 3 replica reading
|
|
`email_address` alone would return `NULL` for every row a still-live Stage 1
|
|
replica had just written. That's not a hypothetical: it's
|
|
[chapter 7](07-the-backfill-window-bug.md), reproduced and fixed.
|
|
|
|
The fix already visible above is `COALESCE(email_address, email)` rather than
|
|
`email_address` alone — Stage 3 falls back to the old column for exactly the rows
|
|
that predate full dual-write coverage. Stage 4 doesn't need the fallback anymore: by
|
|
the time Deploy 4 starts, two full deploys' worth of dual-writing (Stage 2 and Stage
|
|
3, run back to back) have guaranteed every row has both columns populated.
|
|
|
|
## Going deeper
|
|
|
|
- The bug this switch would reintroduce if it were merged into Deploy 2, captured
|
|
live: [chapter 7](07-the-backfill-window-bug.md).
|
|
- All six write/read direction pairs across the three rollouts, proven directly:
|
|
[chapter 8](08-the-rolling-window-proof.md).
|
|
|
|
[← 4. The dual write](04-the-dual-write.md) · [Next: 6. The NOT NULL trap →](06-the-not-null-trap.md)
|