I have begun writing a few blog posts focused on launching your databases into the cloud. Specifically targeted on database migration methodologies. Choosing a migration method involves making a lot of decisions up-front. This post will assume that Managed Relational Database Service (RDS), which is a Platform as a Service offering by Amazon Web Services (AWS), has been chosen. Also, this post will focus on a homogeneous database migration between an on-premises Microsoft SQL Server database and a SQL Server database on RDS.
How to use Database Migration Service
The AWS Database Migration Service (DMS) aids in migrating databases from several different data platforms to Amazon EC2, Amazon RDS, and Amazon Redshift instances. It can be setup to copy your database in a single full load or load and continue to replicate changes, keeping the target database up-to-date.
Setting up DMS is simple. The architecture is comprised of, the source database, the target database, an endpoint for each database, and a replication instance.
This walk through is going to start with an on-premises Microsoft SQL Server already in existence and no AWS resources instantiated, yet.
Building a SQL Server database in Amazon RDS
There are many sizing and parameter decisions to make when creating an Amazon RDS database. For the purposes of this demonstration the AWS Free Tier will be used. The free tier limits some of the choices but this is not a problem because the focus of the article is DMS, not the intricates of RDS.
Begin building the database by logging into the AWS console. Search for and select RDS.
Select Instances and then Launch DB Instance.
Select Microsoft SQL Server Express.
Configure the database according to performance and size needs. Given that this demonstration is in the free tier, db.t2.micro is selected with the included, and free, SQL Server Express license. I was impressed to see SSD storage in the free tier.
Define a unique database instance identifier and the initial SQL authentication account.
Clicking next will bring up the networking and instance configuration options. Ensure that the instance is publicly accessible and allow the wizard to create a new security group. Leave the rest of the options default and click Launch DB Instance.
AWS can take up to 20 minutes to provision a new database instance. Given how small this instance is, it takes closer to 5 minutes. The instance cannot be connected to until its status is available. The endpoint information is listed when the instance is selected in the console.
Configuring network security
Once at the VPC dashboard, go to Security Groups, select the group created by the RDS wizard, and create a new inbound rule. In the screenshot below, I have added a rule for my home network’s public IP address. It is also possible to create a rule for 0.0.0.0/0 which opens up all TCP traffic. Later in this post, a rule will need to be created to allow the DMS replication instance to connect.
Setting up the Database Migration Service
Once again, from the AWS console, search for and select DMS.
Click on Get Started.
Like most wizards in the world, this one begins with a welcome page. One important piece of information that is provided, however, is the tip about using the AWS Schema Conversion Tool. The conversion tool is most useful for heterogeneous migrations, such as Oracle to RDS Microsoft SQL Server. This demonstration is using homogeneous data platforms; therefore, it is not needed.
Leave most of the replication instance choices default. A name and description is required. Then, expand the advanced section.
In the advanced section, select the security group that was used to create the RDS instance. This will make connectivity a little bit easier. Then, click next to move on.
The replication instance will begin to build at this time. Populate the endpoint information for the source and destination connections. The endpoints to each will need to pass a connection test, located at the bottom of the page. The tests are not available until the replication instance is built, however.
The next, and final, page defines the replication task. This demonstration is going to focus on a single full load of the database into RDS. Allowing DMS to configure SQL Server Transactional Replication for on-going data updates, is also an option.
If there is LOB data in the database, make sure to select Full LOB mode to avoid truncation of data. In Limited LOB mode, default, DMS will truncate all LOB values to the maximum bytes which is configured.
I highly recommend enabling logging. DMS works well and is reliable but, if there are any problems, the log becomes invaluable for troubleshooting.
Finally, there must be at least one inclusion rule. If the entire database is to be migrated, the rule can have a wild card (%) in both the schema and table name fields. Multiple rules can be created to cover only the objects that are desired to be included in the migration.
After clicking create task, the task will begin to build. Selecting the task and navigating to the logs tab will present a link to Cloud Watch and the log stream. If you did not create a security rule for TCP 0.0.0.0/0, earlier in this process, then you will need to navigate to the replication instances page. Record the IP address so it can be added as a new security rule in your security group.
In addition to the logs, the replication status can easily be viewed in the table statistics tab and the high-level status columns in-line with the task selector.
Once all of the tables are completed, the full load is done. The hardest part of this process is connecting the replication instance to the source and destination and that is not difficult at all. All of the synchronization process is handled behind the scenes. It is one of the easiest methods that I know of for migrating an on-premises database into a PaaS database.