Modernizing Java Apps and Data on Azure Part Two: Migrating Data

The first article of this series set up the PetClinic app, and now it’s time to move the application’s data. Migrating data always requires checking the source and receiving server capability details. Microsoft provides detailed overviews of their MySQL and PostgreSQL platforms. These offerings run the original databases wrapped by the additional services you need for reliable, secure operation.

First, check what versions the target service supports. Ensure that migrating from an older version to a new version is supported. Then, note the application bandwidth and latency requirements. These are always important considerations, especially when you’re migrating from an on-premise server to a cloud server. Finally, once you know you can migrate the data to a supported version and make data available at acceptable rates, ensure the data is secure.

Microsoft's Azure Database for PostgreSQL versioning policy shows that versions 10 through 14 are compatible with various server configurations. Since version 10 came out in 2017, most current implementations can move to a compatible version.

Microsoft also provides a latency speed test to various data centers. Note that latency from an application hosted locally to cloud data services will always be higher than in-house data services. So, you should monitor data use before and after the migration to find performance optimization opportunities.

Usually, database tuning focuses on operation times, but network performance can be the primary concern when running on cloud services. Chatty, high-bandwidth applications constantly interacting with the server may need to cache data and make fewer calls or rely on publish-and-subscribe push notifications to receive data when created or updated. Review application requirements to determine if the application can wait a few seconds to notify the user that a new message is available instead of informing the user instantly. Sometimes, applications perform the way they do because they have the resources, not because there are specific requirements for that performance.

The significance of latency fades after the application and data are in the cloud. Microsoft publishes internal “region to region” latency reports to help. The ability to reduce latency by deploying a database in a specific region along with the application it serves may provide an opportunity to improve application performance.

Once the data is available, securing it becomes paramount. Microsoft’s documentation on the security methods available for a Flexible Server says role auditing is supported. So, you can review the privileges associated with each role. The server encrypts the stored data “at rest,” so you don’t need to worry about someone capturing it by copying the database files.

Firewall rules determine whether a request reaches the server, so consider which IP address ranges it should access. You’ll encounter the firewall selections later when you create your server. In this tutorial, the application has direct access to the database, so you’ll need to ensure the application is secure since anyone who has access to the application will have access to the database.

Now that you’ve reviewed the product and determined that the Azure Database for PostgreSQL is a good match for your application, use the following migration process:

• Export the data from the local database
• Create the Azure database
• Recreate the database in the cloud
• Connect the application to the new database

You’ll use the Azure portal to create the database, the Postgres command-line client to configure the database and migrate data, and IntelliJ to run the application.

Exporting Data from the Local Database

Assuming you’ve run the sample application and your local Postgres server is running, you can open an MS-DOS command window and execute this command to generate a database backup:

C:\Projects\PetClinic\postgresDb> pg_dump --inserts --create petclinic > local_backup.pg

Creating the Azure Database

Start creating the cloud database by logging into the Azure Portal and clicking Create a resource on the Dashboard. Type in “Postgr” to start the search and click Azure Database for PostgreSQL.

Then click Create.

Select the Flexible server option and click Create.

Then, start configuring the database server by selecting (or creating) a resource group.

Set the Server name field and Workload type in the Server details section. The Spring Boot PetClinic demo is small, so pick the Development option for this tutorial.

In the Compute + storage section, you’ll find the following settings. This server is the smallest available, and it’s all you need for this project. If you’re implementing a larger project, click Configure server to see the full range of choices (two to sixty-four cores with up to 16384 GB storage at 18000 IOPs). Pick the latest PostgreSQL version available. There aren’t any availability preferences, so accept the defaults for the Availability zone and Enable high availability.

Moving down, set the Admin username and set the Password to “P@ssword” (it’s not a safe choice, but you’ll need it later for this tutorial).

At the bottom of the blade, click Next > Networking.

By default, the server isn’t accessible. The server’s hostname is public, and any requests made to the host go to the Azure network. This setup would be a concern in regular operation. Still, the default security settings protect the database while you configure it by blocking all requests until you set rules to accept them.

To help configure the firewall, Microsoft provides an option that allows Azure services to interact with the database. This is an easy way to enable Azure Functions to connect with the database, but you’ll need to ensure those services are secure before allowing it. Enable it for this tutorial because this is demonstration data.

Microsoft also provides a link to open the firewall to your local machine and a link to give full public access. Enable access from the local device, but block public access. You can add additional firewalls to allow access to specific services.

Finally, click Review + create to go to the next page, where you can review the settings.

Click Create to create the server. The deployment takes a few minutes, and during this time, you’ll see a “Deployment is in progress” message like this screenshot:

Recreating the Database in the Cloud

Now you can migrate the data to the online server. Open the Overview page for the resource to find the server’s hostname (you already know the administrator login name).

Connect to the server using the interactive Postgres client and execute the commands below. The password is “P@ssword”:

C:\Projects\PetClinic\postgresDb> psql -h pet-clinic-demo.postgres.database.azure.com 
                                       -U petClinicAdmin -d postgres
Password for user petClinicAdmin:
psql (14.1, server 13.4)
WARNING: Console code page (437) differs from Windows code page (1252)
         8-bit characters might not work correctly. See psql reference
         page "Notes for Windows users" for details.
SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=> create user petclinic password 'petclinic';
CREATE ROLE
postgres=> GRANT petclinic TO "petClinicAdmin" WITH ADMIN OPTION;
GRANT ROLE
postgres=> create database petclinic owner petclinic;
CREATE DATABASE
postgres=>

Then, migrate the data to the database using the following command:

C:\Projects\PetClinic\postgresDb> psql -h pet-clinic-demo.postgres.database.azure.com 
                                       -U petclinic -f local_backup.pg petclinic

Connecting the Application to the New Database

Finally, you need to connect the application to the database. In IntelliJ, open the application-postgres.properties file in the src/main/resources folder, and change the server URL to point to the new server:

spring.datasource.url=${POSTGRES_URL:jdbc:postgresql://pet-clinic-demo.postgres.database.azure.com/petclinic}

Then, restart the application and open the application home page.

Verifying the New Server’s Connection

You can verify that the application uses the new server from the startup log.

Monitoring the Database

Azure provides tools for monitoring database traffic. You can use these tools to verify that applications connect to the new database and gain the tuning metrics discussed at the beginning of this article. Microsoft describes the available metrics and the monitoring platform if you aren’t familiar. You can build dashboards providing overviews of a set of resources or detailed metrics on a single resource, like in this screenshot:

Next Steps

And with that, the database is fully migrated, and the application is ready to use the new data services.

This article provided an overview of all aspects of the data migration process, from initial considerations like versioning, connectivity, and network security to operational considerations such as monitoring. There’s much more to learn, but now you have a working database and can follow links to related articles covering all the platform’s features.

Continue to the following article to migrate the application to Azure App Services and take the next step in migrating to the cloud.

If you'd like to discuss a specific Java app migration scenario with the Microsoft Java on Azure team, please fill out this questionnaire and a representative will contact you.