MariaDB TX 2.0 Cluster in Azure - Quick Guide

MariaDB TX 2.0 Cluster

The MariaDB TX Cluster offering in Microsoft Azure deploys 3 data/Galera nodes and 2 MariaDB MaxScale nodes, all running Ubuntu 16.04 LTS. MaxScale is automatically configured to provide Read/Write Split, Write Connection Router, and Read Connection Router services across the 3 backend nodes. The 2 MaxScale nodes are set up behind an Azure Load Balancer, configure to automatically fail over if one instance of MaxScale becomes unavailable.

You must have an Azure Subscription to be able to deploy this solution. If you use minimum VM sizes, each with 2 cores, your deployment should use 10 cores, which you should be able to deploy under the default core quota for a paid Azure subscription. Unfortunately, the Azure Free Trial has a core quota of 4 cores, which is not enough to deploy this solution. In order to deploy more than 10 cores in a single region, you may need to increase your quota. See Azure quota limitations for more information.

If you are an existing customer of subscription or other services from MariaDB Corporation, the terms of your existing agreement (including the MariaDB Terms and Conditions for your respective region) also apply to your deployment and usage of this solution in the Microsoft Azure Marketplace.

If you are not an existing customer of subscription or other services from MariaDB Corporation, your deployment and usage of this solution in the Microsoft Azure Marketplace is subject to the GNU General Public License (GPL) as well as the latest version of the MariaDB Business Source License (BSL) for MaxScale, the terms of which require a subscription agreement with MariaDB Corporation in order to use this topology in production.

Payment for VMs, storage, and other Azure resources deployed as part of this solution are the responsibility of the end user. Pricing will depend on the options chosen during deployment. Your subscription with Microsoft defines the terms of payment.

Deploying MariaDB TX 2.0 Cluster

First, find the MariaDB TX 2.0 solution in the Azure Marketplace. You can do this by searching for "mariadb", or by visiting the solution page directly at

You can also jump straight to the deployment process at


You must provide a Cluster name. This name should be globally unique, as it will be used to set up DNS and storage accounts in Azure.

Choose the Subscription under which you wish to deploy the cluster.

Create a new Resource group for your cluster. It makes most sense to give this the same value as Cluster name.

Choose a Location where the cluster resources will be deployed. You should choose a Location that supports the types of VMs and Storage you want to use. The "DS" series of VMs include support for "Premium" solid-state (SSD) storage, which offers greatly improved performance over the "Standard" spinning-disk storage supported by the "A" and "D" series VMs. Note that the "DS" series of VMs are available in only a limited subset of locations/regions. If you want to be able to use "DS" series VMs and high-performance Premium storage, you must create your Resource Group in a Location that supports Premium storage. Look for "Premium Storage" at

VM Configuration

Choose the Data node VM Size appropriate for your budget and needs. Azure allows you to choose from a variety of different VM types and sizes. Learn more about VM sizes and pricing at If you want to use SSD (Premium) storage, you must choose a DS-series VM. DS-series VMs are only available in a limited number of Regions in Azure.

Choose a globally unique Data node storage account name. This is set to your Cluster name by default. You can keep that default value if the Azure UI allows you to do so. Otherwise, choose a different value.

Choose the Data node storage account type you want to use, either Premium-LRS (SSD) or Standard-LRS (HDD). Review for information about Storage pricing in Azure and for more information (performance characteristics, etc.) about Premium Storage.

Choose the Disk Size that suits your needs. Each data node in the cluster will place its data directory on this disk. When using Premium (SSD) storage, note that choosing a larger disk has an effect on the available IOPS. That is to say, you get better performance if you're using a bigger device, even if you're not using the whole thing.

You can also choose the MaxScale VM Size. Use the default value unless you identify a CPU or memory bottleneck on the MaxScale node.

Provide an SSH login name that will be used to administer the nodes of the cluster using SSH.

In order to facilitate administration of the cluster, you must provide an SSH public key when deploying the cluster. The file that holds this key is often called and will typically be located in the .ssh subdirectory of your home directory on a Linux or other Unix computer. The private key corresponding to this public key must be used to connect to the nodes in the cluster using SSH. You are responsible for generating and maintaining your own keypair.

App Access Configuration

Configure a Public IP address that will be used to connect to your MaxScale node. By default, Azure should take care of doing this for you automatically.

Choose a Domain name label that will form the DNS name for your MaxScale node. The UI will show the suffix below the text box.

Load Balancer Visibility determines whether you can connect to the exposed MariaDB services on the MaxScale nodes from outside Azure (Public) or only from inside Azure (Internal). If you intend to create additional VMs to run your application inside Azure, choose "Internal". Choose "Public" only if you understand the implications of sending unencrypted database traffic across the open Internet — this is not a recommended configuration and should only be used for testing or PoC purposes.

Specify an App username that will be used by database clients to connect to the MaxScale service.

Specify an App password that will be used by database clients to connect to the MaxScale service. Use a high-quality password.

Specify an App schema/database. This database will be created for you and the App username you provide will have full access (ALL PRIVILEGES) to this database.

Keep in mind that this deployment topology does not support SSL connections from clients to MaxScale at this time (though you can theoretically configure set this up yourself after deployment is complete). For better security, you should set up a VPN connection to Azure, you should use an SSH tunnel to interact with the MaxScale node, or you should connect to the MaxScale node from another VM in Azure that you place into the same virtual network as your MariaDB TX 2.0 Cluster deployment. The implementation details of those approaches are beyond the scope of this document.


Please review your selections. It's not too late to go back and change them, so make sure you've made the right choices.


Once you've read and agreed to the text, you can deploy the solution. It usually takes about 20 minutes for the deployment to complete, but be patient; it can sometimes take much longer.

Reviewing deployment progress

After you've begun deployment of your solution, you can monitor its progress using the Azure Portal.

  1. First load the Resource Groups blade.
  2. From there, click the Resource Group that you chose in the Basics step of your deployment.
  3. You should see a "Last deployment" field with today's date and "Deploying" in parentheses. Click that.
  4. You'll get a "Deployment history" blade that shows your current deployment. Click the deployment:
  5. Here, you can review all the parameters set for this deployment.
  6. Scroll to the bottom and you will see the list of resources being deployed:

Diagnosing deployment problems

Connecting to MariaDB TX 2.0

After your deployment is complete, you'll be able to log in to the MaxScale node using <clusterName>.<location> clusterName is the value you gave in the very first field when setting up your deployment. location is the name of the Location to which you deployed the solution, with spaces removed. For example, West US becomes "westus" and East US 2 becomes "eastus2". For example, if your clusterName was "mytestcluster", and you deployed to the "West US" location, the fully-qualified domain name for your MaxScale node would be

MariaDB MaxScale in this solution exposes three services: RW Split Router (readwritesplit) on port 4006, Write Connection Router (readconnroute to the "Master" node) on port 4007, and Read Connection Router (readconnroute to the "Slave" nodes) on port 4008.

Direct MariaDB/MySQL client access

If you chose "Internal" Load Balancer Visibility, you will only be able to connect applications to MaxScale from a VM running in the same Virtual Network in Azure. Deploying and configuring those VMs is the responsibility of the customer.

If you chose "Public" Load Balancer Visibility during deployment, you'll be able to connect directly to your MaxScale node using any MariaDB or MySQL client, like this:

mysql -h -P 4006 -u myapp -pmyapppassword mydb
$ mysql -h -u myapp -pmyapppassword -P 4006 mydb
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2387
Server version: 10.2.6-MariaDB Cluster MariaDB Certified Binary, wsrep_25.10.r4144

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql 10.2.6-MariaDB Cluster (myapp) [mydb]> select current_user();
| current_user() |
| myapp@%        |
1 row in set (0.09 sec)

Advanced Usage

For more information about connecting to, using, and administering your MariaDB TX 2.0 topology running in Azure, please review MariaDB TX 2.0 Cluster in Azure - Usage and Administration.


Comments loading...