Near-zero downtime migration for Linux-based Db2 databases - Amazon Relational Database Service
Near-zero downtime migration limitations and recommendations Setting up for near-zero downtime migrationMigrating your Db2 database

Near-zero downtime migration for Linux-based Db2 databases

With this migration approach, you migrate a Linux-based Db2 database from one self-managed Db2 database (source) to Amazon RDS for Db2. This approach results in minimal to no outage or downtime for the application or users. This approach backs up your database and restores it with log replay, which helps prevent disruptions to ongoing operations and provides high availability of your database.

To achieve near-zero downtime migration, RDS for Db2 implements restore with log replay. This approach takes a backup of your self-managed Linux-based Db2 database and restores it on the RDS for Db2 server. With Amazon RDS stored procedures, you then apply subsequent transaction logs to bring the database up to date.

Near-zero downtime migration limitations and recommendations

The following limitations apply to using near-zero downtime migration:

  • Amazon RDS requires an online backup for near-zero downtime migration. This is because Amazon RDS keeps your database in a rollforward pending state as you upload your archived transaction logs. For more information, see Migrating your Db2 database.

  • You can't restore from an Amazon S3 bucket in an AWS Region that is different from the Region where your RDS for Db2 DB instance is located.

  • You can't restore a database if your RDS for Db2 DB instance already contains a database.

  • Amazon S3 limits the size of files uploaded to an S3 bucket to 5 TB. If your database backup file exceeds 5 TB, then split the backup file into smaller files.

  • Amazon RDS doesn't support non-fenced external routines, incremental restores, or Delta restores.

  • You can't restore from an encrypted source database, but you can restore to an encrypted Amazon RDS DB instance.

When you restore your database, Amazon RDS copies your backup and then extracts it on your RDS for Db2 DB instance. We recommend that you provision storage space for your RDS for Db2 DB instance that is equal to or greater than the sum of the backup size plus the original database's size on disk.

The maximum size of the restored database is the maximum database size that is supported minus the size of the backup. For example, if the maximum database size that is supported is 64 TiB and the size of the backup is 30 TiB, then the maximum size of the restored database is 34 TiB.

64 TiB - 30 TiB = 34 TiB

Setting up for near-zero downtime migration

For near-zero downtime migration, you need the following AWS components:

  • An Amazon S3 bucket to store your backup files: Upload any backup files that you want to migrate to Amazon RDS. Amazon RDS requires an online backup for near-zero downtime migration. If you already have an S3 bucket, you can use that bucket. If you don't have an S3 bucket, see Creating a bucket in the Amazon S3 User Guide.

    Note

    If your database is large and would take a long time to transfer to an S3 bucket, you can order an AWS Snow Family device and ask AWS to perform the backup. After you copy your files to the device and return it to the Snow Family team, the team transfers your backed-up images to your S3 bucket. For more information, see the AWS Snow Family documentation.

  • An IAM role to access the S3 bucket: If you already have an AWS Identity and Access Management (IAM) role, you can use that role. If you don't have a role, see Step 2: Create an IAM role and attach your IAM policy.

  • An IAM policy with trust relationships and permissions attached to your IAM role: For more information, see Step 1: Create an IAM policy.

  • The IAM role added to your RDS for Db2 DB instance: For more information, see Step 3: Add your IAM role to your RDS for Db2 DB instance.

Migrating your Db2 database

After you set up for near-zero downtime migration, you are ready to migrate your Db2 database to your RDS for Db2 DB instance.

To perform a near-zero downtime migration

  1. Perform an online backup of your source database. For more information, see BACKUP DATABASE command in the IBM Db2 documentation.

  2. Copy the backup of your database to an Amazon S3 bucket. For information about using Amazon S3, see the Amazon Simple Storage Service User Guide.

  3. Connect to the rdsadmin server with the master_username and master_password for your RDS for Db2 DB instance.

    db2 connect to rdsadmin user master_username using master_password

  4. (Optional) To make sure your database is configured with the optimal settings for the restore operation, you can call rdsadmin.show_configuration to check the values for RESTORE_DATABASE_PARALLELISM and RESTORE_DATABASE_NUM_BUFFERS. Call rdsadmin.set_configuration to change these values, as needed. Explicitly setting these values can improve the performance when restoring databases with large volumes of data.

  5. Restore the backup on the RDS for Db2 server by calling rdsadmin.restore_database. Set backup_type to ONLINE. For more information, see rdsadmin.restore_database.

  6. Copy your archive logs from your source server to your S3 bucket. For more information, see Archive logging in the IBM Db2 documentation.

  7. Apply archive logs as many times as needed by calling rdsadmin.rollforward_database. Set complete_rollforward to FALSE to keep the database in a ROLL-FORWARD PENDING state. For more information, see rdsadmin.rollforward_database.

  8. After you apply all of the archive logs, bring the database online by calling rdsadmin.complete_rollforward. For more information, see rdsadmin.complete_rollforward.

  9. Switch application connections to the RDS for Db2 server by either updating your application endpoints for the database or by updating the DNS endpoints to redirect traffic to the RDS for Db2 server. You can also use the Db2 automatic client reroute feature on your self-managed Db2 database with the RDS for Db2 database endpoint. For more information, see Automatic client reroute description and setup in the IBM Db2 documentation.

  10. (Optional) Shut down your source database.