Setting up the Infrastructure

We're using Linux virtual machines because they're solid, dependable, and give you a lot of control. Think of each VM as a separate little computer, dedicated to part of the database job.

Linux VMs – Your Building Blocks

Linux VMs are the starting point. Forget fancy servers for now. VMs are flexible and easy to manage. We're using them because:

• They're Stable: Linux is known for running reliably. You don't want your database crashing unexpectedly.
• They're Isolated: If something goes wrong with one VM, it shouldn't take down your whole database cluster. This is crucial for keeping things running smoothly.
• They're Manageable: VMs give you a good balance of control and ease of use.

One Database Node Per VM: Keep It Simple and Strong

We're putting one database brain on each virtual machine body. Why? Because it makes things simpler and more robust in practice:

• Dedicated Resources: Each database gets its own share of computer power (CPU, memory). No fighting for resources, meaning more predictable performance. Imagine if each person in an office had their own desk – less chaos.
• Failure Containment: If one database node has a problem – crashes, gets overloaded – it's contained within its VM. The others keep working. Like having firewalls between apartments in a building.
• Easier to Manage, Seriously: Dealing with individual VMs is just less messy than cramming everything onto one big server. Troubleshooting becomes more focused. Scaling is more straightforward. Think of cleaning one room at a time versus a whole mansion at once.
• Scale When You Need To: Need more database power? Just add another VM with a database node. It's like adding another player to your team when you need more hands on deck.

Two Key Players: Control and Data

Think of your database cluster like a well-organized team. You need a leader and the workers:

1. The Control Node: The Team Captain

   This VM is the captain of the database team. It doesn't store your main data, but it's essential for keeping everything running smoothly. It's responsible for:

   • Keeping Track of Everyone: Knowing which database nodes are online and healthy.
   • Setting the Rules: Managing the cluster-wide settings and making sure everyone is following them.
   • Watching for Problems: Continuously checking if any database nodes are having issues.
   • Making Decisions: Coordinating important tasks, like picking a new leader if the current one fails, or shifting data around if needed.
   • Being the Go-To Person: Providing one place to manage the whole database cluster.

   In a real-world setup, you'd probably make the "captain" super reliable too (maybe even have backup captains!). But to start, one control node VM is enough to understand the basics.

2. Database Nodes: The Hard Workers

   These are the VMs that actually store and serve your data. They're the workhorses of the cluster. Each one is responsible for:

   • Storing the Data: Holding a piece of the overall database data.
   • Answering Questions (Queries): Responding to requests to read and write data.
   • Working Together (Sometimes): If needed, helping with data backups and making sure data is copied for safety.
   • Reporting to the Captain: Letting the control node know if they're healthy and working correctly.

   How many database nodes you need depends on how much data you have, how busy your application is, and how much safety you want. Start with a few, and you can always add more later.

Getting In: SSH – Your Secure Key

To talk to your VMs and set everything up, you'll use SSH. Think of SSH as a secure, private phone line to each virtual machine. It lets you:

• Log In: Get direct access to each VM's command line.
• Install Software: Put the database software on each VM.
• Set Things Up: Configure the control node and database nodes.
• Check on Things: Monitor the cluster's health and see if there are any problems.
• Fix Issues: Troubleshoot and maintain your database cluster.

For security, use SSH keys instead of passwords. It's like having a unique digital key that's much harder to steal than a password. Tools like ssh-keygen can create these keys.

Imagine This:

Think of a team of chefs in a restaurant (database cluster). There's a head chef (control node) who organizes everyone and makes sure the kitchen runs smoothly. Then you have line cooks (database nodes) who each prepare different parts of the meal (data). They all work together to serve the customers (your application).

Practical Access: Logging into Your VMs

Okay, let's get practical. Once you've created your Linux VMs , you'll get the info you need to connect:

• IP Address: The public address for each VM.
• Username: A default user (like ubuntu, centos, etc.).
• Login Method: Usually a password (less secure) or an SSH key (much better).

Using an SSH tool (like the ssh command on Linux/Mac or PuTTY on Windows), you can log into each VM. For example, if your username is ubuntu and your control node VM's IP is 203.0.113.45, you'd type in your terminal:

$ ssh ubuntu@203.0.113.45

Then, you'll be asked for your password (if using passwords – again, don't) or your SSH key passphrase. Once you're in, you're in the command line of your Linux VM! Do this for every VM you created – control and data nodes.

Conclusion

This article outlined foundational steps for setting up each of your VMs for clustering your database.

This article was written by Ahmad Adel. Ahmad is a freelance writer and also a backend developer.