enabling additional nodes to bitnami MySQL with replication

Working in the cloud with Multi-Tier solutions offers you a very flexible environment to manage your databases and adapt them to your requirements. Enabling additional nodes in a MySQL schema is a quick, easy and cost-effective solution for scale out.

In this blog post, we'll give you a brief overview of MySQL replication. We will also clarify some of the misconceptions that people have about Multi-Tier and replication concepts.

What is Multi-Tier?

Multi-Tier architecture involves more than one server and infrastructure resource. In a database scenario, for example, you can split writes and reads into two or more different instances. This allows you to extend workloads in the cloud and customize your application to meet specific scalability and reliability needs. Multi-Tier solutions, such as Bitnami MySQL with Replication, provide sophisticated deployment topologies for larger production or critical environments.

And what is Replication?

Replication guarantees information gets copied and purposely populated into another environment, rather than just being stored in one location (based on the transactions of the source environment). In a nutshell, it's a mechanism or process that assures us that our information will be stored in more than one (physical or logical) place.

Master-Slave Replication in a Multi-Tier Scheme

This is a multi-slave replication composed of two databases: one master node and one slave node. The example below shows how replication works in a classic scheme.

Generic Master-Slave

As the master-slave replication is a one-way replication (from master to slave), only the master database is used for the write operations, while read operations may be spread across multiple slave databases.

This means you need to have at least two data sources defined: one for write operations and the second for read operations. This topology works very well for typical MySQL use cases, where there are tons more reads than writes. If this replication is carried out in a Multi-Tier scenario, each actor (master and slave) is deployed into a different instance. What this means in practice is that each machine has its own resources (network, CPU, disk, process space, etc).

So why replication?

Replication brings you a bunch of amazing opportunities to increase your company's performance. Here are the four main ones:

  • To create a standby database server. If the primary server fails, the standby can step in. For any organization using its database for mission-critical, time-sensitive tasks, this is a must!

  • To enable backups without having to bring down or lock out the master server. After replication takes place, backups are done on the slave, rather than on the master. This way, the master can be left to do its job without interruptions.

  • To keep data current across multiple locations. Replication is necessary if several branches of an organization need to work from a current copy of the same database. This is also a great way to achieve geographical redundancy or diversity.

  • To balance the workload of multiple servers. By creating images of one database on multiple servers, you can help alleviate the woes of a single overloaded database server by splitting queries between multiple servers, each running on separate hardware.

The diagram below shows an example of MySQL replication environment using a single slave.

MySQL replication with a single slave

Why should I enable additional slaves?

Using secondary servers on your infrastructure, for reads or other administrative solutions, offers additional flexibility. Previously, we saw that there are numerous reasons to have more than one slave, but they can be summarized as follows: we need to add more capacity and to allow more reads from our system.

This is called scale out architecture. Scale out architecture handles data growth differently. Each building block of this architecture either includes or can include elements to boost performance, such as network ports, processors, memory and, yes, disk. As data grows and capacity is added, processing power is also added.

This means data growth doesn't lead to proportionately longer times for backups, de-duplication, replication and recovery. If the workload is quadrupled, the processing power of the architecture is also quadrupled. And there is no "maximum capacity". The diagram below shows how additional slaves might be used.

MySQL replication with multiple slaves

Taking advantage of the cloud to scale out

Scalability describes the cloud's capability to cope and perform under an increased or expanding workload. You can purchase temporary access to the processing power or storage you need to complete business projects or accommodate rapid growth. And at the end of the project, you can then release those additional resources with no further payment obligation. That's how scalability works, and small and large organizations alike can benefit from this cloud characteristic.

With that in mind, adding additional nodes to a Multi-Tier deployment makes sense. In just a couple of clicks, you can add additional slaves to a Bitnami MySQL with Replication on Azure. To do this, you just need to:

  • Install Azure CLI:

    $ curl -L https://aka.ms/InstallAzureCli | bash
  • Log in to your Azure account:

    $ az login

You'll receive a confirmation link; when you do, click on it and enter the code. After you follow the link, you'll see some information about your Azure account.

  • Download the template.json file from your template. It can be done using the web interface or the CLI.

  • Write a parameters.json file. Bear in mind that the parameters must match your original deployment (you can find how to get them here: just update the slaveCount parameter to the desired value. You must provided a few of other parameters like adminPassword, appPassword, stackId and vmSize.

    "slaveCount": {
    "value": 3
  • Finally, run this command:

    $ az group deployment create --name PREVIOUS_DEPLOYMENT_ID --resource-group RESOURCE_GROUP_ID --template-file ./template.json --parameters @./parameters.json --verbose

Now you can see a message:

Starting long running operation: 'Starting group deployment create'
/ Running ..

After the process ends you will have your deployment with the additional nodes enabled.

So in summary, it's really quite simple to adapt your system to different workloads and scenarios, while keeping your infrastructure up and running at all times. To find out more, please take a look at our documentation on how to add additional nodes in MySQL with replication.