- 313 new markdown files created - 30 relationships embedded - 313 entries indexed - State initialized with usage data
2.2 KiB
2.2 KiB
| id | type | title | tags | importance | confidence | created | updated | relations | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 4bb882a6-1ef9-4ec4-873d-816881f6670b | solution | Paper Dynasty: Database sync workflow for prod to dev |
|
0.8 | 0.8 | 2026-02-03T20:26:11.869126+00:00 | 2026-02-03T20:26:11.869126+00:00 |
|
Created automated workflow to sync production PostgreSQL database (akamai) to dev environment (pd-database).
FILES CREATED:
- ~/.claude/skills/paper-dynasty/scripts/sync_prod_to_dev.sh - Main automation script
- ~/.claude/skills/paper-dynasty/workflows/database-sync.md - Complete documentation
- Updated ~/.claude/skills/paper-dynasty/SKILL.md - Added workflow to skill triggers
SCRIPT FEATURES:
- Pre-flight connectivity checks to both databases
- Database statistics before/after (size, table count)
- Automatic timestamped backups to ~/.paper-dynasty/db-backups/
- Safety confirmation prompt (or --yes flag to skip)
- Dry-run mode (--dry-run) for preview
- No-backup mode (--no-backup) for speed
- Colored output for readability
- Error handling with automatic cleanup
DATABASE DETAILS:
- Production: akamai, container sba_postgres, database pd_master, user pd_admin
- Dev: pd-database (10.10.0.42), container sba_postgres, database paperdynasty_dev, user sba_admin
- Both are PostgreSQL (migrated from SQLite in Jan 2026)
USAGE: ~/.claude/skills/paper-dynasty/scripts/sync_prod_to_dev.sh --yes
Or via skill: /paper-dynasty sync prod to dev
TESTED RESULTS:
- Production: 151 MB, 29 tables, 68,191 cards, 105 teams
- Dev after sync: 61 MB, 37 tables, 68,191 cards, 105 teams
- Backup created: 289K SQL dump
- Sync time: ~1-2 minutes
KNOWN ISSUES:
- Role ownership errors at end (pd_admin role doesn't exist on dev) - harmless, data sync succeeds
- The dump includes role OWNER statements that fail but don't affect data integrity
USE CASES:
- Testing PostgreSQL migration changes with real production data
- Debugging production issues locally
- QA testing with production-sized datasets
- Setting up new dev environments