Microsoft Azure – Database Availability and Consistency For Azure SQL

 When you or your company decides to move your database from your on-premise servers/computers to a cloud environment, consistency and availability are two important factors to consider.

Database consistency is much more intricate. It means that no matter how or where you access your data, the same query would give you the same data output.  It also means that your data stays intact in case of an application failure, natural disaster, and so on.  

In this article, we aim to simplify how Azure Database for MySQL achieves the objectives of data consistency and high availability, across different deployment options. We will get an overview of the following concepts:

  • Understanding the 2 deployment modes Azure offers
  • Availability and consistency for single-server deployment.
  • Availability and consistency for flexible deployment.


Key Terminologies

Before getting started get yourself familiar with the following keywords:

  • PaaS:  Platform as a Service
  • Instance: Virtual servers running on physical hardware (In this case, Azure)
  • SLA: Service Level Agreement


Deployment Modes in Azure

Azure Database for MySQL is a PaaS (Platform as a service). This means that Azure provides you with an instance (or multiple instances) of the MYSQL server. Everything from patching to upgrades is handled by Azure. For this mode, there are 2 available deployment options-

  1. Single Server Deployment: This option is only recommended if you currently have an application/workload that is using a single server, and you wish to migrate it to the Azure cloud. A single server requires minimal user customization. It provided an SLA of 99.99% availability within a single region.  
  2. Flexible Server Deployment: This option is highly recommended for production workloads. It’s flexible, allowing you to choose availability zones, pricing tiers, cost optimizations, and more.  

So now that you have a basic understanding of the deployment nodes, let’s deep dive into availability and consistency for these 2 modes.  


Availability and Consistency

For Single-Server Deployment

Planned downtime: As an example, suppose you start out with 4 virtual cores on your Azure Database instance. As you add more and more applications, your database load increases. To handle this, you might need to increase your virtual cores. This is an instance of planned downtime. As you can see in the architecture, Azure Database for MySQL is built out of separate components like

  • Gateway/proxy
  • Database server
  • Azure storage

 

  • If you need to scale up/down your compute instances, a new database server is provided. This happens with minimal downtime.
  • Scaling up storage requires no downtime.
  • Upgrades, patch fixes, and bug fixes require minimal downtime, up to 60-120 seconds at maximum. However, users are advised to eliminate heavy transactions running on their database instances at planned downtimes.
  • Unplanned downtime: Whenever your server faces unexpected downtime, Azure automatically deploys another server within a minute.  For Azure storage failures, there is no downtime. This is because data is replicated 3 times, and if one copy fails, the azure servers switch to read data from the other 2 copies.
  • You can also configure Azure read replicas (backup database copies) in multiple Azure regions to ensure Disaster Recovery (DR) in case of failures in an entire region.


For Flexible Server Deployment:

 There are 2 primary modes of design:

  • Zone Redundant Architecture: This design will create a primary database server in the availability zone (like east us). Another server with the exact same configurations will be placed in a different availability zone within the same region (like east us 2). This model provides higher fault tolerance, but higher latency in transmitting traffic.
  • Same Zone Architecture: In this design, both your primary and secondary servers are placed within the same availability zone. Data transmission is faster, latency is lower due to the servers being physically close. However, fault tolerance is lower.
  • With both architectures, users can provision read replicas for backup and database consistency. Read replicas is a read-only copy of your Azure database, designed to reduce the load on your primary server. 

Azure Database for MYSQL has a comprehensive set of services that ensure data availability and consistency. There are various options for you to choose between different servers, architectures and pay only for the services you use. 

Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Agile Retrospective

Image
  Guide to agile retrospectives for continuous improvement An agile retrospectives is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete (typically a sprint lasting two to four weeks). During the agile retrospective, the team discusses what went well, what did not go as planned, and how to make the next work period better. Even if you are not on a development team, you can probably relate to the concept of retrospection. Have you ever worked hard on something only to realize later that you should have done it differently? It is not always a good feeling, but the solutions you uncover in hindsight can be valuable input for your next try. The same goes for your successes — acknowledging what went well and is worth repeating can be just as impactful. What is an agile retrospective? In short, an agile retrospective is a meeting...
Read more

Agile product management

Image
  What is agile product management? How do we define agile product management? It is a product development philosophy that emphasizes a flexible and human — rather than a rigid process- or tool-oriented — approach to defining product strategy and carrying out work. Teammates focus heavily on customer feedback to make improvements and adjust roadmaps throughout the product management process. This creates more responsive teams, leads to quicker iterations, and creates a more lovable experience overall. Benefits of agile product management Agile redefines how product managers think about planning and building products. Traditionally, new customer experiences were planned, designed, implemented, and tested in a step-by-step way. This meant that new functionality was delivered sequentially. Once requirements were defined and handed off to the development team, it was difficult to make any changes. The failure rate of large-scale and lengthy software development proj...
Read more