Skip to content

PostgreSQL RDS Primary stuck in 'Backing Up' state for long time

0

We have a Production RDS PostgreSQL Primary and Read replica. We restored data from an old primary database into the primary and renamed the read replica to the old name. Meanwhile backup got kicked automatically on the primary. It has been more than 3 hours now that it is in "Backing Up" state. We need to rename the primary as well so that our application points to it. Any pointers? Help Please.

asked 2 years ago753 views

1 Answer
0

Hi Suresh!

Let’s dig into your PostgreSQL RDS issue step by step and ensure you have everything you need to resolve it effectively. 😊


Clarifying the Issue

Your primary PostgreSQL RDS instance is stuck in the "Backing Up" state after restoring data and renaming a read replica. This state has persisted for over three hours, delaying further configuration adjustments like renaming the primary to align with your application requirements.


Key Terms

  • PostgreSQL RDS: A managed PostgreSQL database solution offered by AWS as part of its Relational Database Service.
  • Backing Up State: A state where the instance is undergoing a backup operation. If prolonged, it may signal an underlying issue.
  • Read Replica: A read-only copy of the database for scaling reads or disaster recovery.
  • CloudWatch: AWS's monitoring service that tracks performance and operational data, useful for troubleshooting RDS backups.

The Solution (Our Recipe)

Steps at a Glance

  1. Use CloudWatch to inspect the backup process logs.
  2. Verify backup settings, backup windows, and potential conflicts.
  3. Analyze storage usage and large tables for potential delays.
  4. Take corrective action or escalate to AWS support as needed.
  5. Plan proactive measures to avoid similar issues in the future.

Detailed Steps

  1. CloudWatch Logs Inspection:
    • Navigate to CloudWatch Logs Insights in the AWS Console.
    • Select the log group associated with your PostgreSQL RDS instance (e.g., /aws/rds/instance/[InstanceName]/postgresql).
    • Run a query to filter for backup-related activities. Use this example:
      fields @timestamp, @message
      | filter @message like /backup/
      | sort @timestamp desc
      | limit 50
    • Look for entries such as "Backup started", "Backup completed", or potential error messages like:
      • "Backup process exceeded threshold time"
      • "Unable to flush snapshot to S3".
        These errors often indicate issues with storage, network connectivity, or backup size.

  1. Backup Settings Review:
    • In the RDS Console, inspect the automated backup retention settings under Backup & Restore.
    • Confirm no manual snapshots were initiated that might conflict with automated backups.
    • Review the Backup Window Configuration: Ensure the backup window doesn’t overlap with high-load periods or maintenance events.

  1. Analyze Storage and Large Tables:
    • Oversized tables can significantly delay backups. Query the database with the following SQL to locate large tables:
      SELECT relname AS table_name,
             pg_size_pretty(pg_total_relation_size(relid)) AS size
      FROM pg_catalog.pg_statio_user_tables
      ORDER BY pg_total_relation_size(relid) DESC;
    • Monitor storage metrics in CloudWatch:
      • Disk Space Utilization: Ensure the storage isn’t nearing full capacity.
      • IOPS Metrics: Check for unusual spikes or sustained activity in VolumeWriteIOPs and VolumeReadIOPs.

  1. Take Corrective Action or Escalate:
    • If logs indicate a stalled backup, restarting the RDS instance may clear the issue. Ensure the application can tolerate downtime before proceeding.
    • If the backup appears unusually large or if restarting isn’t viable, open a high-priority support ticket with AWS. Provide the gathered logs, metrics, and query results for faster resolution.

  1. Plan Proactive Measures:
    • Optimize Table Sizes: Use tools like pg_repack to remove bloat from oversized tables and improve performance. This can significantly reduce backup times.
    • Regular Testing: Perform routine tests of your backup and restoration processes in a non-production environment to identify potential bottlenecks.
    • Partitioning: Consider partitioning large tables to improve data management and reduce backup overhead.
    • Backup Scheduling: Schedule backups during periods of low traffic to minimize the impact on performance and reduce contention for resources.

Closing Thoughts

Suresh, these enhanced steps should give you everything needed to diagnose and resolve the issue effectively. Leveraging CloudWatch, database insights, and proactive optimizations will not only resolve this problem but also set you up for smoother operations moving forward. Let me know if there’s anything else you need—I’m happy to help refine further! 🚀


Best wishes, Suresh! Feel free to reach out with updates or further questions. 😊✨


Cheers, Aaron😊

answered 2 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.