MySQL for Pivotal Platform v2.3 Protects Your Data with TLS, Adds Synchronous Replication for Leader-Follower

June 14, 2018 Jagdish Mirani

Perhaps the busiest person in enterprise IT: the database administrator. DBAs are tasked with keeping legacy databases tuned and running smoothly. This is Job 1, because these systems process all the vast majority of business transactions today. DBAs also have to find time to support modern microservices architectures.  Often, these modern applications are built around the edges of legacy systems. Both types of systems, legacy and modern, compete for the DBA’s time.

Compounding things, managing large legacy databases and microservices’ backing stores is a very different operational model. Legacy databases require large, dedicated staff, while the microservices backing stores are numerous and cannot be operated with the same degree of individual attention. What a quandary!

MySQL 2.3 for Pivotal Platform aims to ease the pain associated with microservices database management. Let’s take a spin through the latest round of enterprise-grade features.

Secure Communications via Transport Layer Security

Security is top of mind. Every enterprise is concerned with bad actors gaining access to its network and collecting sensitive data. One attack vector used by hackers is by watching unencrypted network traffic. This vulnerability has the potential to reveal highly sensitive customer data.

To prevent this kind of breach, MySQL for Pivotal Platform supports IPSec and has for some time. We’re excited to give customers the option to use TLS, and we’re pleased to offer TLS in MySQL v2.3 as a way of ensuring that 100% of your communications, including data in motion, is secure. This will help you protect customer data in transit. TLS can also help you comply with regulatory certifications and standards.

Getting Started with TLS in MySQL

With MySQL v2.3, operators can quickly set up TLS, without downtime. Operators don’t have to deal with the complexity of certificate generation. In the event of a security exposure, operators can manually rotate a service’s certificates. For developers, it’s easy to opt into using TLS with new and existing apps. The simplicity of setup and use of TLS allows both operators and developers to focus on business value. Data encryption “just works”!

Now, let’s take a look at how to get started with TLS.

For Operators: Initial Setup & Provisioning TLS

Figure 1. TLS Configuration Screen for Operators

First, the operator needs to prepare the Pivotal Platform foundation for TLS. This has to be done only once per foundation. To reap the benefits of TLS, you’ll need to either provide a Certificate Authority (CA) to Credhub or have Credhub generate one for you. This way, each platform service can be deployed with a server certificate. The CA is distributed across the platform. When the MySQL service publishes an encryption certificate, a client can validate that the certificate is generated by somebody it trusts before communicating across a secure channel.

Generating the Certificate Authority

Operators can use Credhub to generate a CA, or they can opt to bring their own CA,  provided by their enterprise public key infrastructure (PKI). Every instance of a multi-tenant service is distributed in the form of a BOSH deployment. This workflow related to preparing for TLS is shown in the video below.

For Developers: Using TLS

Configuring a MySQL service instance to accept TLS is the first step. Once the certificate has been provisioned, developers can accomplish this via a few simple steps.

Developers also need to modify their apps to use TLS. Depending on service client, applications must be changed in one of two ways:

  • Java and Spring apps will automatically detect if TLS is specified in VCAP_SERVICES. In order to activate TLS for Java and Spring apps, it is necessary to stop and re-bind the application.

  • Other applications need to be modified to discover the CA public key in VCAP_SERVICES. Developers will need to specify that CA component when initiating the connection to the data service. If encryption has been enabled after the service instance has been created, it will be necessary to re-bind the application, following the same process as above.

These steps related to using TLS are shown in the video below.

Use Leader-Follower to Increase the Availability of Your Database

To optimize for performance, adopt asynchronous updates. Here, the leader sends back an acknowledgment to the client as soon as it receives an update, i.e. before replicating it to the follower. This non-blocking interaction favors performance but takes on the added risk related to writes that the leader has acknowledged just before it crashes (prior to replication). These updates are now lost forever, which can be problematic because of their ‘silent’ nature. There is no easy way to identify all the updates that were missed because of a failure.

For many use cases, data consistency is the priority. Consider the case where the database is the system of record. You need a recovery point objective of zero data loss. In these cases, MySQL v2.3 can be configured for synchronous replication between the leader and follower. The acknowledgment is not sent to the client until both the leader and the follower are updated.

Typically, the leader and follower will be in different availability zones. The performance of synchronous replication is subject to the high-speed interconnections that are used across availability zones. The performance of synchronous replication is not as prohibitive as it would be over a wide-area-network.

Scaling the Administrators

The move towards distributed applications brings a commensurate move towards distribution databases and geographies. While microservices solve a lot of problems related to development velocity and release cycles, they do add an operational burden related to managing a large and growing count of database instances. MySQL for Pivotal Platform should be part of your cloud-native data strategy.

We’re on a journey to make MySQL for Pivotal Platform scalable in every way, including the administration of a large number of instances. The addition of TLS to MySQL v2.3 makes the service “secure by default.” Synchronous replication between leader and follower reduces the risk of data loss from leader failure. With these new features, ops teams have two fewer problems to worry about and can focus more time on delivering business value.

You can download MySQL v2.3 here and view the documentation here.

About the Author

Jagdish Mirani

Jagdish Mirani is an enterprise software executive with extensive experience in Product Management and Product Marketing. Currently he is in charge of Product Marketing for Pivotal's data services (Cloud Cache, MySQL, Redis, PostgreSQL). Prior to Pivotal, Jagdish was at Oracle for 10 years in their Data Warehousing and Business Intelligence groups. More recently, Jag was at AgilOne, a startup in the predictive marketing cloud space. Prior to AgilOne, Jag held various Business Intelligence roles at Business Objects (now part of SAP), Actuate (now part OpenText), and NetSuite (now part of Oracle). Jagdish holds a B.S. in Electrical Engineering and Computer Science from Santa Clara University and an MBA from the U.C. Berkeley Haas School of Business.

More Content by Jagdish Mirani
Previous
Keep Your App Platform in a Happy State: An Operator's Guide to Capacity Management on Pivotal Cloud Foundry
Keep Your App Platform in a Happy State: An Operator's Guide to Capacity Management on Pivotal Cloud Foundry

Platform operators are tasked with making sure Pivotal Cloud Foundry is in an updated, healthy state at all...

Next
Secure All the Services! How Banks Use Pivotal Cloud Foundry and the Open Service Broker API to Make It Happen.
Secure All the Services! How Banks Use Pivotal Cloud Foundry and the Open Service Broker API to Make It Happen.

Banks of all sizes are modernizing how they do IT and software development. This blog series explores how b...