MySQL Horizontal Scaling

Scaling your Cloud MySQL / PostgreSQL Instance.


If you had to perform such operation yourself, it is better to design your system in such a way to perform these operations.

Otherwise, it would be possible that you impact your production application, all this depends on how large is your database, and
if you have planned your application to react to such events, and that you used proper table configuration in the case of MySQL.

In general, you have to restore your new servers from the latest backup or perform a backup operation on your actual production servers.
Unfortunately this may seems an easy tasks, but not affecting production serveres isn't. Another thing to take into consideration here is the time
it takes for the restoration process to occurs. If you have a large database, that restore can take a lot of time base on how you are doing the restoration.

What usually happen during a restoration made by yourself

So you have started your database backup during the day, which is a medium size database, and now your next step is to do the restoration process.... You where expecting to leave at 5PM but the restore is taking way more time than you expected. That is a common problem that people face. You will have to ensure that you keep on your master all the required "Log files", and potentially stay for another 2-3 hours.

Then the restoration is completed, great! you can almost go home? Unfortunately no. You have to sync that new server with the master. This process isn't complicated, but it actually have to apply all the logs from the master. This process is also time consuming. How will your system reprocess the whole day data into 5 to 10 minutes? It will probably take more than that see even hours depending on how much activity occured.

So what? Well you will have to stay online and monitor its replication process to ensure it is fully enabled. But wait.... depending on which product you use, you may use the wrong values which
would work but then the replication may break at anytime over the next few months since you have potentially introduced missing data.

Ok let's say you have not made mistake and that the database is now replicated, we can guess that the time now could be probably around 8 to 10PM.

So now its time to call the other department, tell them that the database is ready and that they have to start using it. In the mean time you will have to setup proper monitoring for that new server. Once that is ready, you will have to wait that the other department ask you if you see the new queries on the servers and if so, to have a look at the overall performance of that new server and the previous ones. Great, that's easy if you have all the tools but if not... how will you base yourself?

One of the the reason for your new slave was probably to be able to support higher demand on your database and improve your application speed. Unfortunately, if you had to take a newer backup you had
to introducte more load on your actual servers which isn't great, or remove an existing slave from it.

Our cloud automated solution allows all of that setup without any of your "TIME" required. All you have to do, is to launch the process and our system will take care of babysitting
the creation of the new server.

Have a look how simple horizontal scaling can be