No doubt there will be a need for you to split off your analytical queries from the main database for performance reasons.
If you have used MySQL before you will know about the system server variables, you know such commands as SHOW VARIABLES; You can access most of them via the Azure portal or connect to MySQL and issues the commands you come to know about.
When it comes to MySQL and storage you will normally have to decide on 3 options: basic, general purpose v1 or v2.
Basic does support up to 1TB and is low-cost option but has no IOPs guarantee, not really recommended for production systems. General purpose v2 should be the one used because it uses latest storage infrastructure which can support up to 16-TB and 20000 IOPs a shown below.
We have already created the server now it’s time to connect to it. What you will need – connection string details, correct networking setup and a tool like MySQL Workbench.
Enough of the theory and text lets use the Azure Portal and create MySQL Single server. Navigate to the Azure Portal, find Azure Database for MySQL servers:
When you start the build process for MySQL you will be shown the below screen, the question is what option would you select?
SQL Server is not the only database you build and deploy into Azure. Another very popular option is MySQL. Going back many years, this was actually my first database technology that I ever used so its great seeing it within the Azure eco-system, it has always been a popular choice as seen below.
There is a setting / feature in Managed Instance worth talking about, it is called SQL Trust Groups.
Lets summarise some important learnings about SQL MI and failover groups.
This is our current setup shown below.
There is not much to failing over with Managed Instances, from experience it is similar to that of Azure SQL Database.