am looking to compare the aurora DB and RDS DB in aws. I see that aurora can also use RDS behind the scenes.
I have worked in sybase and sql server in the past. For these difference is clear as they are two different products with their own SQL and admin consoles. I couldn't draw similar picture for aws databases.
The main difference is the deployment, escalation and managing tools that AWS (or GCP's Database) offers you. The engine (Aurora in your case) is the component that those services use to CRUD data from the Databases they manage.
Amazon Relational Database Service (RDS)
Google Cloud databases
Related
We have a plan to create a new application, which won't have the same architecture of the current one, and will definitely have some differences in the tables' schemas. Our current application's database is running on a AWS Aurora Serverless v1 cluster, with MySQL 5.7. We need to migrate data from the old application to the new one, making some schema changes in some places.
One solution is to create dumps of the old tables, in an easily readable format like csv, then import the data in the new application, picking the data as needed. This will require writing bespoke code on both applications to export data from one and import it into the other.
Considering that we are in AWS, and we intend to keep using it, choosing Aurora as a database (we'll have to decide whether use a provided solution or go with Serverless v2), is there any service to export data from one Aurora Serverless v1 cluster to another Aurora cluster, making changes along the way?
I know that database snapshots exist, but that's not exacly our goal. We need to migrate data from one database to another, not creating another copy of the first one. I've seen that there is a service, called "AWS Database Migration Service", that's used to migrate data into RDS, but does this service suit our needs, to get data from one Aurora Serverless database, do some changes, and then put it into another RDS database of our choice?
You could use following options to accomplish your goal.
1.- AWS Database Migration Service, this service provide you capabilities to replicate your data and also perform some schema transformation during replication process. You can create selection and transformation rules, the service will execute those rules and apply changes to the target schemas. You could review more details on this link.
https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.html
2.- AWS Glue Studio, it is ETL service that allows you extract, convert and transfer data between source and target databases.
What is AWS Glue Studio?
Automate ETL jobs between Amazon RDS for SQL Server and Azure Managed SQL using AWS Glue Studio
As you can see in the screenshot below, a server needs to be selected or created in order to create an azure sql serverless database.
Can I reuse that server and create other azure sql serverless databases on it? If so, how many databases can be created using the same server?
I found the answer in the documentation:
Azure SQL Logical Server Limits
It's 5000 databases per logical server.
I need to move schema and its objects from one AWS RDS to another AWS RDS db.
I have used AWS schema conversion tool (SCT) in the past.
Is there any other better way or what I am doing is the best.
Thank you,
AWS Database Migration Service (AWS DMS) will help you to migrate databases to AWS quickly and securely. The source database remains fully operational during the migration, minimizing downtime to applications that rely on the database. The AWS Database Migration Service can migrate your data to and from the most widely used commercial and open-source databases.
Here is the reference link which will help you to guide further for AWS DMS
I would like to know what extra benefits one get by choosing Azure SQL Managed Instance compared to Azure SQL DB PaaS. I know SQL Managed Instance is offered as a vCore based purchasing model only. Apart from this what is the extra add on and benefits that one gets over the other. Any reply would be appreciated.
With Azure SQL Managed Instance, you essentially get a full fledged SQL Server that you can control any way you want, just like you would control a locally configured SQL Server. All the power and access and customization you want.
With, Azure SQL DB PaaS, you are essentially getting a database service, so, you give up a lot of control.
For example, take server collation. With the database service, SQL_Latin1_General_CP1_CI_AS , is all you get. With the Managed Instance, its your server. So, go ahead and select whatever collation you want, just like how you would select the collation at the time of creatoin.
Another issue is with auditing, if that is something that is important to your setup. with SQL Managed Instance, auditing happens at server level, because, you are getting the full database server. With the database service, it only database, because, you are only getting a database.
These are just the main details that I found. more details here at this Azure doc - https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Of course, Managed is going to cost you more because you are paying for the license of the SQL server too.
Lastly, for me, this is the almost (not the exact same thing) like you running your own File Server on a Windows VM on Azure (Managed Instance) versus, just using Blob Storage. In both cases, you are just trying to store some files, but its how much control you have.
I would say think about Azure SQL DB vs Azure SQL Managed Instance (MI) as
Azure SQL DB = Resources dedicated to individual DBs like a container. They are grouped under a Azure SQL Server but that SQL Server is just for grouping.
Azure SQL MI = Almost same as on-prem SQL Server except you don't have to worry about OS, backups, high availability.
Here is a good comparison.
https://learn.microsoft.com/en-us/azure/azure-sql/database/features-comparison
Hopefully this will help
Azure SQL Database - The usual PaaS way. You have vCore, DTU, and Serverless billing mode. And Elastic pool support.
Azure SQL Managed Instance - Similar as below. When you want to use instance-scoped features of Azure SQL Managed Instance like Service Broker, CLR, SQL Server Agent, and Linked servers. As if you have an SQL Server on premise, Azure is responsible for patching, upgrading version etc.
SQL Server on Azure Virtual Machines - Similar as above. But you are responsible for OS and SQL server upgrade.
We have a web application which is hosted on EC2 (Apache in Ubuntu) with MySQL DB in RDS (Multi AZ). We are planning to go for another application instance which will primarily be used by our support team to analyse certain LIVE issues. In order to do this, we would like to have a copy of LIVE DB data in another instance, preferably in another RDS instance. Here is our approach:
Get the latest RDS snapshot
Create a new RDS instance, and copy the RDS snapshot into it
Set up the application configuration to point the DB to the new RDS instance created above
Could you please share your comments on whether this approach is fine, or is there a better approach?
By the way, I checked following stackoverflow questions:
How to copy a database using RDS
Amazon RDS replica
In both these questions, mysqldump is suggested. But in my case the DB size will be huge, and mysqldump might slow down the LIVE performance.
Take a look at AWS read replicas. See http://aws.amazon.com/rds/mysql/#Read_Replica