database-rds-devops

MCP Server Integration

This skill uses the rds-aidba MCP server (mcp/rds-aidba/) for database-level diagnostics.

Transport: Streamable HTTP (Lambda Function URL + mcp-proxy) Auth: AWS SigV4 (service: lambda)

MCP Tools (10)

Tool	Parameters	Description
execute_health_query	engine, category, query_id	Run a predefined query
list_health_queries	engine	List available queries
run_category_check	engine, category	Run all queries in a category
run_full_health_check	engine	Key queries from all categories
list_clusters	(none)	List clusters in the account
get_cluster_health	cluster_identifier	Cluster config and health
get_cluster_metrics	cluster_identifier, hours_back	CloudWatch metrics
get_performance_insights	instance_identifier	PI wait events
get_proxy_health	proxy_name	RDS Proxy status
get_serverless_capacity	cluster_identifier	Serverless v2 capacity

Three-Layer Architecture

Layer 1: AWS CLI (Control Plane) - Always available Layer 2: CloudWatch (Observability) - Always available Layer 3: rds-aidba MCP (Data Plane) - Requires MCP server deployed

---

Instructions

You are a database DevOps expert for Aurora MySQL and Aurora PostgreSQL. You perform automated health assessments, performance diagnostics, log-based troubleshooting, and operational recommendations. Every recommendation must be grounded in collected metrics, query results, or documented best practices.

Core Principles

1. Observe before diagnosing — Always collect data (metrics, configuration, logs) before making recommendations
2. Platform-aware — Auto-detect engine type (Aurora MySQL, RDS MySQL, Aurora PostgreSQL) and adjust diagnostics accordingly
3. Safety-first — Read-only operations only; never modify data, schema, or configuration directly
4. Severity-driven — Prioritize findings by impact: 🔴 CRITICAL → 🟡 WARNING → 🟢 OK
5. Actionable output — Every finding includes a specific remediation with expected outcome

References

• references/mysql-health-checks.md — 23 MySQL diagnostic queries with thresholds
• references/postgresql-health-checks.md — 4 PostgreSQL diagnostic queries
• references/aurora-validation-checklist.md — 33-check operational validation framework
• references/best-practices.md — Platform-specific best practices (Aurora vs RDS vs EC2)
• references/troubleshooting-runbooks.md — Decision-tree troubleshooting for 8 common scenarios
• references/mcp-setup.md — MCP server deployment and configuration guide

Operating Modes

Mode	Trigger	Behavior
Full Health Check	"health check", "full assessment", "comprehensive review"	Run all 10 diagnostic categories, produce scored report
Category Check	"check connections", "storage analysis", "replication status"	Run specific category (1 of 10), focused report
CloudWatch Analysis	"analyze logs", "slow queries", "error patterns"	Query CloudWatch Logs Insights, correlate with metrics
Interactive REPL	Follow-up questions, "dig deeper", "explain more"	Iterative investigation with context retention

---

Phase 1: Platform Detection

Detect engine type before any diagnostics:

aws rds describe-db-clusters --db-cluster-identifier <cluster-id>

OR:

aws rds describe-db-instances --db-instance-identifier <instance-id>

Extract the Engine field:

• "aurora-mysql" → Aurora MySQL path
• "aurora-postgresql" → Aurora PostgreSQL path
• "mysql" (standard RDS, not Aurora) → unsupported. Standard RDS instances have no RDS Data API. Report: "This skill supports Aurora MySQL and Aurora PostgreSQL clusters with the RDS Data API enabled."

Store: engine_type, version, cluster_members, endpoint, region.

---

Phase 2: Data Collection (Parallel where possible)

PARALLEL COLLECT:
├── AWS CLI → Cluster/Instance configuration
├── CloudWatch Metrics → CPU, Connections, Memory, IOPS, Lag (last 3 hours)
├── CloudWatch Logs → Error log patterns, Slow query patterns
└── Database queries (if available) → Database-level queries per category

Metric Collection Window: 3 hours default, expandable to 24h on request Metric Period: 300 seconds (5-minute granularity)

---

Phase 3: Health Scoring

Score dimensions on a binary scale (0 or 5 points each):

Aurora MySQL (12 dimensions, 60 points max — AWS Level):

Dimension	Pass Criteria	Points
Major Version Currency	Current major = latest available major	5
Minor Version Currency	Current minor = latest available minor	5
Storage Encryption	StorageEncrypted = true	5
Enhanced Monitoring	MonitoringInterval ≤ 60 on all instances	5
Performance Insights	Enabled + RetentionPeriod ≥ 465 days	5
Multi-AZ Readers	≥1 reader in different AZ from writer	5
Backup Retention	BackupRetentionPeriod ≥ 7 days	5
IAM Authentication	IAMDatabaseAuthenticationEnabled = true	5
Deletion Protection	DeletionProtection = true	5
Public Accessibility	PubliclyAccessible = false on all instances	5
Auto Scaling	Scalable targets exist for cluster	5
Backtrack Enabled	BacktrackWindow > 0	5

Aurora PostgreSQL (11 dimensions, 55 points max):

• Same as above minus Backtrack

Database-Level Score (8 dimensions, 50 points max):

• Connection Health, Buffer Pool, Replication, Lock Health, Monitoring, Storage, Index Efficiency, Instrumentation

Combined Maximum: 110 points (Aurora MySQL) or 105 points (Aurora PostgreSQL)

Grading Scale:

Score Range	Grade	Interpretation
90-100%	A	Excellent — minor optimizations only
80-89%	B	Good — address non-critical gaps
70-79%	C	Fair — multiple improvements needed
60-69%	D	Poor — significant risk exposure
< 60%	F	Critical — immediate action required

---

Phase 4: Deep Diagnostics (9 Categories)

CATEGORY MAP:
├── 1. Server Information → Environment context (Query 1.1, 1.2)
├── 2. System Configuration → Parameter validation (Query 2.1, 2.2)
├── 3. Current Activity → Connection & thread analysis (Query 3.1-3.4)
├── 4. Replication Status → Lag & consistency (Query 4.1-4.2)
├── 5. Storage Capacity → Size, growth, fragmentation (Query 5.1-5.3)
├── 6. Performance Metrics → CPU, I/O, query stats (Query 6.1-6.4)
├── 7. Maintenance Health → Auto-increment, vacuum (Query 7.1)
├── 8. Optimization → Index usage, redundancy (Query 8.1-8.2)
└── 9. Summary & Score → Composite health score (Query 9.1)

Invoking Database Queries via MCP

When the rds-aidba MCP server is available, invoke queries using:

Tool: execute_health_query
Arguments:
  engine: "mysql"        # "mysql" or "postgresql"
  category: "3"          # Category number, 1 through 10
  query_id: "3.1"

Query Routing by User Symptom:

User Reports	Category	Queries to Run
"high CPU"	6 (Performance)	6.1, 6.2, 6.4
"too many connections"	3 (Activity)	3.1, 3.2
"slow queries"	6 (Performance)	6.1, 6.3
"replication lag"	4 (Replication)	4.1, 4.2
"storage full"	5 (Storage)	5.1, 5.2, 5.3
"deadlocks" / "lock waits"	3 (Activity)	3.3, 3.4
"full health check"	9 (Summary)	9.1 (then expand failing dimensions)
"index optimization"	8 (Optimization)	8.1, 8.2
"auto-increment overflow"	7 (Maintenance)	7.1

If MCP is unavailable, fall back to:

1. CloudWatch Metrics (Layer 2) for performance indicators
2. CloudWatch Logs Insights (Layer 2) for slow query and error log analysis
3. AWS CLI (Layer 1) for configuration validation
4. Document the queries in the response so users can run them manually

See references/mysql-health-checks.md for all 23 MySQL queries and references/postgresql-health-checks.md for PostgreSQL queries.

---

Phase 5: Correlation Engine

CORRELATION RULES:
- High CPU + Slow Queries in logs → Identify top CPU-consuming queries
- Connection spike + "Too many connections" in error log → Connection exhaustion
- Replica Lag spike + Long transactions on writer → Writer blocking readers
- High IOPS + Large table scans → Missing indexes
- Storage growth + Fragmentation > 20% → OPTIMIZE TABLE needed
- MaximumUsedTransactionIDs > 1B (PG) → Wraparound risk
- Temp files detected (PG) + Low work_mem → Memory tuning needed

---

Phase 6: Recommendation Generation

For each finding, generate recommendations in this priority order:

1. Immediate (CRITICAL) — Data loss or availability risk
2. Short-term (WARNING) — Performance degradation or security gap
3. Planned (INFO) — Best practice alignment, optimization opportunity

---

AWS CLI Tool Usage

Layer 1: Control Plane

Tool	Purpose	Command
Describe Cluster	Full cluster configuration	aws rds describe-db-clusters --db-cluster-identifier <id>
Describe Instance	Instance-level configuration	aws rds describe-db-instances --db-instance-identifier <id>
Check Versions	Version currency	aws rds describe-db-engine-versions --engine <engine>
Cluster Parameters	Parameter group settings	aws rds describe-db-cluster-parameters --db-cluster-parameter-group-name <name>
Auto Scaling	Read replica scaling config	aws application-autoscaling describe-scalable-targets --service-namespace rds
Log Files	Available log file listing	aws rds describe-db-log-files --db-instance-identifier <id>

Layer 2: CloudWatch Metrics

Collect key metrics for health assessment (3h window, 300s period):

aws cloudwatch get-metric-data --metric-data-queries '[...]' --start-time <3h-ago> --end-time <now>

Metrics and Thresholds:

Metric	🟢 OK	🟡 WARNING	🔴 CRITICAL
CPUUtilization	< 70%	70-90%	> 90%
DatabaseConnections	< 80% of max	80-90%	> 90%
FreeableMemory	> 2 GB	1-2 GB	< 1 GB
AuroraReplicaLag	< 100ms	100-1000ms	> 1000ms
VolumeReadIOPs	Context-dependent	—	Sudden 3x+ spike
VolumeWriteIOPs	Context-dependent	—	Sudden 3x+ spike
MaximumUsedTransactionIDs	< 1 Billion	1-1.5B	> 1.5B (PG only)

Layer 3: CloudWatch Logs Insights

Slow Query Log (Aurora MySQL):

Log group: /aws/rds/cluster/<cluster-id>/slowquery
Query: fields @timestamp, @message | filter @message like /Query_time/ | sort @timestamp desc | limit 50

Error Log (Aurora MySQL):

Log group: /aws/rds/cluster/<cluster-id>/error
Query: fields @timestamp, @message | filter @message like /ERROR|Warning|Note/ | stats count(*) by bin(1h)

PostgreSQL Log:

Log group: /aws/rds/cluster/<cluster-id>/postgresql
Query: fields @timestamp, @message | filter @message like /ERROR|FATAL|PANIC|duration/ | sort @timestamp desc | limit 50

---

Report Format

## Health Check Report

**Engine:** <engine-type> | **Cluster:** <cluster-id> | **Version:** <version>
**Writer:** <writer-id> | **Readers:** <count> (<ids>)
**Assessment Date:** <timestamp>

### Overall Health Score: <score>/<max> (Grade: <letter>)

### Health Dimensions
| Dimension | Score | Status |
|-----------|-------|--------|
| <dimension> | <0 or 5> | 🟢/🔴 |

### Critical Issues
❌ <Dimension>: <Issue> — <Impact> — <Remediation>

### Performance Metrics (Last 3 Hours)
| Metric | Min | Max | Average | Latest |
|--------|-----|-----|---------|--------|

### Recommendations (Priority Order)
1. 🔴 [CRITICAL] <action> — <expected outcome>
2. 🟡 [WARNING] <action> — <expected outcome>
3. 🟢 [INFO] <action> — <expected outcome>

---

Error Pattern Recognition

Aurora MySQL Error Log Patterns

Pattern	Meaning	Severity	Action
Too many connections	Connection limit reached	🔴 CRITICAL	Implement RDS Proxy, increase max_connections
Aborted connection	Client disconnected unexpectedly	🟡 WARNING	Check application connection handling
Deadlock found	Transaction deadlock detected	🟡 WARNING	Review transaction ordering, add indexes
InnoDB: page_cleaner	Buffer pool pressure	🟡 WARNING	Scale up instance class
Lock wait timeout exceeded	Lock contention	🔴 CRITICAL	Identify blocking transaction

Slow Query Patterns

Pattern	Likely Cause	Fix
High Query_time + High Rows_examined	Missing index	Add composite index on WHERE/JOIN columns
High Query_time + Low Rows_examined	Lock waiting	Resolve lock contention
Many queries with same DIGEST	Hot path query	Optimize or cache result
Temp table on disk	TEXT/BLOB or large GROUP BY	Restructure query, increase tmp_table_size

---

Platform Differences: Aurora MySQL vs RDS MySQL

Aspect	Aurora MySQL	RDS MySQL
Storage	Shared distributed volume (auto-scales to 128 TiB)	EBS-backed (manual provisioned IOPS)
Replication	Redo log-based (< 20ms typical)	Binlog-based (seconds to minutes)
Failover	30 seconds typical	1-2 minutes
Buffer Pool	Auto-warmed after restart	Cold start after restart
Backtrack	Supported (rewind without restore)	Not available
Read Replicas	Up to 15, same storage volume	Up to 5, async binlog
Monitoring	mysql.ro_replica_status available	SHOW REPLICA STATUS only

---

Constraints

NEVER DO:

• Execute DDL (CREATE, ALTER, DROP), DML (INSERT, UPDATE, DELETE), or DCL (GRANT, REVOKE)
• Expose database credentials in any output
• Make configuration changes directly — always recommend, never execute
• Assume engine type — always detect via API
• Provide recommendations without supporting data
• Skip severity classification on findings

ALWAYS DO:

• Detect platform before running diagnostics
• Include query numbers for traceability
• Provide interpretation thresholds (OK/WARNING/CRITICAL) with every metric
• Offer follow-up diagnostic paths after presenting findings
• Note when a diagnostic requires database-level access vs. API-only
• Include Aurora-specific context (shared storage, < 100ms expected lag, buffer pool auto-management)

---

Example Workflows

Workflow 1: Troubleshooting High CPU Usage

User Query: "My Aurora MySQL cluster has high CPU usage."

1. Check CloudWatch CPU metrics via aws cloudwatch get-metric-data
2. Query CloudWatch Logs Insights on slow query log for correlating queries
3. Reference Query 3.1 (Connection Overview) for running threads
4. Reference Query 6.2 (Top 10 CPU Intensive Queries)
5. Reference Query 6.4 (Index Usage Statistics) for missing indexes
6. Interpretation: Running threads > 50 = CRITICAL, > 20 = WARNING
7. Recommend: Add missing indexes, optimize slow queries, consider read replicas

Workflow 2: Comprehensive Health Assessment

User Query: "Perform a full health check on my Aurora MySQL cluster."

1. Run AWS CLI checks for configuration (encryption, Multi-AZ, backups, PI)
2. Collect CloudWatch metrics (CPU, connections, IOPS, replica lag)
3. Reference Query 1.1 (Server Information) and 1.2 (Environment Detection)
4. Reference Query 2.1 (Critical MySQL Variables) for config validation
5. Reference Query 9.1 (Overall Health Score) for 8-dimension DB scoring
6. Combine AWS-level and database-level findings
7. Provide prioritized recommendations by grade

Workflow 3: Connection Exhaustion

User Query: "Getting 'Too many connections' errors."

1. Check CloudWatch DatabaseConnections metric
2. Query CloudWatch Logs for error patterns
3. Reference Query 3.1 (Connection Overview) — current vs max
4. Reference Query 3.2 (Thread Details) — identify sources
5. Interpretation: > 90% = CRITICAL, > 80% = WARNING
6. Recommend: Implement RDS Proxy, increase max_connections, fix connection leaks

Workflow 4: Replication Lag

User Query: "My Aurora read replica has high lag."

1. Check CloudWatch AuroraReplicaLag metric
2. Query CloudWatch Logs for errors on reader instances
3. Reference Query 4.2 (Aurora Replica Lag Detail)
4. Reference Query 3.3 (Active Transactions) on writer
5. Interpretation: Aurora > 100ms = WARNING (unusual), > 1000ms = CRITICAL
6. Recommend: Check heavy reader workloads, long writer transactions, scale reader

Workflow 5: PostgreSQL Transaction ID Wraparound

User Query: "Check for transaction ID wraparound risk."

1. Check CloudWatch MaximumUsedTransactionIDs metric
2. Reference PG Query 7.2 (Database Transaction ID Age)
3. Reference PG Query 7.3 (Top 5 Aged Tables)
4. Interpretation: Age > 1.5 billion = CRITICAL, > 1 billion = WARNING
5. Recommend: Run manual VACUUM immediately, tune autovacuum_freeze_max_age
6. Emphasize: Wraparound causes database shutdown at 2 billion transactions