Fast question:
Is it possible to have an Elastic Pool in Azure with Azure SQL Databases and MySQL databases?
Or in alternative an Elastic Pool made of Managed Instance and MySQL databases?
Thank you #Francesco Mantovani. For now Lets post the answer that we have for now. Once you have your article ready, you can still post it as additional answer here.
===
Cut from https://dba.stackexchange.com/questions/279553/azure-elastic-pool-is-it-supported-for-mysql
Azure DB for MySQL is similar as Azure SQL DB Elastic pool or Azure SQL DB managed instance.
With Azure DB for MySQL server, we can create one or multiple DBs. We
can >
Create a single DB per server to use all the resources or
Create multiple databases to share the resources. The pricing is structured per-server, based on the configuration of pricing tier,
vCores, and storage (GB).
Reference : https://learn.microsoft.com/en-us/azure/mysql/concepts-servers
Similarly in Azure SQL DB Elastic Pool
Azure SQL DB elastic pools are cost-effective solution for managing
and scaling multiple databases that have varying and unpredictable
usage demands. The DBs in an elastic pool are on a single server and
share a set number of resources at a set price. Elastic pools in Azure
SQL DB enable SaaS developers to optimize the price performance for a
group of databases within a prescribed budget while delivering
performance elasticity for each database.
Reference : https://learn.microsoft.com/en-us/azure/azure-sql/database/elastic-pool-overview
Only Azure SQL DB has the feature to have multiple databases with separate physical resources in the same logical server.
In Azure DBs for MySQL, If you wish to have two DBs with their own dedicated resources, you need to have two separate Azure DBs for MySQL Servers.
I totally agree with MadhurajVadde-MT:
In Azure DBs for MySQL, If you wish to have two DBs with their own
dedicated resources, you need to have two separate Azure DBs for MySQL
Servers.
It might sound ridiculous but all Azure OSS servers are made to store several databases by default:
https://www.jeeja.biz/2021/08/26/lets-get-confused-azure-database-for-mysql-mariadb-postgresql-part-2/
You kinda have Elastic Pool by default.
Related
I have created an azure SQL single database "w3s_singledb" with no elastic pool and SQL server named "singledb2022dec". After logging into "singledb2022dec.database.windows.net" I executed "create database w3s_seconddb" and it was created.
Next, I created Azure Elastic Pool "elasticpool2022dec" and SQL server named "elasticpool2022dec.database.windows.net". After logging into "elasticpool2022dec.database.windows.net" I executed "create database testdb1" and "create database testdb2". Both were created.
I changed all the databases pricing to basic DTU.
I was trying to understand the basic difference between Single Database and Elastic Pool Databases.?
I know Single Database will be used for "When Application needs a Single Database to work on".
And Elastic Pool will be used for "When Application needs multiple databases to work on and need to share Common Resources like CPU and RAM".
I was trying to understand more elaborately.
The basic idea with an Elastic pool is that you can share resources among databases that need resources at different times. Thereby avoiding paying for idle resources.
Example:
3 databases, set up as 3 single database instance, costs 3X
3 databases, set up as an elastic pool with total resources comparable to 2 single databases, costs 2X
Azure SQL databases are throttled, once you’ve reached the limit of the database resources, additional requests will be timed out.
With an elastic pool, you create a shared resource group for your databases. This can be much more cost efficient, especially when your database infrastructure requires multiple databases or multi-tenancy.
If your database resource usage displays a typical pattern with peaks in performance every now and then, an Elastic Pool might be suited for you.
If your database usage requires large amounts of resources for a longer period of time, it might be a better idea to have a dedicated resource tier for your database.
If you want to change the service tier or compute size of an Elastic Pool, keep in mind that all databases within the pool are affected, briefly. But there will certainly be some kind of downtime during the scaling process. If you need to scale out a dedicated database tier, only that database is affected.
I have question regarding SQL Pool. Not sure i understood what it is. Does SQL Pool service is the service for SQL Server type databases? I have Postgres database and consider to move it to Azure nevertheless what is there any usage of SQL Pool service in case of Azure Postgres or it's only for Azure SQL Server database? Last: Does SQL Pool also used by Synapse ETL?
Azure SQL Pool is used with Azure Synapse Analytics to query Big Data. You can consider it as a Data Warehouse. Once your dedicated SQL pool is created, you can import big data with simple PolyBase T-SQL queries, and then use the power of the distributed query engine to run high-performance analytics.
How SQL Pool works? In a cloud data solution, data is ingested into big data stores from a variety of sources. Once in a big data store, Hadoop, Spark, and machine learning algorithms prepare and train the data. When the data is ready for complex analysis, dedicated SQL pool uses PolyBase to query the big data stores. PolyBase uses standard T-SQL queries to bring the data into dedicated SQL pool tables.
No, PostgreSQL can't be used in SQL Pool. There is actually no link between these two services. If you want to migrate the on-premises PostgreSQL to Azure, you can use Azure Database for PostgreSQL. Check Tutorial: Migrate PostgreSQL to Azure DB for PostgreSQL online using DMS via the Azure CLI.
Due to reasons (I've been told it's a networking issue with MIs; regardless, we can't fix it, we're waiting on a solution from MS that may or may not come out this year), we cannot talk from on-prem to managed instances. However, we can reach Azure SQL Databases.
We would like to replicate lookup data from on-prem to Azure Managed Instances (MIs) as well as ASDs. Is there any way to use the ASD as a "jump" box for replication, maybe by putting the Distributor on an MI that can talk to the ASD?
Looked at Azure Data Sync, but the 5-minute-minimum makes it a no-go.
Otherwise, our current fallback is to run an Azure VM/AKS instance, replicate to it, then from there to the ASDs/MIs. But man, I'd rather not have to do that.
Any suggestions appreciated.
One Way Transactional replication using SQL Data Sync for Azure.
If they wish to maintain the replication running after the migration to Managed Instances, transactional replication will be the best option at this time. Replication to Azure SQL Database
Or using ETL via Azure DataFactory
Transfer data from a SQL Server database to an Azure SQL Database using Azure Blob Storage and the Azure Data Factory (ADF): this is a supported legacy technique that benefits from a replicated staging copy.
ADF pipeline consisting of two data migration processes. They work together to transfer data between a SQL Server database and an Azure SQL Database on a regular basis. The two actions are as follows:
Data should be copied from a SQL Server database to an Azure Blob Storage account
We're in the process of a server migration from an on-prem server (Win2008R2) to Azure PaaS.
To move the DBs, we used the Microsoft Data Migration Assistant (DMA) tool, which worked great and we can connect to the migrated Azure DB via SQL Server Management Studio.
Considering:
Made quite a few changes to the migrated Azure DB (tables, stored procedures, indexes) to work with the apps in Azure
Combined multiple on-prem DBs into one DB in Azure via DMA to save costs
On-prem DB is continually being modified by insert/update operations (multiple tables) during the migration process
Question: what is the best and fastest way to migrate data (all vs missing/updated) considering the above?
I would recommend you to migrate first only the schema of your on-premises databases to Azure SQL Databases and then let Azure SQL Data Sync to migrate the data to Azure and keep it updated on Azure SQL Database.
My suggestion to start with an empty schema on the Azure SQL Database side is because when SQL data Sync finds data on-premises and on Azure it start comparing both databases and that consumes a lot of resources.
On the initial sync SQL Data Sync may consume a lot of resources on the on-premises database server even when having an empty schema on the Azure side, for that you can use SQL Server Resource Governor to cap the CPU used by the data sync sessions in your on premises SQL Server, and this way avoid big performance impact possibly affecting database users.
When you are ready, you can switch your users (gradually or not if SQL Data Sync is on bi-directional mode) to Azure. Once your users have been migrated, you can then remove the member database (the on-premises database) from the SQL Data Sync configuration and stop SQL Data Sync operation.
I disagree with all the answers here.
If you are running on Win2008R2 there is a high chance that you are on an old SQL Server (2008? 2012?) which are both deprecated and unsuitable for Azure SQL Database. And probably the application is also old and not suitable for the Cloud in general. I suggest you a good testing phase.
Here my to do list:
Upgrade SQL Server to SQL Server 2016 on-prem and test if all your queries are still running correctly
Test how ready is your SQL Server to go to Azure SQL Database through Microsoft Data Migration Assistant (DMA) tool or the new Azure SQL Migration extension for Azure Data Studio (came out his month).
Don even think for a second that merging databases will reduce your overall costs. Decide if going multi-tenant or single-tanant not because of the price of the database.
Plan for hours of downtime based on the size of the migration. Don't migrate while your database is modified. Expect downtime. The best way is to take a backup of the day before and then resume the logs.
and test like crazy. This is not gonna be easy because the app is old.
Good luck.
Visual Studio also has a great tool for comparing both schema and data between two databases on different servers.
It can then update the target database with any changes after which you can switch over to use the Azure DB.
This method would require downtime of around 5-30 minutes depending on amount of data, but that might be acceptible depending on your requirements.
The use case is Distributed deployment of Web Application on Azure using PaaS. I read the Azure documentation on SQL Azure database geo-replication, and it seems none of the services tiers best fit this need. The other option is SQL Sync, which is in preview and cannot be used in production.It seems Microsoft Azure does not have any way for a redundant database centric application using PaaS model.
Please help how to resolve the issue or any alternate solution.
Akanksha
Both SQL Data Sync and Geo-replication are for database redundant using. But we need to know you detailed scenarios, so that we can say which one is more fit. Basically Geo-replication is DB level data synchronization used for DR. SQL Data Sync is Table level data synchronization used for reference data replication for both Azure DB and On-prem DB.