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 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.
A sample application that shows application session management using the database is included.
The following diagram illustrates this reference architecture.
Description of the illustration architecture-deploy-tomcat-mds.png
The architecture has the following components:
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, private 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. You can segment VCNs into subnets, which can be scoped to a region or to an availability domain. Both regional subnets and availability domain-specific subnets can coexist in the same VCN. 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.
When you create the VCN, determine how many IP addresses your cloud resources in each subnet require. Using the Classless Inter-Domain Routing (CIDR) notation, specify a subnet mask and a network address range that's large enough for the required IP addresses. Use an address range that's within the standard private IP address space.
Select an address range that doesn’t overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or in another cloud provider) that you intend to set up private connections to.
After you create a VCN, you can't change its address range.
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.
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.
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.
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.
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.
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.
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
If you aren't already signed in, enter the tenancy and user credentials.
- Review and accept the terms and conditions.
- Select the region where you want to deploy the stack.
- Follow the on-screen prompts and instructions to create the stack.
- After creating the stack, click Terraform Actions, and select Plan.
- 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.
- 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:
- Go to GitHub.
- Clone or download the repository to your local computer.
- Follow the instructions in the
- Create a Tomcat Cluster with MySQL Session Persistence
- Using JDBCStore for Session persistence
- Getting Started with MySQL Database Service
- A Quick Guide to Using the MySQL Yum Repository (for updating the MySQL Client and for installing MySQL Shell)