Migrating to an Amazon RDS for MySQL, PostgreSQL, or Aurora MySQL Instance

This topic tells you how to migrate to an instance of the Tanzu Cloud Service Broker for AWS tile from any of the following:

Amazon Relational Database Service (Amazon RDS) for MySQL instance of the VMware Tanzu Service Broker for AWS tile
PostgreSQL instance of the VMware Tanzu Service Broker for AWS tile
Aurora MySQL instance of the VMware Tanzu Service Broker for AWS tile

About Migrating Data to an Amazon RDS for MySQL, PostgreSQL, Aurora MySQL, or SQL Server Instance

Because the VMware Tanzu Service Broker for AWS (hereafter referred to as the legacy broker) tile is going out of support, you must move from instances that the legacy broker created over to service instances that Cloud Service Broker for AWS created.

The Cloud Service Broker for AWS plans are configurable. When migrating, examine the configuration of the plans in use with the legacy broker and create matching plans in Cloud Service Broker for AWS.

You can use the AWS Data Migration Service (DMS) to migrate data between Amazon RDS instances (DMS is mandatory for SQL Server). The tool copies data from one database to another. Because the original database is not modified, you can reverse the migration if you detect any problems. It also enables migration to happen over time.

The DMS is a tool provided as part of AWS. For more information about AWS DMS, see the AWS documentation.

Matching Configuration

Both the legacy broker and Cloud Service Broker for AWS allow you to customize service plans.

Create plans in Cloud Service Broker for AWS that match the plans used in the legacy broker. It might be useful to create a test service instance and compare the properties in the AWS console. For how to configure plans, see Configure Services with Cloud Service Broker for AWS.

Migrating Data

You might want to migrate data from instances created with the legacy broker to instances created with Cloud Service Broker for AWS.

Important
Migration of data might incur app downtime. The amount of downtime depends on the method chosen.

There are many methods for performing data migration, including AWS DMS, manual data migration, and methods available from other vendors. For more information about the data migration process, see the documentation for the method that you choose.

In general, to migrate data:

Create a backup of the instance.
Create an Amazon RDS instance using Cloud Service Broker for AWS.
Replicate the data from a legacy broker instance into the newly created instance.
Unbind apps from the legacy broker instance and bind them to the newly created instance.

After the migration is completed you can stop ongoing migration and, if you want, delete the legacy broker instance.

For more detailed steps showing the Cloud Foundry commands necessary to use AWS DMS, see Migrate Data from a Legacy Instance.

Migrate Data from a Legacy RDS Instance

To migrate data from an existing legacy RDS instance to Cloud Service Broker for AWS:

Create a backup of the legacy RDS instance.
Get credentials for the legacy RDS instance details by running:
```
cf env APP-USING-LEGACY-SERVICE-INSTANCE-NAME
```
Where APP-USING-LEGACY-SERVICE-INSTANCE-NAME is the name of an app that is bound to a service instance from the legacy broker.
Inspect the VCAP_SERVICES JSON output to see the host name, database, user name, password, and port required to configure DMS.
Create a new RDS service instance using Cloud Service Broker for AWS by running:
```
cf create-service SERVICE-OFFERING SERVICE-PLAN NEW-SERVICE-INSTANCE-NAME
```
Where:
- SERVICE-OFFERING is the name of the RDS service offer selected to match the legacy instance
- SERVICE-PLAN is the name of the RDS service plan created to match the legacy instance configuration
- NEW-SERVICE-INSTANCE-NAME is the name of the new RDS service instance
Create a service key in the new RDS service by running:
```
cf create-service-key NEW-SERVICE-INSTANCE-NAME SERVICE-KEY-NAME
```
Where:
- NEW-SERVICE-INSTANCE-NAME is the name of the new RDS service instance
- SERVICE-KEY-NAME is a name that you choose for the service key

Get credentials from the service key by running:

cf service-key NEW-SERVICE-INSTANCE-NAME SERVICE-KEY-NAME

Inspect the JSON output for the host name, name, user name, password, and port required to configure the data migration.
Configure and run data migration, for example, by using AWS DMS. For how to configure data migration, see the documentation for the method you have chosen.

Important
The data migration process might create schemas and tables without granting access for other users to work with that data. You can resolve this by connecting to the database with the credentials used for DMS, and granting binding_user_group access to the schemas and tables.

Alternatively if you are not using a continuous migration method, such as AWS DMS change data capture (CDC), delete the service key used for data migration. This re-assigns data ownership to the binding_user_group role, automatically giving access to other users.
Disconnect the app from the legacy service binding by running:
```
cf unbind-service APP-NAME LEGACY-SERVICE-INSTANCE-NAME
```
Where:
- APP-NAME is the app using the old AWS RDS instance.
- LEGACY-SERVICE-INSTANCE-NAME is the name of the VMware Tanzu Service Broker for AWS-brokered RDS instance.
Bind the app to the new service instance by running:
```
cf bind-service APP-NAME NEW-SERVICE-INSTANCE-NAME
```
Where NEW-SERVICE-INSTANCE-NAME is the name of the Cloud Service Broker for AWS service instance that you created earlier.

For example:
```
 $ cf bind-service my-app my-csb-aws-instance
 
```
Because Cloud Service Broker for AWS creates new credentials at bind time, this creates new binding credentials for the app.
Update the app to consume the new binding credential format:
RDS PostgreSQL
Restage the app by running:
```
cf restage APP-NAME
```
RDS MySQL, RDS Aurora MySQL, or SQL Server
The legacy binding exposes the database name in the credentials block as database, whereas the binding credentials received from Cloud Service Broker for AWS exposes the database name as name. You must update the consuming app to handle the name credential property. Push and start the app by running:
```
cf push APP-NAME
```
After the migration finishes, you can stop continuous migration and remove the legacy service instance.

Important
The legacy broker does not support the aurora-postgresql engine, therefore it is not mentioned in this tutorial. The migration between the same flavors of RDS instances but different services has not been tested. In other words, the migration between an Amazon RDS for MySQL Instance and an Amazon RDS for Aurora MySQL has not been tested, and such testing is beyond the scope of this topic.