Deploy Apache Tomcat connected to MySQL Database Service

Apache Tomcat® is an open source Java application server. It implements the Java Servlet, JavaServer Pages, Java Expression Language and Java WebSocket technologies.

MySQL Database Service is a fully-managed Oracle Cloud Infrastructure native service. It's developed, managed, and supported by the MySQL team at Oracle. Tasks such as backup and recovery, database and operating system patching, and so on are automated. You are responsible solely for managing your data, schema designs, and access policies.


The reference architecture contains a load balancer, an application tier with Apache Tomcat, and a database tier with an HA-enabled MySQL Database Service.

The components are located in different subnets. The load balancer is in a public subnet. The Tomcat servers share a private subnet and the database is in its own private subnet. All external access is through the load balancer via an Internet gateway.

The HA-enabled MySQL Database Service is an abstraction of a cluster. It has three MySQL instances but with a single endpoint. One instance is the Primary and the other two instances are the Secondaries. The Primary has the single endpoint, allowing reads and writes to the database. The Secondaries receive replicated data from the Primary. No direct access is allowed to the Secondaries.

In case of failure or manual switchover, one of the Secondaries becomes the new Primary and the endpoint is redirected to it. This means that the endpoint IP address never changes and there is no need to update the application.

A sample application that shows application session management using the database is included.

The following diagram illustrates this reference architecture.

Description of architecture-deploy-tomcat-mds-ha.png follows
Description of the illustration architecture-deploy-tomcat-mds-ha.png

If the subnet is regional, the three MySQL instances are placed across different Availability Domains and Fault Domains. In regions with a single Availability Domain, the MySQL instances are placed across different Fault Domains within the same Availability Domain.

The architecture has the following components:

  • Region

    An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).

  • Availability domains

    Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.

  • Fault domains

    A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.

  • Virtual cloud network (VCN) and subnets

    A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.

  • Load balancer

    The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.

  • Security list

    For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.

  • Route table

    Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.

  • Internet gateway

    The internet gateway allows traffic between the public subnets in a VCN and the public internet.

  • Tomcat servers

    The Tomcat servers host the Java Servlet, JavaServer Pages, Java Expression Language, and Java WebSockets. Your applications exist in this layer.

  • Database servers

    Tomcat can connect to any database that offers Java Database Connectivity (JDBC). This architecture uses MySQL Database Service.

  • Bastion host

    The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.


Your requirements might differ from the architecture described here. Use the following recommendations as a starting point.

  • VCN

    When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.

    Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.

    After you create a VCN, you can change, add, and remove its CIDR blocks.

    When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.

  • Load balancer

    This architecture uses a 10-Mbps load balancer which is included in the Always Free tier. Depending on the number of simultaneous connections needed and on the total throughput, you can use larger shapes. The throughput can be edited at any moment.

    We recommend that you use DNS names because the load balancer’s IP address can’t be reserved.

  • Instances

    All tenancies get two Always Free Compute virtual machine (VM) instances, which this architecture uses for the Tomcat servers.

    If more processing power is required, you can select different shapes.

  • Database systems

    Connecting to MySQL: Install the latest MySQL client and also install MySQL Shell from the MySQL Yum Repository. See the More Information section for a link to using the MySQL Yum repository.

  • Storage

    The instances in this architecture use regular block storage; no extra performance is required.

  • Network connectivity

    You can manage the environment by connecting to your existing on-premises infrastructure by using a site-to-site VPN or a dedicated connection with FastConnect.

    If the environment needs to be segregated from the existing infrastructure or accessed externally, a bastion host can secure the management connections. The bastion host is typically provisioned in a demilitarized zone (DMZ). It protects sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. You can avoid exposing the more sensitive components of the architecture without compromising access to them.


Consider the following points when deploying this reference architecture.

  • Performance

    You can adjust the performance to match the application-specific needs by changing the instance shapes (if using Intel series), or OCPU and memory separately (if using AMD series).

    The database instance cannot be changed at the moment. Choose the adequate size when you create it.

  • Security

    Except for the bastion host (if present) and load balancers, all the components should be placed in private subnets.

    If rigorous security is required, please consider taking advantage of Oracle Security Zones. It's included at no extra cost.

  • Availability

    The load balancer comes with a standby instance and requires no intervention if failover occurs.

    The Tomcat servers are deployed as a pair and are balanced by the load balancer. Each Tomcat instance is located in a different fault domain.

    Back up your database as often as required to match your intended recovery point objective (RPO).

    Although infrequent, adjust the maintenance window for MySQL Database Service to match your organization's needs.

  • Cost

    The cost of this architecture changes based on the size and shapes of the instances, database, and load balancers. There are no components with variable costs.


The code required to deploy this reference architecture is available in GitHub. You can pull the code into Oracle Cloud Infrastructure Resource Manager with a single click, create the stack, and deploy it. Alternatively, download the code from GitHub to your computer, customize the code, and deploy the architecture by using the Terraform CLI.

  • Deploy by using Oracle Cloud Infrastructure Resource Manager:
    1. ClickDeploy to Oracle Cloud

      If you aren't already signed in, enter the tenancy and user credentials.

    2. Review and accept the terms and conditions.
    3. Select the region where you want to deploy the stack.
    4. Follow the on-screen prompts and instructions to create the stack.
    5. After creating the stack, click Terraform Actions, and select Plan.
    6. Wait for the job to be completed, and review the plan.

      To make any changes, return to the Stack Details page, click Edit Stack, and make the required changes. Then, run the Plan action again.

    7. If no further changes are necessary, return to the Stack Details page, click Terraform Actions, and select Apply.
  • Deploy using the Terraform code in GitHub:
    1. Go to GitHub.
    2. Clone or download the repository to your local computer.
    3. Follow the instructions in the README document.

Change Log

This log lists only the significant changes: