brandon/oam
1
0
Fork 0
mirror of https://gitea.com/mcereda/oam.git synced 2026-02-09 05:44:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
Files
b5c4461e11f74c09a818a8ef4f77220d5f5c0ce9
oam/knowledge base/cloud computing/aws/rds.md

11 KiB
Raw Blame History

Amazon Relational Database Service

  1. TL;DR
  2. Backup
    1. Automatic backups
    2. Manual backups
    3. Export snapshots to S3
  3. Restore
  4. Encryption
  5. Further readings
    1. Sources

TL;DR

Usage 
# Show RDS instances.
aws rds describe-db-instances
aws rds describe-db-instances --output 'json' --query "DBInstances[?(DBInstanceIdentifier=='master-prod')]"

# Restore instances from snapshots.
aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier 'mynewdbinstance' \
  --db-snapshot-identifier 'mydbsnapshot'

# Start export tasks.
aws rds start-export-task \
  --export-task-identifier 'db-finalSnapshot-2024' \
  --source-arn 'arn:aws:rds:eu-west-1:012345678901:snapshot:db-prod-final-2024' \
  --s3-bucket-name 'backups' \
  --iam-role-arn 'arn:aws:iam::012345678901:role/CustomRdsS3Exporter' \
  --kms-key-id 'arn:aws:kms:eu-west-1:012345678901:key/abcdef01-2345-6789-abcd-ef0123456789'

# Get export tasks' status.
aws rds describe-export-tasks
aws rds describe-export-tasks --export-task-identifier 'my-snapshot-export'

# Cancel tasks.
aws rds cancel-export-task --export-task-identifier 'my_export'

Read replicas can be promoted to standalone DB instances.
See Working with DB instance read replicas.

Disk free metrics are available in CloudWatch.

One can choose any of the following retention periods for instances' Performance Insights data:

  • 7 days (default, free tier).
  • n months, where n is a number from 1 to 24.
    In CLI and IaC, this number must be n*31.

Backup

RDS backup storage for each Region is calculated from both the automated backups and manual DB snapshots for that Region.
Moving snapshots to other Regions increases the backup storage in the destination Regions.

Backups are stored in S3.

Should one choose to retain automated backups when deleting DB instances, those backups are saved for the full retention period; otherwise, all automated backups are deleted with the instance.
After automated backups are deleted, they cannot be recovered.

Should one choose to have RDS create a final DB snapshot before deleting a DB instance, one can use that or previously created manual snapshots to recover it.

Automatic backups

Automatic backups are storage volume snapshots of entire DB instances.

Automatic backups are enabled by default.
Setting the backup retention period to 0 disables them, setting it to a nonzero value (re)enables them.

Enabling automatic backups takes the affected instances offline to have a backup created immediately.
It will cause outages.

Automatic backups occur daily during the instances' backup window, configured in 30 minute periods. Should backups require more time than allotted to the backup window, they will continue after the window ends and until they finish.

Backups are retained for up to 35 days (backup retention period).
One can recover DB instances to any point in time from the backup retention period.

The backup window can't overlap with the weekly maintenance window for DB instance or Multi-AZ DB cluster.
During automatic backup windows storage I/O might be suspended briefly while the backup process initializes. Initialization typically takes up to a few seconds. One might also experience elevated latencies for a few minutes during backups for Multi-AZ deployments.
For MariaDB, MySQL, Oracle and PostgreSQL Multi-AZ deployments, I/O activity isn't suspended on the primary instance as the backup is taken from the standby.
Automated backups might occasionally be skipped if instances or clusters are running heavy workloads at the time backups are supposed to start.

DB instances must be in the available state for automated backups to occur.
Automated backups don't occur while DB instances are in other states (i.e., storage_full).

Automated backups aren't created while a DB instance or cluster is stopped.
RDS doesn't include time spent in the stopped state when the backup retention window is calculated. This means backups can be retained longer than the backup retention period if a DB instance has been stopped.

Automated backups don't occur while a DB snapshot copy is running in the same AWS Region for the same database.

Manual backups

Back up DB instances manually by creating DB snapshots.
The first snapshot contains the data for the full database. Subsequent snapshots of the same database are incremental.

One can copy both automatic and manual DB snapshots, but only share manual DB snapshots.

Manual snapshots never expire and are retained indefinitely.

One can store up to 100 manual snapshots per Region.

Export snapshots to S3

One can export DB snapshot data to S3 buckets.
RDS spins up an instance from the snapshot, extracts data from it and stores the data in Apache Parquet format.
By default all data in the snapshots is exported, but one can specify specific sets of databases, schemas, or tables to export.

  • The export process runs in the background and does not affect the performance of active DB instances.

  • Multiple export tasks for the same DB snapshot cannot run simultaneously. This applies to both full and partial exports.

  • Exporting snapshots from DB instances that use magnetic storage isn't supported.

  • The following characters aren't supported in table column names:

    , ; { } ( ) \n \t = (space) /

    Tables containing those characters in column names are skipped during export.

  • PostgreSQL temporary and unlogged tables are skipped during export.

  • Large objects in the data, like BLOBs or CLOBs, close to or greater than 500 MB will make the export fail.

  • Large rows close to or greater than 2 GB will make their table being skipped during export.

  • Data exported from snapshots to S3 cannot be restored to new DB instances.

  • The snapshot export tasks require a role with write-access permission to the destination S3 bucket:

    {
  "Version": "2012-10-17",
  "Statement": [{
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "export.rds.amazonaws.com"
      }
  }]
}

    {
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
        "s3:PutObject*",
        "s3:ListBucket",
        "s3:GetObject*",
        "s3:DeleteObject*",
        "s3:GetBucketLocation"
    ],
    "Resource": [
        "arn:aws:s3:::bucket",
        "arn:aws:s3:::bucket/*"
    ]
  }]
}

After the export, one can analyze the data directly through Athena or Redshift Spectrum.

In the Console

The Export to Amazon S3 console option appears only for snapshots that can be exported to Amazon S3.
Snapshots might not be available for export because of the following reasons:

  • The DB engine isn't supported for S3 export.
  • The DB instance version isn't supported for S3 export.
  • S3 export isn't supported in the AWS Region where the snapshot was created.
Using the CLI 
# Start new tasks.
$ aws rds start-export-task \
  --export-task-identifier 'db-finalSnapshot-2024' \
  --source-arn 'arn:aws:rds:eu-west-1:012345678901:snapshot:db-prod-final-2024' \
  --s3-bucket-name 'backups' --s3-prefix 'rds' \
  --iam-role-arn 'arn:aws:iam::012345678901:role/CustomRdsS3Exporter' \
  --kms-key-id 'arn:aws:kms:eu-west-1:012345678901:key/abcdef01-2345-6789-abcd-ef0123456789'
{
  "ExportTaskIdentifier": "db-finalSnapshot-2024",
  "IamRoleArn": "arn:aws:iam::012345678901:role/CustomRdsS3Exporter",
  "KmsKeyId": "arn:aws:kms:eu-west-1:012345678901:key/abcdef01-2345-6789-abcd-ef0123456789",
  "PercentProgress": 0,
  "S3Bucket": "backups",
  "S3Prefix": "rds",
  "SnapshotTime": "2024-06-17T09:04:41.387000+00:00",
  "SourceArn": "arn:aws:rds:eu-west-1:012345678901:snapshot:db-prod-final-2024",
  "Status": "STARTING",
  "TotalExtractedDataInGB": 0
}

# Get tasks' status.
$ aws rds describe-export-tasks
$ aws rds describe-export-tasks --export-task-identifier 'db-finalSnapshot-2024'
$ aws rds describe-export-tasks --query 'ExportTasks[].WarningMessage' --output 'yaml'

# Cancel tasks.
$ aws rds cancel-export-task --export-task-identifier 'my_export'
{
    "Status": "CANCELING",
    "S3Prefix": "",
    "ExportTime": "2019-08-12T01:23:53.109Z",
    "S3Bucket": "DOC-EXAMPLE-BUCKET",
    "PercentProgress": 0,
    "KmsKeyId": "arn:aws:kms:AWS_Region:123456789012:key/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "ExportTaskIdentifier": "my_export",
    "IamRoleArn": "arn:aws:iam::123456789012:role/export-to-s3",
    "TotalExtractedDataInGB": 0,
    "TaskStartTime": "2019-11-13T19:46:00.173Z",
    "SourceArn": "arn:aws:rds:AWS_Region:123456789012:snapshot:export-example-1"
}

Restore

DB instances can be restored from DB snapshots.
Instances cannot be restored with less storage.

When increasing allocated storage, increases must be by at least of 10%. Trying to increase the value by less than 10% will result in an error.
The allocated storage cannot be increased when restoring RDS for SQL Server DB instances.

aws rds restore-db-instance-from-db-snapshot \
  --db-instance-identifier 'mynewdbinstance' \
  --db-snapshot-identifier 'mydbsnapshot'

Encryption

RDS automatically integrates with AWS KMS for key management.

By default, RDS uses the RDS AWS managed key (aws/rds) for encryption.
This key can't be managed, rotated, nor deleted by users.

RDS will automatically put databases into a terminal state when access to the KMS key is required but the key has been disabled or deleted, or its permissions have been somehow revoked.
This change could be immediate or deferred depending on the use case that required access to the KMS key.
In this terminal state, DB instances are no longer available and their databases' current state can't be recovered. To restore DB instances, one must first re-enable access to the KMS key for RDS, and then restore the instances from their latest available backup.

Further readings

Sources