migration Archives - DEVOPS DONE RIGHT

Apache Cassandra Migration: 3.x to 4.x Ep: 2 DC and DR Setup

Well in my previous blog, we learned about Cassandra’s basics. If you have not read it yet, you should go through it. We have discussed the basics of Cassandra which will be useful in your daily operations on the database.

So now we will deep-dive into Cassandra’s DC/DR Setup.

DC/DR setup is necessary in a production environment where you don’t know when an issue can occur. You need to have an immediate backup when your cluster is down, and you should always have another cluster to respond.

Cassandra is a database and for a database, we want it to remain up in any and every situation to avoid downtime of our applications. Disaster Recovery setup of databases is equally necessary as you do for your applications. So let’s get started with this super easy way where it will take a few minutes and make your DR Setup ready.

Know How to Use Velero to Backup and Migrate Kubernetes Resources and Persistent Volumes

“Murphy’s law doesn’t mean that something bad will happen. It means that whatever can happen, will happen.” This is something related to destiny but we should not totally rely upon it and should be prepared for the worst.
The same philosophy referenced above applies to the tech world too. That’s the reason we should be prepared with our backup options choices possibly, a data set or Kubernetes cluster.

Kubernetes backup solutions bring down the risk and empower faster recovery time while providing key benefits like: disaster recovery and backup & restore. Now we have to explore some simple and convenient options to take Kubernetes backup. While working on a similar project I came to know about Velero which can fulfil our needs to take Kubernetes backup and restore and it is easy to use.

https://c.tenor.com/wtz8za_yyGoAAAAM/darla-little-rascals.gif

Velero is an open-source tool for securely backing up and restoring resources in a Kubernetes cluster, performing disaster recovery, and moving resources and persistent volumes to another Kubernetes cluster.

Migrate your data between various Databases

Data Migration Service

Have you ever thought about migrating your production database from one platform to another

and dropped this idea later, because it was too risky, you were not ready to

bare a downtime?

If yes, then please pay attention because this is what we are going to perform
in this article.

A few days back we’re trying to migrate our production MySQL RDS from AWS to GCP, SQL, and we had to migrate data without downtime, accurate and
real-time and that too without the help of any Database Administrator.

After doing a bit research and evaluating few services we finally started working on AWS DMS (Data Migration Service) and figured out this is a great service to migrate a
different kind of data.

You can migrate your data to and from the most widely used commercial and open-source databases, and database platforms. Databases like Oracle, Microsoft SQL Server, and
PostgreSQL, MongoDB.

The source database remains fully operational during the migration,
The service supports homogeneous migrations such as Oracle to Oracle,
and also heterogeneous migrations between different database platforms.

Let’s discuss some important features of AWS DMS:

Migrates the database securely, quickly and accurately.
No downtime required, works as schema converter as well.
Supports various type or database like MySQL, MongoDB, PSQL etc.
Migrates real-time data also synchronize ongoing changes.
Data validation is available to verify database.
Compatible with a long range of database platforms like RDS, Google SQL, on-premises etc.
Inexpensive (Pricing is based on the compute resources used during the migration process).

This is a typical migration scenario.

Let’s perform step by step migration:

Note: We’ve performed migration from AWS RDS
to GCP SQL, you can choose database source and
destination as per your requirement.

Create replication instance:
A replication instance initiates the connection between the source and target databases, transfers the data, cache any changes that occur on the source database during the initial data load.

Use the fields to below to configure the parameters of your new replication instance including network and security information, encryption details, select instance class as per requirement.

After completion, all mandatory fields click the next tab, and you will be redirected
to Replication Instance tab.

Grab a coffee quickly while the instance is getting ready.

Hope you are ready with your coffee because the instance is ready now.
Now we are to create two endpoints “Source” and “Target” 2.1 Create Source Endpoint:

Click on “Run test” tab after completing all fields, make sure your Replication instance IP is whitelisted
under security group. 2.2 Create Target Endpoint

Click on “Run test” tab again after completing all fields, make sure your Replication instance IP is whitelisted under target DB authorization.

Now we’ve ready Replication Instance, Source Endpoint, and Target Endpoint.
Finally, we’ll create a “Replication Task” to start replication.

Fill the fields like:

Task Name: any name
Replication Instance: The instance we’ve created above
Source Endpoint: The source database
Target Endpoint: The target database
Migration Type: Here I choose “Migration existing data and replication
ongoing” because we needed ongoing changes.