trade-next/trade-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(migration): add enforced database and cache constraints

Browse Source
This commit is contained in:
u1
2026-04-12 13:16:58 +00:00
parent a127cfbde3
commit 2f95a70359
1 changed files with 52 additions and 24 deletions
Download Patch File Download Diff File Expand all files Collapse all files

76
doc/migration-todo.md
View File

@@ -213,40 +213,66 @@ Date: `2026-04-12`
### 12. Define hard storage quotas and monitoring for trade data on `mevnode` ### 12. Define hard storage quotas and monitoring for trade data on `mevnode`
- Pending. - Pending.
- Use enforceable limits, not only declarative PVC sizes without backend enforcement.
- Add warning and critical thresholds for disk usage, inode usage, and PVC growth.
### 13. Define CPU and memory reservations that protect `agave-validator` ### 13. Define hard database and cache constraints
- Pending.
- Storage limits for `Postgres` and `Redis` must be enforced by the real storage backend, not only declared in Kubernetes manifests.
- `Postgres` must not be able to grow beyond the actually allocated disk budget.
- `Postgres` must have explicit CPU and memory requests/limits consistent with host headroom.
- `Postgres` must have operating thresholds for free disk, WAL growth, autovacuum, and table/index bloat.
- `Redis` must have explicit memory limits and an intentional eviction/persistence policy.
- `Redis` must not be allowed to consume unbounded RAM or disk on the target host.
- Database and cache capacity alerts must fire before any hard limit is reached, not after the filesystem is already effectively full.
- Full-disk and out-of-memory behavior for `Postgres` and `Redis` must be tested before application cutover.
### 14. Define CPU and memory reservations that protect `agave-validator`
- Pending. - Pending.
### 14. Define the minimum safe free RAM headroom on `mevnode` during rollout ### 15. Define the minimum safe free RAM headroom on `mevnode` during rollout
- Pending. - Pending.
### 15. Define the maximum acceptable swap usage on `mevnode` during rollout ### 16. Define the maximum acceptable swap usage on `mevnode` during rollout
- Pending. - Pending.
### 16. Prepare a minimal canary namespace for trade on `mevnode` ### 17. Install and bootstrap `k3s` on `mevnode`
- Pending.
- Define the target `k3s` installation model on `mevnode`.
- Define the target storage class, host paths, and bootstrap dependencies needed before application rollout.
- Verify that the base cluster, registry access, namespaces, and secret distribution work before any application components are installed.
### 18. Install `Postgres` and `Redis` on `mevnode`
- Pending.
- Bring up the data plane first: `Postgres` and `Redis`.
- Validate persistence, storage placement, service discovery, restart behavior, and cold start.
- Do not install application components until `Postgres` and `Redis` are healthy.
### 19. Prepare a minimal canary namespace for trade on `mevnode`
- Pending. - Pending.
### 17. Bring up Redis, Postgres, and Hasura on `mevnode` ### 20. Bring up `Hasura`, API, and frontend on `mevnode`
- Pending.
- Bring up `Hasura` only after `Postgres` is healthy.
- Bring up API and frontend only after `Hasura`, `Postgres`, and `Redis` are healthy.
### 21. Migrate publishers and ingest only after storage and Redis validation pass
- Pending. - Pending.
### 18. Bring up API and frontend on `mevnode` ### 22. Validate host health, agave health, trade health, and end-to-end flow after rollout
- Pending. - Pending.
### 19. Migrate publishers and ingest only after storage and Redis validation pass ### 23. Keep `mevnode_bot` as a rollback target until the new stack is stable
- Pending.
### 20. Validate host health, agave health, trade health, and end-to-end flow after rollout
- Pending.
### 21. Keep `mevnode_bot` as a rollback target until the new stack is stable
- Pending. - Pending.
@@ -264,12 +290,14 @@ Date: `2026-04-12`
- [ ] 10. Decide which trade datasets must be migrated and which can be rebuilt. - [ ] 10. Decide which trade datasets must be migrated and which can be rebuilt.
- [ ] 11. Define a dedicated storage path or device for trade data on `mevnode`. - [ ] 11. Define a dedicated storage path or device for trade data on `mevnode`.
- [ ] 12. Define hard storage quotas and monitoring for trade data on `mevnode`. - [ ] 12. Define hard storage quotas and monitoring for trade data on `mevnode`.
- [ ] 13. Define CPU and memory reservations that protect `agave-validator`. - [ ] 13. Define hard database and cache constraints.
- [ ] 14. Define the minimum safe free RAM headroom on `mevnode` during rollout. - [ ] 14. Define CPU and memory reservations that protect `agave-validator`.
- [ ] 15. Define the maximum acceptable swap usage on `mevnode` during rollout. - [ ] 15. Define the minimum safe free RAM headroom on `mevnode` during rollout.
- [ ] 16. Prepare a minimal canary namespace for trade on `mevnode`. - [ ] 16. Define the maximum acceptable swap usage on `mevnode` during rollout.
- [ ] 17. Bring up Redis, Postgres, and Hasura on `mevnode`. - [ ] 17. Install and bootstrap `k3s` on `mevnode`.
- [ ] 18. Bring up API and frontend on `mevnode`. - [ ] 18. Install `Postgres` and `Redis` on `mevnode`.
- [ ] 19. Migrate publishers and ingest only after storage and Redis validation pass. - [ ] 19. Prepare a minimal canary namespace for trade on `mevnode`.
- [ ] 20. Validate host health, agave health, trade health, and end-to-end flow after rollout. - [ ] 20. Bring up `Hasura`, API, and frontend on `mevnode`.
- [ ] 21. Keep `mevnode_bot` as a rollback target until the new stack is stable. - [ ] 21. Migrate publishers and ingest only after storage and Redis validation pass.
- [ ] 22. Validate host health, agave health, trade health, and end-to-end flow after rollout.
- [ ] 23. Keep `mevnode_bot` as a rollback target until the new stack is stable.