Livelli di servizio del server flessibile di Database di Azure per MySQL
APPLICABILE A:
Database di Azure per MySQL - Server flessibile
È possibile creare un'istanza del server flessibile di Database di Azure per MySQL in uno dei tre livelli di servizio: con possibilità di burst, per utilizzo generico e Business critical. Lo SKU della macchina virtuale sottostante differenzia i livelli di servizio usati in serie B, serie D e serie E. La scelta del livello di calcolo e delle dimensioni determina la memoria e i vCore disponibili nel server. La tecnologia di archiviazione esatta viene usata in tutti i livelli di servizio. Viene effettuato il provisioning di tutte le risorse a livello di istanza del server flessibile di Database di Azure per MySQL. Un server può avere uno o più database.
| Risorsa/Livello | Possibilità di burst | Utilizzo generico | Business Critical |
|---|---|---|---|
| Serie VM | Dimensioni delle macchine virtuali della serie B con supporto per burst | Dadsv5-seriesDdsv4-series | Edsv4/Edsv5-series*/Eadsv5-series |
| vCore | 1, 2, 4, 8, 12, 16, 20 | 2, 4, 8, 16, 32, 48, 64 | 2, 4, 8, 16, 32, 48, 64, 80, 96 |
| Memoria per vCore | Variabile | 4 GiB | 8 GiB ** |
| Dimensioni dello spazio di archiviazione | Da 20 GiB a 16 TiB | Da 20 GiB a 16 TiB | Da 20 GiB a 32 TiB |
| Periodo di conservazione dei backup dei database | 1 - 35 giorni | 1 - 35 giorni | 1 - 35 giorni |
** Fatta eccezione per 64.80 e 96 vCore, che hanno rispettivamente 504 GiB, 504 GiB e 672 GiB di memoria.
* Il calcolo Ev5 offre le migliori prestazioni tra le altre serie di macchine virtuali per quanto riguarda QPS e latenza. Ulteriori informazioni sulla prestazioni e sulla disponibilità di area di calcolo Ev5 sono disponibili qui.
Livelli di servizio server flessibile
Per scegliere un livello di calcolo, usare la tabella seguente come punto di partenza.
| Livello di calcolo | Carichi di lavoro di destinazione |
|---|---|
| Con possibilità di burst | Ideale per carichi di lavoro che non richiedono continuamente l’intera CPU. |
| Utilizzo generico | La maggior parte dei carichi di lavoro aziendali richiedono calcolo e di memoria bilanciati con velocità effettiva di I/O scalabile. Tra gli esempi sono inclusi i server per l'hosting di app Web e per dispositivi mobili e di altre applicazioni aziendali. |
| Business Critical | Carichi di lavoro di database ad alte prestazioni che richiedono prestazioni in memoria per l'elaborazione più rapida delle transazioni e una concorrenza maggiore. Tra gli esempi sono inclusi i server per l'elaborazione dei dati in tempo reale e le app transazionali o analitiche a prestazioni elevate. |
Dopo aver creato un server, è possibile modificare il livello di calcolo, le dimensioni di calcolo e le dimensioni di archiviazione. Il ridimensionamento del calcolo richiede un riavvio e un’attesa di 60-120 secondi, mentre il ridimensionamento dell'archiviazione non richiede riavvio né attesa. È anche possibile aumentare o diminuire il periodo di conservazione dei backup in modo indipendente. Vedere la sezione Ridimensionare le risorse per ulteriori informazioni.
Livelli di servizio, dimensioni e tipi di server
Le risorse di calcolo possono essere selezionate in base al livello e alle dimensioni. Ciò determina i vCore e le dimensioni della memoria. I vCore rappresentano la CPU logica dell'hardware sottostante.
Con possibilità di burst
Per il livello di servizio con possibilità di burst, le specifiche dettagliate dei tipi di server disponibili sono le seguenti.
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni della memoria totale (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB di archiviazione temp (unità SSD) |
|---|---|---|---|---|---|---|
| Standard_B1s | 1 | 1 | 1.1 | 320 | 171 | 0 |
| Standard_B1ms | 1 | 2 | 2.2 | 640 | 341 | 0 |
| Standard_B2s | 2 | 4 | 4.4 | 1280 | 683 | 0 |
| Standard_B2ms | 2 | 8 | 8.8 | 1700 | 1365 | 0 |
| Standard_B4ms | 4 | 16 | 17.6 | 2400 | 2731 | 0 |
| Standard_B8ms | 8 | 32 | 35.2 | 3100 | 5461 | 0 |
| Standard_B12ms | 12 | 48 | 52.8 | 3800 | 8193 | 0 |
| Standard_B16ms | 16 | 64 | 70.4 | 4300 | 10923 | 0 |
| Standard_B20ms | 20 | 80 | 88 | 5000 | 13653 | 0 |
Utilizzo generico
Per il livello di servizio di utilizzo generico, le specifiche dettagliate dei tipi di server disponibili sono le seguenti.
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni della memoria totale (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB di archiviazione temp (unità SSD) |
|---|---|---|---|---|---|---|
| Standard_D2ads_v5 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D2ds_v4 | 2 | 8 | 11 | 3200 | 1365 | 53 |
| Standard_D4ads_v5 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D4ds_v4 | 4 | 16 | 22 | 6400 | 2731 | 107 |
| Standard_D8ads_v5 | 8 | 32 | 44 | 12.800 | 5461 | 215 |
| Standard_D8ds_v4 | 8 | 32 | 44 | 12.800 | 5461 | 215 |
| Standard_D16ads_v5 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D16ds_v4 | 16 | 64 | 88 | 20000 | 10923 | 430 |
| Standard_D32ads_v5 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D32ds_v4 | 32 | 128 | 176 | 20000 | 21845 | 860 |
| Standard_D48ads_v5 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D48ds_v4 | 48 | 192 | 264 | 20000 | 32768 | 1290 |
| Standard_D64ads_v5 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
| Standard_D64ds_v4 | 64 | 256 | 352 | 20000 | 43691 | 1720 |
Business Critical
Per il livello di servizio Business critical, le specifiche dettagliate dei tipi di server disponibili sono le seguenti.
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni della memoria totale (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB di archiviazione temp (unità SSD) |
|---|---|---|---|---|---|---|
| Standard_E2ds_v4 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E2ads_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v4 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E4ads_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v4 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E8ads_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v4 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E16ads_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v4 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E20ads_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v4 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E32ads_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v4 | 48 | 384 | 528 | 48.000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48.000 | 65536 | 906 |
| E64ds_v4 Standard | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E64ads_v5 | 64 | 504 | 693 | 64000 | 86016 | 1224 |
| Standard_E80ids_v4 | 80 | 504 | 693 | 72.000 | 86016 | 1224 |
| Standard_E2ds_v5 | 2 | 16 | 22 | 5000 | 2731 | 37 |
| Standard_E4ds_v5 | 4 | 32 | 44 | 10000 | 5461 | 75 |
| Standard_E8ds_v5 | 8 | 64 | 88 | 18000 | 10923 | 151 |
| Standard_E16ds_v5 | 16 | 128 | 176 | 28000 | 21845 | 302 |
| Standard_E20ds_v5 | 20 | 160 | 220 | 28000 | 27306 | 377 |
| Standard_E32ds_v5 | 32 | 256 | 352 | 38000 | 43691 | 604 |
| Standard_E48ds_v5 | 48 | 384 | 528 | 48.000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Gestione della memoria nel server flessibile di Database di Azure per MySQL
In MySQL, la memoria svolge un ruolo fondamentale in varie operazioni, tra cui l'elaborazione di query e la memorizzazione nella cache. Il server flessibile di Database di Azure per MySQL ottimizza l'allocazione di memoria per il processo del server MySQL (mysqld), assicurandosi di ricevere risorse di memoria sufficienti per svolgere efficientemente l’elaborazione di query, la memorizzazione nella cache, la gestione delle connessioni client e la gestione dei thread. Ulteriori informazioni su come MySQL usa la memoria.
Dimensioni della memoria fisica (GB)
Le dimensioni della memoria fisica (GB) nella tabella seguente rappresentano la memoria ad accesso casuale (RAM) disponibile in gigabyte (GB) nel server flessibile di Database di Azure per MySQL.
Dimensione della memoria totale (GB)
Il server flessibile di Database di Azure per MySQL fornisce una Dimensione della memoria totale (GB). Questa rappresenta la memoria totale disponibile per il server, ovvero una combinazione di memoria fisica e una determinata quantità di componenti SSD di archiviazione temporanea. Questa vista unificata è progettata per semplificare la gestione delle risorse, consentendo di concentrarsi esclusivamente sulla memoria totale disponibile per il processo del server MySQL di Azure (mysqld). La metrica Percentuale memoria (memory_percent) rappresenta la percentuale di memoria occupata dal processo del server MySQL di Azure (mysqld). Questa metrica viene calcolata in base alla Dimensione della memoria totale (GB). Ad esempio, quando la metrica Percentuale memoria mostra un valore pari a 60, significa che il processo del server MySQL di Azure sta utilizzando il 60% delle Dimensioni della memoria totale (GB) disponibile nel server flessibile di Database di Azure per MySQL.
Server MySQL (mysqld)
Il processo del server MySQL di Azure, mysqld, è il motore principale delle operazioni di database. All'avvio, inizializza i componenti totali come il pool di buffer InnoDB e la cache dei thread, utilizzando la memoria in base alle esigenze di configurazione e carico di lavoro. Ad esempio, il pool di buffer InnoDB memorizza nella cache i dati e gli indici a cui si accede di frequente per ottimizzare la velocità di esecuzione delle query, mentre la cache dei thread gestisce i thread di connessione client. Altre informazioni.
Motore di archiviazione InnoDB
Come motore di archiviazione predefinito di MySQL, InnoDB usa la memoria per memorizzare nella cache i dati a cui si accede di frequente e gestire strutture interne come il pool di buffer innodb e il buffer di log. Il pool di buffer innoDB contiene i dati di tabella e gli indici in memoria per ridurre al minimo l'I/O del disco, migliorando le prestazioni. Il parametro Dimensioni del pool di buffer InnoDB viene calcolato in base alle dimensioni della memoria fisica (GB) disponibili nel server. Ulteriori informazioni sulle dimensioni del pool di buffer InnoDB disponibili in server flessibile di Database di Azure per MySQL.
Threads
Le connessioni client vengono gestite tramite appositi thread gestiti dal gestore di connessione. Questi thread gestiscono l'autenticazione, l'esecuzione di query e il recupero dei risultati per le interazioni con client. Altre informazioni.
Per altre informazioni sulla serie di calcolo disponibile, vedere la documentazione delle macchine virtuali di Azure per dimensioni di macchine virtuali con possibilità di burst di serie B, per utilizzo generico serie Dadsv5serie Ddsv4 e Business Critical Edsv4/serie Edsv5/serie Eadsv5.
Limitazioni delle prestazioni delle istanze di serie con possibilità di burst
Nota
Per dimensioni delle macchine virtuali con possibilità di burst di serie B, se la macchina virtuale viene avviata/arrestata o riavviata, i crediti potrebbero andare perduti. Per altre informazioni, vedere Dimensioni delle macchine virtuali della serie B con supporto per burst.
Il livello di calcolo con possibilità di burst è progettato per offrire una soluzione conveniente per carichi di lavoro che non richiedono continuamente l’intera CPU. Questo livello è ideale per carichi di lavoro non di produzione, ad esempio ambienti di sviluppo, gestione temporanea o test. La funzionalità esclusiva del livello di calcolo con possibilità di burst è la possibilità di "burst", ovvero di utilizzare più delle prestazioni di base della CPU, usando fino al 100% della vCPU quando il carico di lavoro dovesse richiederlo. Ciò è reso possibile da un modello di credito CPU, che consente alle istanze di serie B di accumulare "crediti CPU" durante periodi di utilizzo ridotto della CPU. Questi crediti possono quindi essere spesi durante periodi di utilizzo elevato della CPU, consentendo all'istanza di eseguire un burst, superando le prestazioni di base della CPU.
Tuttavia, è importante notare che una volta che un'istanza con possibilità di burst esaurisce i crediti CPU, opererà alle prestazioni di base della CPU. Ad esempio, le prestazioni di base della CPU di un Standard_B1ms sono pari al 20%, ovvero 0,2 Vcore. Si supponga che il server di livello con possibilità di burst stia eseguendo un carico di lavoro che richiede maggiori prestazioni della CPU rispetto al livello di base e abbia esaurito i crediti della CPU. In tal caso, il server potrebbe riscontrare limitazioni nelle prestazioni e potrebbe infine influire su varie operazioni di sistema, ad esempio Arresto/Avvio/Riavvio per il server.
Nota
Per server con dimensioni di macchine virtuali con possibilità di burst di serie B, ad esempio Standard_B1s/Standard_B1ms/Standard_B2s, le loro dimensioni di memoria host relativamente ridotte potrebbero causare arresti anomali (memoria insufficiente) in un carico di lavoro continuo, anche se la metrica memory_percent non ha raggiunto il 100%.
A causa di questa limitazione, il server potrebbe riscontrare problemi di connettività e le operazioni di sistema potrebbero essere compromesse. In tali situazioni, si consiglia di sospendere il carico di lavoro nel server per accumulare crediti in base al modello bancario di credito di serie B o valutare la possibilità di ridimensionare il server a livelli più elevati, ad esempio per utilizzo generico o Business critical.
Pertanto, mentre il livello di calcolo con possibilità di burst offre vantaggi significativi in termini di costi e flessibilità per determinati tipi di carichi di lavoro, non è consigliabile per carichi di lavoro di produzione che richiedono prestazioni omogenee della CPU. Il livello con possibilità di burst non supporta la funzionalità di creazione delle repliche in lettura in Database di Azure per MySQL - Server flessibile e la funzionalità Concetti relativi alla disponibilità elevata in Database di Azure per MySQL - Server. Altri livelli di calcolo, ad esempio per utilizzo generico o Business critical, sono più adatti per tali carichi di lavoro e funzionalità.
Per ulteriori informazioni sul modello di credito CPU di serie B di Azure, vedere le dimensioni delle macchine virtuali con possibilità di burst di serie B e il modello di credito della CPU di serie B.
Monitorare i crediti CPU nel livello con possibilità di burst
Il monitoraggio del saldo del credito CPU è fondamentale per mantenere prestazioni ottimali nel livello di calcolo con possibilità di burst. Il server flessibile di Database di Azure per MySQL offre due metriche chiave relative ai crediti CPU. La soglia ideale per l'attivazione di un avviso dipende da requisiti di carico di lavoro e prestazione.
Monitoraggio di Database di Azure per MySQL - Server flessibile: questa metrica indica il numero di crediti CPU utilizzati dall'istanza. Il monitoraggio di questa metrica consente di comprendere i criteri di utilizzo della CPU dell'istanza e di gestirne efficacemente le prestazioni.
Monitoraggio di Database di Azure per MySQL - Server flessibile: questa metrica mostra il numero di crediti CPU rimanenti per l’istanza. Il monitoraggio di questa metrica può aiutare a prevenire un peggioramento delle prestazioni dell’istanza a causa dell'esaurimento dei crediti CPU. Se la metrica Credito CPU rimanente scende al di sotto di un determinato livello (ad esempio, meno del 30% dei crediti disponibili totali), ciò indicherà che i crediti CPU dell'istanza sono a rischio di esaurimento se il carico CPU dovesse corrente continua continuare.
Per ulteriori informazioni su come configurare avvisi sulle metriche, vedere questa guida.
Storage
Lo spazio di archiviazione di cui si esegue il provisioning è la capacità di archiviazione disponibile per il server flessibile. Lo spazio di archiviazione viene usato per i file del database, i file temporanei, i log delle transazioni e i log del server MySQL. Per i livelli di servizio con possibilità di burst e per utilizzo generico, l'intervallo di archiviazione comprende da un minimo di 20 GiB a un massimo di 16 TiB. Per il livello di servizio Business critical, invece, il supporto di archiviazione comprende fino a 32 TiB. In tutti i livelli di servizio, l'archiviazione viene ridimensionata con incrementi di 1 GiB e può essere ridimensionata dopo la creazione del server.
Nota
L'archiviazione può essere solo aumentata, non ridotta.
È possibile monitorare il consumo di archiviazione nel portale di Azure (con Monitoraggio di Azure) usando le metriche di limite di archiviazione, percentuale di archiviazione e archiviazione utilizzata. Per informazioni sulle metriche, vedere l'articolo sul monitoraggio.
Raggiungere il limite di archiviazione
Quando lo spazio di archiviazione utilizzato nel server sta per raggiungere il limite di cui è stato effettuato il provisioning, il server passa alla modalità di sola lettura per proteggere eventuali scritture perse nel server. I server con uno spazio di archiviazione con provisioning di 100 GB o inferiore sono contrassegnati come di sola lettura se lo spazio di archiviazione disponibile è inferiore al 5% delle dimensioni di archiviazione con provisioning. I server con più di 100 GB di spazio di archiviazione con provisioning sono contrassegnati come di sola lettura quando lo spazio di archiviazione disponibile è inferiore a 5 GB.
Ad esempio, se è stato eseguito il provisioning di 110 GiB di spazio di archiviazione e l'utilizzo effettivo supera 105 GiB, il server viene contrassegnato come di sola lettura. In alternativa, se è stato eseguito il provisioning di 5 GiB di spazio di archiviazione, il server viene contrassegnato come di sola lettura quando lo spazio di archiviazione disponibile diventa inferiore a 256 MB.
Mentre il servizio tenta di impostare il server su sola lettura, tutte le nuove richieste di transazione di scrittura vengono bloccate e le transazioni attive esistenti continuano a essere eseguite. Quando il server è impostato su sola lettura, tutte le operazioni di scrittura e i commit delle transazioni successivi hanno esito negativo, ma le query di lettura continuano a funzionare senza interruzioni.
Per disattivare la modalità di sola lettura del server, è necessario aumentare lo spazio di archiviazione di cui è stato eseguito il provisioning nel server. A questo scopo è possibile usare il portale di Azure o l'interfaccia della riga di comando di Azure. Dopo avere aumentato lo spazio di archiviazione, il server sarà pronto per accettare nuovamente transazioni in scrittura.
È consigliabile configurare un avviso per ricevere una notifica quando l'archiviazione server sta per raggiungere la soglia, in modo tale da evitare di passare allo stato di sola lettura. Per ulteriori informazioni, vedere la documentazione che illustra come configurare un avviso.
Aumento automatico dell'archiviazione
L'aumento automatico dell'archiviazione evita che il server esaurisca l'archiviazione e passi a sola lettura. Se l'aumento automatico dell'archiviazione è abilitato, l'archiviazione aumenta automaticamente senza influire sul carico di lavoro. L'aumento automatico dell'archiviazione è abilitato per impostazione predefinita per tutte le nuove creazioni del server. Per i server con provisioning dello spazio di archiviazione minore di 100 GB, le dimensioni di archiviazione di cui è stato effettuato il provisioning vengono aumentate di 5 GB quando lo spazio di archiviazione disponibile scende al di sotto del 10% dell'archiviazione con provisioning. Per i server con provisioning dello spazio di archiviazione superiore a 100 GB, le dimensioni di archiviazione di cui è stato effettuato il provisioning vengono aumentate del 5% quando l'archiviazione disponibile scende al di sotto di 10 GB dimensioni di archiviazione di cui è stato effettuato il provisioning. Si applicano i limiti massimi di archiviazione come specificato sopra. Aggiornare l'istanza del server per visualizzare lo spazio di archiviazione di cui è stato effettuato il provisioning aggiornato in Impostazioni nella pagina Calcolo e archiviazione.
Ad esempio, se è stato effettuato il provisioning di 1.000 GB di spazio di archiviazione e l'utilizzo effettivo supera i 990 GB, le dimensioni di archiviazione del server vengono aumentate a 1.050 GB. In alternativa, se è stato effettuato il provisioning di 20 GB di spazio di archiviazione, le dimensioni di archiviazione vengono aumentate a 25 GB quando sono disponibili meno di 2 GB di spazio di archiviazione.
Tenere presente che l'archiviazione, una volta ridimensionata automaticamente, non può essere ridotta.
Nota
L'aumento automatico dell'archiviazione è abilitato per impostazione predefinita per server configurati a disponibilità elevata e non può essere disabilitato.
IOPS
Il server flessibile di Database di Azure per MySQL supporta operazioni di I/O al secondo su cui è stato effettuato il provisioning preliminare e operazioni di I/O al secondo con scalabilità automatica. Operazioni di I/O al secondo di archiviazione in Database di Azure per MySQL - Server flessibile Il numero minimo di operazioni di I/O al secondo è pari a 360 per tutte le dimensioni di calcolo e il numero massimo di operazioni di I/O al secondo è determinato dalle dimensioni di calcolo selezionate. Per ulteriori informazioni sul numero massimo di operazioni di I/O al secondo per ogni dimensione di calcolo, vedere la tabella.
Importante
**Il numero minimo di operazioni di I/O al secondo è 360 per tutte le dimensioni di calcolo
**Il numero massimo di operazioni di I/O al secondo è determinato dalle dimensioni di calcolo selezionate.
È possibile monitorare il consumo di I/O nel portale di Azure (con Monitoraggio di Azure) usando la metrica Monitoraggio di Database di Azure per MySQL - Server flessibile. Se sono necessarie più operazioni di I/O al secondo rispetto al numero massimo di operazioni di I/O al secondo in base al calcolo, sarà necessario ridimensionare il calcolo del server.
Operazioni di I/O al secondo con pre-provisioning
Il server flessibile di Database di Azure per MySQL offre operazioni IOPS con provisioning preliminare, cosa che consente di allocare un numero specifico di operazioni IOPS all'istanza del server flessibile di Database di Azure per MySQL. Questa impostazione garantisce prestazioni omogenee e prevedibili per i carichi di lavoro. Con operazioni di I/O al secondo con pre-provisioning, è possibile definire un limite di operazioni di I/O al secondo specifico per il volume di archiviazione, garantendo la possibilità di gestire alcune richieste al secondo. Ciò comporta un livello di prestazioni affidabile e garantito. Le operazioni di I/O al secondo con pre-provisioning consentono di effettuare il provisioning di operazioni di I/O al secondo aggiuntive oltre il limite di operazioni di I/O al secondo. Grazie a questa funzionalità, puoi anche incrementare o ridurre il numero di operazioni di I/O al secondo in base ai requisiti dei carichi di lavoro in qualsiasi momento.
Operazioni di I/O al secondo con scalabilità automatica
L'aspetto fondamentale del server flessibile di Database di Azure per MySQL è la possibilità di ottenere prestazioni ottimali per carichi di lavoro di livello 1. Ciò può essere ottimizzato consentendo al server di ridimensionare automaticamente le prestazioni dei server di database (I/O) in base alle esigenze del carico di lavoro. Questa funzionalità opzionale consente agli utenti di ridimensionare le operazioni di I/O su richiesta senza dover effettuare il pre-provisioning di una determinata quantità di I/O al secondo. Con l'abilitazione delle operazioni di I/O al secondo con scalabilità automatica, è ora possibile usufruire senza preoccupazioni della gestione delle operazioni I/O nel server flessibile del Database di Azure per MySQL, poiché il server ridimensiona automaticamente gli I/O in base alle esigenze del carico di lavoro.
Con le operazioni di I/O al secondo con scalabilità automatica, si paga solo per l'I/O usato dal server e non è più necessario effettuare il provisioning e pagare per risorse che non sono completamente usate, risparmiando tempo e denaro. Inoltre, le applicazioni di livello 1 cruciali possono ottenere prestazioni uniformi rendendo disponibili operazioni di I/O aggiuntive per il carico di lavoro in qualsiasi momento. La scalabilità automatica delle operazioni di I/O al secondo elimina l'amministrazione necessaria a garantire prestazioni ottimali per i clienti del server flessibile di Database di Azure per MySQL.
Scalabilità dinamica: le operazioni di I/O al secondo con scalabilità automatica regolano dinamicamente il limite di operazioni di I/O al secondo del server di database in base alla domanda effettiva del carico di lavoro. Ciò garantisce prestazioni ottimali senza intervento manuale o configurazione.
Gestione dei picchi di carico di lavoro: la scalabilità automatica delle operazioni di I/O al secondo consente al database di gestire facilmente picchi o fluttuazioni del carico di lavoro senza compromettere le prestazioni delle applicazioni. Questa funzionalità garantisce una velocità di risposta uniforme anche durante i periodi di picco di utilizzo.
Risparmio sui costi: a differenza delle operazioni di I/O al secondo con provisioning preliminare, in cui viene specificato un limite fisso di operazioni di I/O al secondo e si paga indipendentemente dall'utilizzo, le operazioni di I/O con scalabilità automatica consentono di pagare solo per il numero di operazioni di I/O utilizzate.
Backup
Il servizio esegue automaticamente il backup del server. È possibile selezionare un periodo di conservazione compreso tra 1 e 35 giorni. Ulteriori informazioni sui backup sono disponibili nell'articolo concetti relativi al backup e al ripristino.
Ridimensionare le risorse
Dopo aver creato il server, è possibile modificare in modo indipendente il livello di calcolo, le dimensioni di calcolo (vCore e memoria), la quantità di archiviazione e il periodo di conservazione dei backup. Le dimensioni di calcolo possono essere aumentate o ridotte e il periodo di conservazione dei backup può essere aumentato o ridotto tra 1 e 35 giorni. Le dimensioni dello spazio di archiviazione possono essere solo aumentate. Il ridimensionamento delle risorse può essere eseguito tramite il portale o l'interfaccia della riga di comando di Azure.
Nota
Le dimensioni dello spazio di archiviazione possono essere solo aumentate. Dopo che è stato effettuato un aumento, non è possibile tornare a una dimensione di archiviazione inferiore.
Quando si modificano il livello di calcolo o le dimensioni di calcolo, il server deve essere riavviato per rendere effettivo il nuovo tipo di server. Quando il sistema passa al nuovo server, non è possibile stabilire nuove connessioni e viene effettuato il rollback di tutte le transazioni di cui non è stato eseguito il commit. Questa finestra può variare, ma nella maggior parte dei casi è compresa tra 60 e 120 secondi.
Il ridimensionamento dell'archiviazione e la modifica del periodo di conservazione dei backup sono operazioni effettuate online che non richiedono un riavvio del server.
Price
Per le informazioni più aggiornate sui prezzi, vedere la pagina dei prezzi. Per informazioni sui costi della configurazione desiderata, il portale di Azure mostra i costi mensili nella scheda Calcolo e archiviazione in base alle opzioni selezionate. Se non è disponibile una sottoscrizione di Azure, è possibile usare il calcolatore dei prezzi di Azure per ottenere una stima. Nel sito Web del calcolatore prezzi di Azure, selezionare Aggiungi elementi, espandere la categoria Database, scegliere Database di Azure per MySQL e Server flessibile come tipo di distribuzione per personalizzare le opzioni.
Se si vogliono ottimizzare i costi del server, prendere in considerazione i seguenti suggerimenti:
- Ridurre il livello o le dimensioni di calcolo (vCore) se il calcolo è sottoutilizzato.
- Valutare la possibilità di passare dai livelli di utilizzo generico e Business critical al livello con possibilità di burst se il carico di lavoro non dovesse richiedere continuamente l‘intera capacità di calcolo.
- Sospendere il server quando non è in uso.
- Ridurre il periodo di conservazione dei backup se non è necessaria una conservazione più lunga dei backup.