|
| 1 | +# Database Migrations Guide |
| 2 | + |
| 3 | +This package uses [node-pg-migrate](https://github.com/salsita/node-pg-migrate) for managing database schema changes. |
| 4 | + |
| 5 | +## Quick Reference |
| 6 | + |
| 7 | +```bash |
| 8 | +# Run pending migrations |
| 9 | +aztec migrate-ha-db up --database-url postgresql://... |
| 10 | + |
| 11 | +# Rollback last migration |
| 12 | +aztec migrate-ha-db down --database-url postgresql://... |
| 13 | +``` |
| 14 | + |
| 15 | +## Migration Files |
| 16 | + |
| 17 | +Migrations are located in the `migrations/` directory and are named with timestamps: |
| 18 | + |
| 19 | +``` |
| 20 | +migrations/ |
| 21 | + └── 1_initial-schema.ts |
| 22 | +``` |
| 23 | + |
| 24 | +## Creating New Migrations |
| 25 | + |
| 26 | +When you need to modify the database schema: |
| 27 | + |
| 28 | +```bash |
| 29 | +# Generate a new migration file |
| 30 | +npx node-pg-migrate create add-new-field |
| 31 | + |
| 32 | +# This creates: migrations/[timestamp]_add-new-field.ts |
| 33 | +``` |
| 34 | + |
| 35 | +Edit the generated file: |
| 36 | + |
| 37 | +```typescript |
| 38 | +import type { MigrationBuilder } from 'node-pg-migrate'; |
| 39 | + |
| 40 | +export async function up(pgm: MigrationBuilder): Promise<void> { |
| 41 | + // Add your schema changes here |
| 42 | + pgm.addColumn('validator_duties', { |
| 43 | + new_field: { type: 'text', notNull: false }, |
| 44 | + }); |
| 45 | +} |
| 46 | + |
| 47 | +export async function down(pgm: MigrationBuilder): Promise<void> { |
| 48 | + // Reverse the changes |
| 49 | + pgm.dropColumn('validator_duties', 'new_field'); |
| 50 | +} |
| 51 | +``` |
| 52 | + |
| 53 | +## Production Deployment |
| 54 | + |
| 55 | +### Option 1: Kubernetes Init Container |
| 56 | + |
| 57 | +```yaml |
| 58 | +apiVersion: apps/v1 |
| 59 | +kind: Deployment |
| 60 | +metadata: |
| 61 | + name: validator |
| 62 | +spec: |
| 63 | + template: |
| 64 | + spec: |
| 65 | + initContainers: |
| 66 | + - name: db-migrate |
| 67 | + image: aztecprotocol/aztec:<image_tag> |
| 68 | + command: ['node', '--no-warnings', '/usr/src/yarn-project/aztec/dest/bin/index.js', 'migrate-ha-db', 'up'] |
| 69 | + env: |
| 70 | + - name: DATABASE_URL |
| 71 | + valueFrom: |
| 72 | + secretKeyRef: |
| 73 | + name: db-credentials |
| 74 | + key: connection-string |
| 75 | + containers: |
| 76 | + - name: validator |
| 77 | + image: aztecprotocol/aztec:<image_tag> |
| 78 | + # ... validator config |
| 79 | +``` |
| 80 | + |
| 81 | +### Option 2: Separate Migration Job |
| 82 | + |
| 83 | +```yaml |
| 84 | +apiVersion: batch/v1 |
| 85 | +kind: Job |
| 86 | +metadata: |
| 87 | + name: validator-migrate-v1 |
| 88 | +spec: |
| 89 | + template: |
| 90 | + spec: |
| 91 | + containers: |
| 92 | + - name: migrate |
| 93 | + image: aztecprotocol/aztec:<image_tag> |
| 94 | + command: ['node', '--no-warnings', '/usr/src/yarn-project/aztec/dest/bin/index.js', 'migrate-ha-db', 'up'] |
| 95 | + env: |
| 96 | + - name: DATABASE_URL |
| 97 | + valueFrom: |
| 98 | + secretKeyRef: |
| 99 | + name: db-credentials |
| 100 | + key: connection-string |
| 101 | + restartPolicy: Never |
| 102 | +``` |
| 103 | +
|
| 104 | +### Option 3: CI/CD Pipeline |
| 105 | +
|
| 106 | +```yaml |
| 107 | +# GitHub Actions example |
| 108 | +- name: Run Database Migrations |
| 109 | + run: | |
| 110 | + docker run --rm \ |
| 111 | + -e DATABASE_URL=${{ secrets.DATABASE_URL }} \ |
| 112 | + aztecprotocol/aztec:<image_tag> \ |
| 113 | + migrate-ha-db up |
| 114 | +``` |
| 115 | +
|
| 116 | +## High Availability Considerations |
| 117 | +
|
| 118 | +The migrations use idempotent SQL operations (`IF NOT EXISTS`, `ON CONFLICT`, etc.), making them safe to run concurrently from multiple nodes. However, for cleaner logs and faster deployments, we recommend: |
| 119 | + |
| 120 | +1. **Run migrations once** from an init container or migration job |
| 121 | +2. **Then start** multiple validator nodes |
| 122 | + |
| 123 | +If multiple nodes run migrations simultaneously, they will all succeed, but you'll see redundant log output. |
| 124 | + |
| 125 | +## Development Workflow |
| 126 | + |
| 127 | +```bash |
| 128 | +# 1. Create migration |
| 129 | +npx node-pg-migrate create my-feature |
| 130 | +
|
| 131 | +# 2. Edit migrations/[timestamp]_my-feature.ts |
| 132 | +
|
| 133 | +# 3. Test migration locally |
| 134 | +aztec migrate-ha-db up --database-url postgresql://localhost:5432/validator_dev |
| 135 | +
|
| 136 | +# 4. Test rollback |
| 137 | +aztec migrate-ha-db down --database-url postgresql://localhost:5432/validator_dev |
| 138 | +
|
| 139 | +# 5. Re-apply |
| 140 | +aztec migrate-ha-db up --database-url postgresql://localhost:5432/validator_dev |
| 141 | +
|
| 142 | +# 6. Run tests |
| 143 | +yarn test |
| 144 | +``` |
| 145 | + |
| 146 | +## Troubleshooting |
| 147 | + |
| 148 | +### Migration Failed Midway |
| 149 | + |
| 150 | +If a migration fails partway through: |
| 151 | + |
| 152 | +```bash |
| 153 | +# The failed migration will be marked as running |
| 154 | +# Fix the issue and re-run |
| 155 | +aztec migrate-ha-db up --database-url postgresql://... |
| 156 | +``` |
| 157 | + |
| 158 | +### Reset Development Database |
| 159 | + |
| 160 | +```bash |
| 161 | +# Drop all migrations |
| 162 | +while aztec migrate-ha-db down --database-url postgresql://localhost:5432/validator_dev; do :; done |
| 163 | +
|
| 164 | +# Or drop the database entirely |
| 165 | +psql -c "DROP DATABASE validator_dev;" |
| 166 | +psql -c "CREATE DATABASE validator_dev;" |
| 167 | +
|
| 168 | +# Re-run migrations |
| 169 | +aztec migrate-ha-db up --database-url postgresql://localhost:5432/validator_dev |
| 170 | +``` |
| 171 | + |
| 172 | +### Check Applied Migrations |
| 173 | + |
| 174 | +```bash |
| 175 | +# Query the migrations table |
| 176 | +psql $DATABASE_URL -c "SELECT * FROM pgmigrations ORDER BY id;" |
| 177 | +``` |
| 178 | + |
| 179 | +## Migration Best Practices |
| 180 | + |
| 181 | +1. **Always provide `down()` migrations** for rollback capability |
| 182 | +2. **Test migrations on a copy of production data** before deploying |
| 183 | +3. **Make migrations backward compatible** when possible |
| 184 | +4. **Avoid data migrations in schema migrations** - use separate data migration scripts |
| 185 | +5. **Keep migrations small and focused** - one logical change per migration |
| 186 | +6. **Never modify committed migrations** - create a new migration instead |
0 commit comments