docs(migration): move database constraints to first migration item
This commit is contained in:
@@ -156,7 +156,19 @@ Date: `2026-04-12`
|
||||
|
||||
## Chapter 2
|
||||
|
||||
### 01. Reconstruct the current live `mevnode_bot` and `trade-staging` state into canonical Git/IaC in a new Gitea organization
|
||||
### 01. 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.
|
||||
|
||||
### 02. Reconstruct the current live `mevnode_bot` and `trade-staging` state into canonical Git/IaC in a new Gitea organization
|
||||
|
||||
- Live `k3s` is the input for reconstruction, not the final source of truth.
|
||||
- Split application repositories, Kubernetes manifests, and host IaC into separate repositories.
|
||||
@@ -168,66 +180,54 @@ Date: `2026-04-12`
|
||||
- Record every current live drift before moving workloads.
|
||||
- Done on `2026-04-12`: `trade-next` was created and the target repositories now exist.
|
||||
- Done on `2026-04-12`: the live component boundary map was written to `trade-next/trade-docs/doc/k3s-component-repo-map.md`.
|
||||
- Next for item `01`: reconstruct the live `trade-staging` objects, overlays, secrets wiring, and host-specific drift into `trade-gitops` and `trade-host-iac`.
|
||||
- Next for item `02`: reconstruct the live `trade-staging` objects, overlays, secrets wiring, and host-specific drift into `trade-gitops` and `trade-host-iac`.
|
||||
|
||||
### 02. Fix `dlob-publisher-hot` startup, readiness, and liveness
|
||||
### 03. Fix `dlob-publisher-hot` startup, readiness, and liveness
|
||||
|
||||
- Pending.
|
||||
|
||||
### 03. Fix `dlob-publisher-all` startup, readiness, and liveness
|
||||
### 04. Fix `dlob-publisher-all` startup, readiness, and liveness
|
||||
|
||||
- Pending.
|
||||
|
||||
### 04. Confirm whether trade Redis is meant to run as a single instance or as Redis Cluster
|
||||
### 05. Confirm whether trade Redis is meant to run as a single instance or as Redis Cluster
|
||||
|
||||
- Pending.
|
||||
|
||||
### 05. Align publisher Redis client mode with the actual deployed Redis topology
|
||||
### 06. Align publisher Redis client mode with the actual deployed Redis topology
|
||||
|
||||
- Pending.
|
||||
|
||||
### 06. Restore or recreate the missing `gitea-registry` image pull secret
|
||||
### 07. Restore or recreate the missing `gitea-registry` image pull secret
|
||||
|
||||
- Pending.
|
||||
|
||||
### 07. Verify that image pulls work after node reboot and on a cold start
|
||||
### 08. Verify that image pulls work after node reboot and on a cold start
|
||||
|
||||
- Pending.
|
||||
|
||||
### 08. Measure the real PostgreSQL data size inside the current trade PVC
|
||||
### 09. Measure the real PostgreSQL data size inside the current trade PVC
|
||||
|
||||
- Pending.
|
||||
|
||||
### 09. Explain why the declared `20Gi` PVC currently consumes about `585 GiB` on disk
|
||||
### 10. Explain why the declared `20Gi` PVC currently consumes about `585 GiB` on disk
|
||||
|
||||
- Pending.
|
||||
|
||||
### 10. Decide which trade datasets must be migrated and which can be rebuilt
|
||||
### 11. Decide which trade datasets must be migrated and which can be rebuilt
|
||||
|
||||
- Pending.
|
||||
|
||||
### 11. Define a dedicated storage path or device for trade data on `mevnode`
|
||||
### 12. Define a dedicated storage path or device for trade data on `mevnode`
|
||||
|
||||
- Pending.
|
||||
|
||||
### 12. Define hard storage quotas and monitoring for trade data on `mevnode`
|
||||
### 13. Define hard storage quotas and monitoring for trade data on `mevnode`
|
||||
|
||||
- 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 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.
|
||||
@@ -278,19 +278,19 @@ Date: `2026-04-12`
|
||||
|
||||
## Chapter 3
|
||||
|
||||
- [ ] 01. Reconstruct the current live `mevnode_bot` and `trade-staging` state into canonical Git/IaC in a new Gitea organization.
|
||||
- [ ] 02. Fix `dlob-publisher-hot` startup, readiness, and liveness.
|
||||
- [ ] 03. Fix `dlob-publisher-all` startup, readiness, and liveness.
|
||||
- [ ] 04. Confirm whether trade Redis is meant to run as a single instance or as Redis Cluster.
|
||||
- [ ] 05. Align publisher Redis client mode with the actual deployed Redis topology.
|
||||
- [ ] 06. Restore or recreate the missing `gitea-registry` image pull secret.
|
||||
- [ ] 07. Verify that image pulls work after node reboot and on a cold start.
|
||||
- [ ] 08. Measure the real PostgreSQL data size inside the current trade PVC.
|
||||
- [ ] 09. Explain why the declared `20Gi` PVC currently consumes about `585 GiB` on disk.
|
||||
- [ ] 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`.
|
||||
- [ ] 12. Define hard storage quotas and monitoring for trade data on `mevnode`.
|
||||
- [ ] 13. Define hard database and cache constraints.
|
||||
- [ ] 01. Define hard database and cache constraints.
|
||||
- [ ] 02. Reconstruct the current live `mevnode_bot` and `trade-staging` state into canonical Git/IaC in a new Gitea organization.
|
||||
- [ ] 03. Fix `dlob-publisher-hot` startup, readiness, and liveness.
|
||||
- [ ] 04. Fix `dlob-publisher-all` startup, readiness, and liveness.
|
||||
- [ ] 05. Confirm whether trade Redis is meant to run as a single instance or as Redis Cluster.
|
||||
- [ ] 06. Align publisher Redis client mode with the actual deployed Redis topology.
|
||||
- [ ] 07. Restore or recreate the missing `gitea-registry` image pull secret.
|
||||
- [ ] 08. Verify that image pulls work after node reboot and on a cold start.
|
||||
- [ ] 09. Measure the real PostgreSQL data size inside the current trade PVC.
|
||||
- [ ] 10. Explain why the declared `20Gi` PVC currently consumes about `585 GiB` on disk.
|
||||
- [ ] 11. Decide which trade datasets must be migrated and which can be rebuilt.
|
||||
- [ ] 12. Define a dedicated storage path or device for trade data on `mevnode`.
|
||||
- [ ] 13. Define hard storage quotas and monitoring for trade data on `mevnode`.
|
||||
- [ ] 14. Define CPU and memory reservations that protect `agave-validator`.
|
||||
- [ ] 15. Define the minimum safe free RAM headroom on `mevnode` during rollout.
|
||||
- [ ] 16. Define the maximum acceptable swap usage on `mevnode` during rollout.
|
||||
|
||||
Reference in New Issue
Block a user