MySQL Classic Retirement Customer FAQ
We are ending the MySQL Database on Azure service on December 1st, 2019, which will be replaced by the Azure Database for MySQL service.
If you are an existing customer:
- You will be automatically migrated to the new service before the end of life of the existing service.
- Support the business continuity. When your server(s) has been scheduled for migration from the retired MySQL Database on Azure service to the new Azure Database for MySQL service, we estimate the total downtime for migration per server to be less than 10 minutes in most cases. However, the exact downtime is depending on the size and rate of change of your existing MySQL Database on Azure instances.
- Migration will begin on Feb 15th, 2019.
- Special pricing will be lost when scaled to a different service tier or if the server is deleted; When scaled back to the original service tier will retain the special pricing.
- You will continue to pay the same price post migration – detailed information about the SKU mapping between the old service and the new service will be published before end of December 2018
- No action necessary for now. At a minimum, 30 days prior to your scheduled migration you will receive additional notifications including the exact timeline for your migration
If you are a new customer:
- You will not be accepted on the “MySQL Database on Azure” service as of the date of this announcement
Q: What do I have to prepare for the migration?
A: There are several things you should do before your scheduled migration to assure a good migration experience:
- Assure you are using a client driver that is supported by the new server. A complete list of supported drivers can be found here.
- The new Azure Database for MySQL does not support
1. Navicat 11.1 client. Please upgrade to a higher version before the migration
2. CentOS 6.9 default client. Please upgrade the MySQL client to version 5.5 or above
3. There is a difference in the maximum number of connections that can be established to the server. Please refer to the documentation for the new connection limits. If you require higher connection limits, please change your SKU that is mapped to a SKU with a sufficient high connection limit. Please refer to question “How will my server be mapped to the new offering?” for the SKU mapping.
Prepare for VNet usage: If your client VM is running in a VNet and you have the Microsoft.SQL service endpoint enabled (for example to connect to a SQL Database using the endpoint) you have the following two options:
1. Remove the Microsoft.SQL service endpoint from your VNet in case you do not need them or
2. Make sure your current MySQL server is at least MS3 and you configure the correct VNet firewall rules for your server right after the migration completes.
- In the Azure portal, navigate to the overview for your server and click on ”Migrate to Azure Database for MySQL”. Review and mitigate the list of all potential issues that may block the migration prior to your scheduled migration. Potential issues include:
a. Missing primary keys: For the tables listed, please add primary key. Without primary keys on all tables, an offline migration might become necessary and you will experience a longer downtime.
b. Non supported storage engines: For the tables listed which use storage engines that are not supported, please alter the table to use InnoDB. Otherwise, these tables are not accessible after migration.
c. Invalid names for firewall rules: For the firewall rules listed, please changes their names. Otherwise, these firewall rules cannot be migrated to the new instance.
- Adjust your pricing tier to at least MS3 prior to the migration if you want the full service capabilities after the migration: The Basic service tier in Azure Database for MySQL cannot be scaled to the General Purpose or Memory Optimized service tiers. The MS1 and MS2 SKUs will be mapped to the Basic service tier. If you want to make full use of the new service (including features like VNet service endpoints, maximum storage and compute scaling, readable replicas), make sure your database is at least MS3 prior to the migration.
- Learn how to manage users in the new service: Create users in Azure Database for MySQL server
- Learn about SSL in Azure Database for MySQL: SSL connectivity in Azure Database for MySQL
- Learn how to monitor your resource usage including storage utilization and setup alerts for these metrics.
Q: Will my total bill increase when moving from MySQL Database on Azure to Azure Database for MySQL?
A: No. Your monthly total bill once on Azure Database for MySQL will be the same as your total monthly bill on MySQL Database on Azure. For example: if you are an MS4 customer currently paying ¥1,071.36 per month for MySQL Database on Azure, you will continue to pay ¥1,071.36 per month once on Azure Database for MySQL.
Q: Will my bill look different after I migrate from MySQL Database on Azure to Azure Database for MySQL? How will my bill look different?
A: Yes, your bill will look different after we migrated you from MySQL Database on Azure to Azure Database for MySQL, but your total bill amount will remain the same. Today with MySQL Database on Azure you are charged for the version you are using (MS1, MS2, MS3, MS4, MS5, MS6, MP1, or MP2), which includes a free amount of storage called “free database capacity”. If you use more storage than is included in this free database capacity, then you are billed ¥0.6116 per GB per month for that excess storage.
After the migration to Azure Database for MySQL, you will be charged for the compute and storage resources you provision. Compute resources are charged per vCore per hour. Storage is charged per provisioned GB per month. Azure Database for MySQL does not include “free database capacity”.
Let us look at an example that describes how you will be billed before and after you migrate to Azure Database for MySQL:
Let us assume you are using MS5 with 200 GB of storage. MS5 includes 100 GB of “free database capacity”. That makes the bill look like this:
- MS5 server: ¥2.1613 per hour x 744 hours per month = ¥1,608.01 per month
- Storage Overage: ¥0.6116 per GB per month x (200 GB used – 100 GB free) = ¥61.16 per month
- Total Bill: ¥1,608.01 per month + ¥61.16 per month = ￥1,669.17 per month
During the migration to Azure Database for MySQL the MS5 server will migrate to General Purpose 4 vCore with 200 GB provisioned storage. The pricing look as follows:
- Compute: ¥0.5198 per vCore per hour x 4 vCore x 744 hours per month = ¥1,546.85 per month
- Storage: ¥0.6116 per GB per Month x 200 GB = ¥122.32 per month
- Total Bill: ¥1,546.85 per month + ¥122.32 per month = ￥1,669.17 per month
So in this example, the total monthly bill for MySQL Database on Azure MS5 and the equivalent offer on Azure Database for MySQL is the same.
Q: How will you maintain my total bill if you are charging for storage?
A: MySQL Database on Azure includes a free amount of storage called “free database capacity”. This free database capacity varies by version (MS1, MS2, MS3, MS4, MS5, MS6, MP1, or MP2).
Azure Database for MySQL does not include free storage. Instead Azure Database for MySQL charges for compute in vCores per hour and provisioned storage in GB per month separately. Each MySQL Database on Azure migrated to Azure Database for MySQL will be provisioned with a minimum storage size equivalent to the free database capacity for MySQL Database on Azure. For example, if you are an MS1 customer, your database will be provisioned with a minimum of 100 GB of storage.
To maintain the same total monthly bill for customers who have migrated from MySQL Database on Azure to Azure Database for MySQL, migrated customers will be billed using a special “legacy” compute and storage meters that maintain your total monthly bill. These “legacy” meters are priced to offset the loss of the “free database capacity” included in MySQL Database on Azure.
Q: What happens if I notice an increase in my total bill?
A: You should not see an increase in your total monthly bill. If you do, please open a support ticket so that the team can investigate.
Q: How will my server be mapped to the new offering?
|MySQL Database on Azure SKU (Old Server)||Azure Database for MySQL SKU (New Server)|
Q: When will my server be migrated?
A: You will get an email notification at least 30 days prior to the date your server is scheduled to migrate. Migrations will not start before Feb 15th, 2019.
Q: How will the billing meters be mapped?
A: We have published detailed meter mapping information here for your reference.
Q: Do I have to migrate myself or will you provide assistance to migrate?
A: You do not have to take any action, your MySQL server will be migrated for you. You will receive another communication with additional details 30 days prior to your scheduled migration.
Q: What if I migrate to using a mysqldump and mysqlrestore?
A: You can migrate using mysqldump and mysqlrestore, however you will not be able to maintain use the legacy meters put in place to maintain your exact current price points. You will be billed using new pricing model.
Q: What happens if I want to change the performance level after I migrate (ex: I have migrated to a General Purpose 4 vCore from MS5, and then want to upgrade to General Purpose 8 vCore)?
A: If you decide to increase your database size once on Azure Database for MySQL after you have migrated, you will no longer receive the “legacy” prices, but will migrate to the Azure Database for MySQL prices as displayed here.
Q: What is the experience during the migration?
A: The impact to your server and workload will be minimal. We migrate server from MySQL Database for Azure to the new Azure Database for MySQL using replication. This means that the server will be online during the migration except for the final phase of the migration that includes the failover to the new server. The connection string to the server will remain the same, so that you do not have to change your application logic.
Below are the migration steps in short:
- We take a snapshot of the server in MySQL Database for Azure.
- We restore that snapshot in a new Azure Database for MySQL server.
- Set up replication between the old and the new server to catch up all changes since the snapshot.
- When the new server is caught up except for in-flight transactions, we set the old server to read-only mode for new transactions.
- The new server catches up with the latest changes and we stop the replication.
- We then copy configurations, firewall rules and redirect DNS from the old to the new server and finally stop the old server.
- All new connections to against the new server. No changes to your application are required.
Q: Can I choose my admin user name?
A: If you have special requirements for your admin user, please file a support ticket prior to your migration to coordinate the requirements with the engineering team.