Select Page

Jun 23, 2022 | Database, Tutorial

How to start your NETWAYS Managed Database

by

In the first Database tutorial, Sebastian already explained what Vitess is all about and what possibilities it offers you, when running your application compared to an ordinary database.

In this tutorial, I would like to explain how easy it is for you to start your NETWAYS Managed Database(s) within a few minutes in our Vitess Cluster!

 

What Makes Your Database Special

It has to be mentioned in advance that your setup is always highly available. We run Vitess in a Kubernetes cluster, which is equally distributed between our two data centers.

We always replicate the data from left to right. A managed database therefore consists of at least two replicas – a primary and at least one replica. If the primary is located in one data center (left), the replica automatically moves to the other (right). So, if one data centers fails, Vitess swings over and continues to run the database on the second data center without affecting your application.

Furthermore, disaster recovery is included out of the box. As soon as the database is created, an initial backup is made and subsequently a daily backup (MySQL dump) is created. The data is copied to S3 in Xtrabackup format and from this storage the data is restored, in case of emergency.

 

How to Get Your First Database Started

Enough of the theory – how does the start of a Managed DB work in practice? First of all you have to register on our NETWAYS Web Services (NWS) platform.

As soon as you have created your account and entered your payment method, you are ready to go!

First of all, you start your Vitess Cluster, as seen above. Within a Vitess Cluster you can start as many databases as you want. Under “Managed Contract” you have the option to rename your cluster.

 

 

Now you have to start the first database. Just click on “1. create a new database”.

In the following you can name your DB and choose in which Vitess cluster the database should be started (if you have more than one cluster).

Now you have to choose one of our four plans. These plans differ in the replica size, the included backup size and the included traffic. In addition, each next higher plan is assigned more resources (in the form of CPU and memory). So if you have a lot of load, it is recommended to choose a higher plan, because it can handle more queries/second.

After that, you can decide how many replicas should be created. The smallest value is always two (consisting of one primary and one replica). If your application is very read-intensive, you can increase the number of replicas as much as you like and thus distribute the load efficiently.

The retention period of the daily backups can also be freely determined. The backup of the last day is delivered by default. If you want the backups to be kept for several days, you can easily set this by increasing the days to the desired duration.

Last but not least, you can select the replication mode. Here, you can set how your data should be replicated.

In Asyn mode the primary is “fired” with transactions and the replicas just try to keep up with the primary as much as possible without a time delay – but these time delays (seconds behind master) can/may occur. In case of a failover, it can happen that a replica is switched to the primary, which did not get the latest transactions, because it was a few seconds behind.

This cannot happen in semi-sync mode. In semi-sync mode MySQL always expects at least one replica to have fulfilled the last transaction. This ensures that at least one replica is always at the exact same state as your primary. If the primary is broken, Vitess automatically switches to the latest replica and appoints it as the new primary – so it continues without data loss.

Here’s an advice: Ideally, a database setup in semi-sync mode consists of three replicas – a primary and two replicas. One of these two replicas is always up to date with the primary. If a failover occurs, the primary replica can continue to work, because it has an additional replica that confirms new transactions.

If this were not the case (and you had only one replica), then the replica appointed as primary would now lack a counterpart for the commitment of new transactions. So it would have to wait until a new replica is up to commit the transactions (this only affects writes or deletes; read queries are not affected).

Now click on “Create” and your database will be started! Et voilà – after a short moment your data is available and you can start. For your database you now have the options “Connect”, “Edit” and “Destroy”.

 

 

Connect” shows you how to connect to the database – as usual with mySQL with host, user, password and SSL options (we reject non-SSL connections).

There is one more special feature: your SQL connection will include the database name!

If you add @replica to the database name, then you connect to the replica (which is read-only).

So, if your application supports it (e.g. Ruby on Rails), you can specify your primary database connection and your replica database connection – and subsequently, all selected statements go to replicas and all data manipulation statements go to the primary. This way your setup can scale super well, as your application can direct the load of the read queries to the replicas.

 

 

With “Edit” you can configure your database.

So, if you run out of storage, you can simply switch to the next bigger plan here. Or you can increase the number of replicas and backups or adjust the replication mode again.

If the largest plan is no longer sufficient, our scaling via sharding takes effect. For this, however, a detailed tutorial follows.

 

 

As shown above, with “Destroy” you delete your database again.

 

 

Under “User” you will find all the credentials for the automatically created user. Furthermore, you can create (and delete) additional users and assign passwords.

 

 

With “Backups” you will always find the backup that is automatically created once a day by default.

You can also create a backup manually at any time (e.g. in case you are working on your database and want to make a last database backup) by clicking on “Create Backup” and selecting the database to be backed up (if you have started several in your cluster).

Depending on which rentention cycle you have set for your database, your intermediate backups will be deleted in the evening.

 

If you have several backups here, you can delete them – only the last (highest) backup cannot be deleted, because it is used to restore the replicas if necessary.

Under “Graphs” we visualize the utilization of your setup (queries/second), the storage allocation and the slave lag for all replicas.

Under “Manage contract” you can rename or cancel your Vitess cluster.

 

Now that’s all the magic behind starting your first NETWAYS Managed Database built with Vitess! 

Don’t miss our newsletter
More about Database | Tutorial
Securing ingress-nginx with cert-manager

Securing ingress-nginx with cert-manager

In one of our first tutorials, we showed you how to get started with ingress-nginx on your Kubernetes cluster. As a next step, we will tell you how to go about securing ingress-nginx with cert-manager by creating TLS certificates for your services! What is...

Migrating Servers from VMware to Openstack

Migrating Servers from VMware to Openstack

In this tutorial, we will have a look at migrating servers from VMware to OpenStack. After VMware's recent acquisition by Broadcom, many Cloud Service Providers (CSPs) face termination of their partnership programs with VMware. With no further information publicly...

Mastering Kubernetes with Cilium: Empowering L7 Traffic Control

Mastering Kubernetes with Cilium: Empowering L7 Traffic Control

With the new release of the Cilium CNI on our Kubernetes Service you'll get the ability to filter traffic based on L7 properties. It's very powerful and can help a lot with your services security. In this tutorial, we'll be securing an API endpoint to allow access...

Using Terraform with OpenStack

Using Terraform with OpenStack

Many of you may already be familiar using Terraform with Azure or AWS. Although these may be the most used platforms, there is still a need for variety of other options due to local regulations (GDPR). As our systems are geared towards Open-Source, we will be looking...

Dynamic Inventory – An Ansible and Openstack Lovestory

Dynamic Inventory – An Ansible and Openstack Lovestory

For those of you that may not be too familiar with Ansible, it is a great tool to get started in the world of automation and making your life with configuration management a whole lot easier. In this tutorial we will be going through a basic playbook that you can use...

ReadWriteMany (RWX) with the NFS Ganesha Provisioner

ReadWriteMany (RWX) with the NFS Ganesha Provisioner

Introduction You have the desire that your application needs to scale across multiple nodes for load balancing, but needs access to a common PVC? For this purpose, you need a PVC that is RWX-enabled. As part of our Managed Kubernetes Cluster, it is possible to create...

Resizing Persistent Volumes in Kubernetes

Resizing Persistent Volumes in Kubernetes

You want to resize a PersistentVolume (PV) in Kubernetes? In this tutorial, you'll learn how to do it. If you don't already know what a PV is and how you can create one, you should check out the tutorial Creating Persistent Volumes in Kubernetes first.   Let's...

What is Vitess?

What is Vitess?

Back in 2010 a solution was created to solve the massive MySQL scalability challenges at YouTube - and then Vitess was born. Later in 2018, the project became part of the Cloud Native Computing Foundation and since 2019 it has been listed as one of the graduated...

Custom Connection Limit for Load Balancers

Custom Connection Limit for Load Balancers

You need to set a custom limit for incoming connections on your load balancer? Here you can learn how to achieve this! About the Connection Limit The connection limit specifies the maximum allowed number of connections per second for a load balancer listener (open...