| Azure Database for MySQL Flexible Server | |
Server and Database Lifetime | | Deleting an Azure SQL logical server and it deletes its databases, elastic pools, and SQK pools |
| Support automated daily, snapshot-based database files backup Transaction log backups occur every 5 minutes Failed backup will be retried every 20 minutes until a successful backup is taken Backup windows are inherently managed by Azure and cannot be customized.
| The Hyperscale architecture does not require full, differential, or log backups. |
| Locally redundant backups (default for same-zone HA or no HA servers) replicate 3 times within a single physical location in the primary region providing at least 99.999999999%(11 nines) durability over a given year. Zone-redundant backup for servers with zone-redundant configuration provides at least 99.9999999(11 9's) durability. High Availability for a server can be disabled post create however the backup storage will continue to remain zone-redundant. Geo-redundant backup replicate backup data files in the primary region's paired region providing 99.99999999999999(16 nines) durability For a Zone-redundant High Availability server geo-redundancy can only be enabled/disabled at server create time Not support moving from zone-redundant to geo-redundant backup storage
| Locally redundant storage (LRS): three synchronous backup copies within a single physical location in the primary region. Zone-redundant storage (ZRS): three synchronous backup copies across three Azure availability zones in the primary region. Geo-redundant storage (GRS): three synchronous backup copies within a single physical location in the primary region by using LRS and three asynchronous backup copies within a single physical location in the paired secondary region.
Backup storage redundancy for Hyperscale databases can be set only during creation. |
| All Azure Database for MySQL data, backups and temporary files created during query execution are encrypted using AES 256-bit encryption. The storage encryption is always on and cannot be disabled.
| If the database is encrypted with TDE, backups are automatically encrypted at rest, including LTR backups. |
| | 1-35 days for automatic backups, default 7 days Up to 10 years long-term retention backups Short-term back up retention of 1 to 35 days for Hyperscale databases is now in preview. Long-term backup retention (LTR) capability for Hyperscale databases is now in preview.
|
| Supported using logical backups | |
| Support total of 50 on-demand backups from the portal Same retention policy and encryption These backup files cannot be exported, only used for faster(up to 90%) point-in-time restore operation.
| |
| Support either backup redundancy option Restore creates a new server in the same region with the same compute and storage configurations as the source server it is based on. The newly restored server's compute can be scaled down after the server is created. Support fast restore point by choosing the restore point-in-time at which the full backup is completed. Support restoring on a different zone Support restoring to a different VNET Support restoring (through REST API) a deleted flexible server within 5 days from the time of server deletion. Restoring a single/few database(s) or tables is not supported.
| The following options are available for database recovery through automated backups: Create a new database on the same server, recovered to a specified point in time within the retention period. Create a database on the same server, recovered to the deletion time for a deleted database. Create a new database on any server in the same region, recovered to the time of a recent backup. Create a new database on any server in any other region, recovered to the point of the most recent replicated backups.
Note: Not supported to overwrite an existing database during restore. Deleting a server deletes all its databases and the deleted databases can't be recovered. It's not supported to restore a deleted server. Database restore operations don't restore the tags of the original database.
When you restore a database, the service determines which full, differential, and transaction log backups need to be restored. |
| Support only if geo-redundant backup is available Only allows to restore the server to the geo-paired region Changing server configurations such as compute, storage or pricing tier during geo-restore is not supported. For HA enabled Server, the new restored server will be configured in the same region and zone as the primary server, but deployed as a non-HA flexible server for both Point-in-time restore and Geo-restore. Support geo-restore on a stopped server through Azure CLI
| A database can be restored on any logical server in any Azure region from the most recent geo-replicated backups even if an outage has made the database or the entire region inaccessible. There's a delay between when a backup is taken and when it's geo-replicated to an Azure blob in a different region. As a result, the restored database can be up to one hour behind the original database(RPO up to 1 hour) RTO up to 12 hours. It doesn't guarantee that the target region will have the capacity to restore all the databases after a regional outage, because a sharp increase of demand is likely.
|
| Supported through geo-redundant backup There can be up to one hour data loss due to the delay between when a backup is taken and when it is replicated to different region. Automatic failover not supported Using the same r/w endpoint not supported
| For business-critical applications that require large databases and must ensure business continuity, use auto-failover groups. That feature offers a much lower RPO and RTO, and the capacity is always guaranteed. |
| | Support creating a copy of an existing database on either the same server or a different server. |
Azure Monitor Integration And Alerting | Supported. All Azure metrics have a one-minute frequency Each metric provides 30 days of history. Alerts can be configured on the metrics.
| |
Monitoring Database Operations | Support Audit log. Disabled by default. Can be enabled and configured through the server parameters Audit logs can be used to track database-level activity including connection, admin, DDL, and DML events.
| Intelligent Insights SQL Insights SQL Analytics
|
Query Performance Insights | Supported (using Workbooks) | |
| | |
| Overview
Auditing
Query Performance Insight
Activity Logs Insights | |
Historical Diagnostic Data Collection | MySQL Slow Logs MySQL Audit Logs AllMetrics
| |
| | |
Comments