| Azure Database for MySQL Flexible Server | |
|---|
Server Role In Database Service | The parent resource of all underlying database Multiple databases sharing the resources assigned to the server The databases in a server are all physically co-located
| The parent resource of all underlying database. The logical construct acting as a central administrative point of a collection of databases within the same region Provide a namespace for databases, elastic pools, and dedicated SQL pools Ability to assign necessary resources (CPU/storage) to individual databases.
|
Resource Allocation / Pricing | Structured per-server, based on the configuration of compute tier, vCores, and storage (GB) | Structured per-database, based on the configuration of compute tier, vCores, and storage (GB) |
Reserved Instance Pricing | Supported saving up to 63% cost | |
| Yes, and stopped server will automatically be started at the end of 30 days. Not supported with read replica configurations (both source and replicas). Once the server is stopped, the other management operations are not available for the flexible server.
| |
Auto-pausing When Not-In-Use | | |
Server Level Configuration | Allowed through exposed Server parameters (my.cnf) | At the logical server level, the following items care configurable: |
| | Latest stable version of Windows |
| Community Edition / 5.7 & 8.0 | Latest stable Database Engine version |
| Supported: InnoDB MEMORY(HEAP) MyISAM Performance_Schema CSV
Unsupported: BLACKHOLE ARCHIVE FEDERATED
| Single SQL Server Storage Engine |
| The following system database are read-only and used to support various PaaS functionality: Sys Mysql Information_schema Performance_schema
| The Master database of logical server stores data for following features: SQL Logins Firewall rules DMVs
|
Availability zone selection for application colocation | | |
| Burstable (B-series VM,1-20 vCores, Memory-per-vCore: Variable, 4 GiB for 4 or more vCores) General Purpose (D-series VM,2-64 vCores, Memory-per-vCore: 4 GiB) Business Critical (E-series VM,2-96 vCores, Memory-per-vCore: 8 GiB with the exception of 64,80, and 96 vCores, which has 504, 504 and 672 GiB of memory respectively )
| |
| | General Purpose up to 4TB data and 1TB log Business Critical up to 4TB data and 1TB log Hyperscale up to 100 TB data and unlimited log
|
| Support online storage scaling Storage cannot be scaled down once the server is created. Supported pre-provisioned IOPS between 360 and the maximum IOPS determined by the selected compute size Auto scale IOPS is now in preview
| Support online change of resources (CPU/storage). |
| Supported and enabled by default for all new server creates Storage once auto-scaled up, cannot be scaled down
| |
| The existing server is shut down and the storage is then attached to the new VM. During the server switching window (60-120 seconds), no new connection can be established, and all uncommitted transactions are rolled back. | Moving the database engine process to a new virtual machine is an online process during which applications continue using the existing Azure SQL Database service. Once the target database engine is ready to process queries, open connections to the current database engine will be terminated, and uncommitted transactions will be rolled back. New connections will be made to the target database engine. |
| Built-in HA: database files are stored in Azure Premium File shares with 3 copies of replica in an availability zone having automatic data recovery capabilities Same-zone HA: a standby server is always available within the same zone as the primary server. It can be enabled post server create Zone-redundant HA setup with a host standby replica through ZRS replication technology (semisynchronous ) Zone-redundant HA can only be set during flexible sever create. Standby server isn't available for read or write operations to enable fast failover Support standby zone placement (auto or manually, and changeable) Support automatic failover that is fully transparent from the client application Support user initiated forced failover Support transparent application failover Data-in Replication isn't supported for HA servers, but in Microsoft's roadmap HA is not supported for the Burstable pricing tier. HA can be disabled on a server and billing stops right after Currently, the primary and standby server are scaled at the same time
| Standard Availability Model (relies on HA of the remote storage tier): Locally redundant availability for Basic, Standard and General Purpose service tier Zone redundant availability for General Purpose (serverless and provisioned)
Premium Availability Model (AlwaysON AG with a three to four-node cluster): When a database with a zone-redundant configuration is created on a logical server, the master database associated with the server is automatically made zone-redundant as well. |
| For zone-redundant HA: No major performance impact for read workloads Because of the sync replication technology used in ZRS storage, there might be 5-10 percent increased latency for application writes and commits.
For same-zone HA: | Because the zone-redundant databases have replicas in different datacenters with some distance between them, the increased network latency may increase the commit time and thus impact the performance of some OLTP workloads. |
| Support up to 10 read replicas Asynchronously using the MySQL engine's native binary log (binlog) file position-based Replication technology Support transaction-based replication using GTIDs Only available in General Purpose and Business Critical pricing tier No automated failover Not supported Geo-replication(supported by Single Server) Read replicas are supported for HA servers. To create the first replica, the source server will first restart to prepare itself for replication. An existing server can't be made into a replica. You can't create a replica of another read replica
| As an extra benefit, the premium availability model includes the ability to redirect read-only Azure SQL connections to one of the secondary replicas. The feature is enabled by default on new Premium, Business Critical. The read scale-out feature is also available in the Hyperscale service tier when at least one secondary replica is added. read scale-out feature is not available in Basic, Standard and General Purpose, but Readable geo-secondary replicas can provide similar functionality in these service tiers For all replica types, reads from a read-only replica are always asynchronous with respect to the primary.
|
| Supported with Data-in Replication based on the binary log (binlog) file position-based. GTID-based replication is currently not supported for Azure Database for MySQL Flexible Servers. Configuring Data-in replication for zone-redundant high availability servers is not supported.
| Azure SQL Database can only be the push subscriber of a SQL Server publisher and distributor. The SQL Server instance acting as publisher and/or distributor can be an instance of SQL Server running on-premises, an Azure SQL Managed Instance, or an instance of SQL Server running on an Azure virtual machine in the cloud. Snapshot and one-way transactional replication are supported. Peer-to-peer transactional replication and merge replication are not supported. Replication can only use SQL Server authentication logins to connect to Azure SQL Database. Replication management, monitoring, and troubleshooting must be performed from SQL Server rather than Azure SQL Database.
|
| Support public endpoints with server firewall through a publicly resolvable DNS address. Support private access with Virtual Network integration. Resources in a VNet (or peered VNet) can communicate through private IP addresses. Connectivity method cannot be changed after creating the server. Both options control access at the server-level, not at the database - or table-level
| Can be reached via a public endpoint inherited from its logical SQL Server Creating a private endpoint associating with a private IP address within a Virtual Network effectively brings the Azure SQL Database service into the virtual network Support both Server-level and Database-level firewall rules Public and private access can be enabled together on the same server
|
Date Encryption In Transit | TLS v1.2 is enabled by default with support for TLS v1.3(MySQL v8.0), 1.1 and 1.0 | Transport Layer Security (TLS) is used by all drivers that Microsoft supplies or supports for connecting to databases in Azure SQL Database. The default for the minimal TLS version is to allow all versions. The current highest supported version is 1.2 After enforcing a version of TLS, it's not possible to revert to the default.
|
| | Transparent data encryption (TDE) encrypts databases, logs and backups at rest without any changes to applications. |
| | |
| | |
Microsoft Defender for Cloud | Not Supported(Supported by Single Server) | Supported Built-in advanced intelligence and security.
|
| Automatic OS patching Automatic minor version upgrade as part of service's planned maintenance In-place major version upgrade is not supported. To upgrade the major version, take a dump and restore it to a server that was created with the new engine version.
| Built-in backups, patching, recovery. |
| Support for customer provided server maintenance schedule | Azure periodically performs planned maintenance of SQL Database, During the maintenance window, databases are fully available but can be subject to short reconfigurations within respective availability SLAs for SQL Database. The maintenance window is free of charge and can be configured on creation or for existing Azure SQL resources. Configuring maintenance window is a long running asynchronous operation. The resource is available during the operation, except a short reconfiguration that happens at the end of the operation and typically lasts up to 8 seconds even in case of interrupted long-running transactions.
|
| | 8 hour window System Default Weekday window: 10:00 PM to 6:00 AM local time, Monday - Thursday Weekend window: 10:00 PM to 6:00 AM local time, Friday - Sunday
|
コメント