Livelli di servizio del server flessibile di Database di Azure per MySQL
SI APPLICA A:
Database di Azure per MySQL - Server flessibile
È possibile creare un'istanza del server flessibile Database di Azure per MySQL in uno dei tre livelli di servizio diversi: Burstable, General Purpose e Business Critical. I livelli di servizio sono differenziati in base allo SKU di macchina virtuale sottostante usato 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 stessa tecnologia di archiviazione viene usata in tutti i livelli di servizio. Viene effettuato il provisioning di tutte le risorse a livello di istanza del server flessibile Database di Azure per MySQL. Un server può avere uno o più database.
| Risorsa/Livello | Burstable | Utilizzo generico | Business Critical |
|---|---|---|---|
| Serie VM | Serie B | Serie Ddsv5 serieDadsv4 | Serie Edsv4 Edsv5*/serie Eadsv5/ |
| 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 16 TiB |
| Periodo di conservazione dei backup dei database | Da 1 a 35 giorni | Da 1 a 35 giorni | Da 1 a 35 giorni |
** Con l'eccezione di 64.80 e 96 vCore, che ha rispettivamente 504 GiB, 504 GiB e 672 GiB di memoria.
* Ev5 compute offre prestazioni migliori tra le altre serie di macchine virtuali in termini di QPS e latenza. Altre informazioni sulla disponibilità delle prestazioni e dell'area di calcolo Ev5 sono disponibili qui.
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 i carichi di lavoro che non necessitano continuamente della CPU completa. |
| Utilizzo generico | La maggior parte dei carichi di lavoro aziendali che richiedono risorse di calcolo e di memoria bilanciate 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 richiede tra 60 e 120 secondi, mentre il ridimensionamento dell'archiviazione non richiede il riavvio. È anche possibile modificare in modo indipendente il periodo di conservazione dei backup verso l'alto o verso il basso. Per altre informazioni, vedere la sezione Ridimensionare le risorse.
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.
Le specifiche dettagliate dei tipi di server disponibili sono le seguenti per Burstable:
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni totali della memoria (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB Archiviazione temp (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 |
Le specifiche dettagliate dei tipi di server disponibili sono le seguenti per utilizzo generico:
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni totali della memoria (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB Archiviazione temp (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 |
Le specifiche dettagliate dei tipi di server disponibili sono le seguenti per Business Critical:
| Dimensioni di calcolo | vCore | Dimensioni della memoria fisica (GiB) | Dimensioni totali della memoria (GiB) | Numero massimo di operazioni di I/O al secondo supportate | Numero massimo di connessioni | GiB Archiviazione temp (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 | 48000 | 65536 | 906 |
| Standard_E48ads_v5 | 48 | 384 | 528 | 48000 | 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 | 72000 | 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 | 48000 | 65536 | 906 |
| Standard_E64ds_v5 | 64 | 512 | 704 | 64000 | 87383 | 1208 |
| Standard_E96ds_v5 | 96 | 672 | 924 | 80000 | 100000 | 2004 |
Gestione della memoria in Database di Azure per MySQL server flessibile
In MySQL la memoria svolge un ruolo importante in varie operazioni, tra cui l'elaborazione delle query e la memorizzazione nella cache. Database di Azure per MySQL server flessibile ottimizza l'allocazione di memoria per il processo del server MySQL (mysqld), assicurandosi che riceva risorse di memoria sufficienti per l'elaborazione efficiente delle query, la memorizzazione nella cache, la gestione delle connessioni client e la gestione dei thread. Altre informazioni su come MySQL usa la memoria.
Dimensioni della memoria fisica (GB)
La dimensione della memoria fisica (GB) nella tabella seguente rappresenta la memoria ad accesso casuale disponibile (RAM) in gigabyte (GB) nel server flessibile Database di Azure per MySQL.
Dimensioni totali della memoria (GB)
Database di Azure per MySQL server flessibile offre dimensioni totali della memoria (GB). Rappresenta la memoria totale disponibile per il server, ovvero una combinazione di memoria fisica e una quantità impostata di componenti SSD di archiviazione temporanea. Questa vista unificata è progettata per semplificare la gestione delle risorse, consentendo di concentrarsi sulla memoria totale disponibile solo per il processo mysql server (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 alle dimensioni totali della memoria (GB).This metric is calculated from the Total Memory Size (GB). Ad esempio, quando la metrica Percentuale memoria visualizza un valore pari a 60, significa che il processo del server MySQL di Azure usa il 60% delle dimensioni di memoria totale (GB) disponibili nel server flessibile Database di Azure per MySQL.
Server MySQL (mysqld)
Il processo del server MySQL di Azure, mysqld, funge da motore di base per le operazioni del database. All'avvio, inizializza i componenti totali, ad esempio il pool di buffer InnoDB e la cache dei thread, usando 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 migliorare 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 della tabella e gli indici in memoria per ridurre al minimo l'I/O del disco, migliorando le prestazioni. Il parametro Dimensioni pool di buffer innoDB viene calcolato in base alle dimensioni della memoria fisica (GB) disponibili nel server. Altre informazioni sulle dimensioni del pool di buffer InnoDB disponibile in Database di Azure per MySQL server flessibile.
Threads
Le connessioni client vengono gestite tramite thread dedicati gestiti dalla gestione connessione. Questi thread gestiscono l'autenticazione, l'esecuzione di query e il recupero dei risultati per le interazioni client. Altre informazioni.
Per altre informazioni sulla serie di calcolo disponibile, vedere la documentazione della macchina virtuale di Azure per burstable (serie B), la serieDdsv5 per utilizzo generico Ddsv4 e la serie/ Eadsv5 serie Business Critical Edsv4/Edsv5 serie Eadsv5.
Limitazioni delle prestazioni delle istanze di serie con burst
Nota
Per il livello di calcolo burstable (serie B) se la macchina virtuale viene avviata/arrestata o riavviata, è possibile che i crediti vadano persi. Per altre informazioni, vedere Domande frequenti su burstable (serie B).
Il livello di calcolo con burst è progettato per offrire una soluzione conveniente per i carichi di lavoro che non richiedono continuamente una CPU completa continua. Questo livello è ideale per carichi di lavoro non di produzione, ad esempio ambienti di sviluppo, gestione temporanea o test. La funzionalità univoca del livello di calcolo con burst è la possibilità di "burst", ovvero di usare più delle prestazioni della CPU di base usando fino al 100% della vCPU quando il carico di lavoro lo richiede. Ciò è reso possibile da un modello di credito CPU, che consente alle istanze della 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 oltre le prestazioni della CPU di base.
Tuttavia, è importante notare che una volta che un'istanza con burst esaurisce i crediti della CPU, opera alle prestazioni della CPU di base. Ad esempio, le prestazioni della CPU di base di un Standard_B1ms sono pari al 20%, ovvero 0,2 Vcore. Se il server livello burstable esegue un carico di lavoro che richiede prestazioni della CPU superiori al livello di base e ha esaurito i crediti CPU, il server potrebbe riscontrare limitazioni delle prestazioni e alla fine potrebbe influire su varie operazioni di sistema, ad esempio Arresto/Avvio/Riavvio per il server.
Nota
Per i server nel livello di calcolo burstable (serie B), ad esempio Standard_B1s/Standard_B1ms/Standard_B2s, le dimensioni di memoria host relativamente ridotte possono 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 interessate. In tali situazioni, il corso consigliato consiste nel sospendere il carico di lavoro nel server per accumulare crediti in base al modello bancario di credito serie B o per valutare la possibilità di ridimensionare il server a livelli più elevati, ad esempio livelli per utilizzo generico o business critical .
Pertanto, mentre il livello di calcolo burstable offre vantaggi significativi in termini di costi e flessibilità per determinati tipi di carichi di lavoro, non è consigliabile per i carichi di lavoro di produzione che richiedono prestazioni coerenti della CPU. Il livello burstable non supporta la funzionalità di creazione di repliche in lettura e funzionalità di disponibilità elevata. Per tali carichi di lavoro e funzionalità, altri livelli di calcolo, ad esempio per utilizzo generico o business critical, sono più appropriati.
Per altre informazioni sul modello di credito cpu della serie B di Azure, vedere le istanze con burst della serie B e il modello di credito cpu della serie B.
Monitoraggio dei crediti CPU nel livello burstable
Il monitoraggio del saldo del credito della CPU è fondamentale per mantenere prestazioni ottimali nel livello di calcolo con burst. Database di Azure per MySQL server flessibile fornisce due metriche chiave correlate ai crediti CPU. La soglia ideale per l'attivazione di un avviso dipende dai requisiti specifici di carico di lavoro e prestazioni.
Credito CPU utilizzato: questa metrica indica il numero di crediti CPU utilizzati dall'istanza. Il monitoraggio di questa metrica consente di comprendere i modelli di utilizzo della CPU dell'istanza e di gestirla in modo efficace.
Credito CPU rimanente: questa metrica mostra il numero di crediti CPU rimanenti per l'istanza. Tenere d'occhio questa metrica consente di impedire all'istanza di ridurre le prestazioni a causa dell'esaurimento dei crediti della CPU. Se la metrica Rimanente credito CPU scende al di sotto di un determinato livello (ad esempio, meno del 30% dei crediti disponibili totali), ciò indicherà che l'istanza è a rischio di esaurimento dei crediti CPU se il carico della CPU corrente continua.
Per altre informazioni su come configurare gli 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. Archiviazione viene usato per i file di database, i file temporanei, i log delle transazioni e i log del server MySQL. In tutti i livelli di servizio, lo spazio di archiviazione minimo supportato è 20 GiB e il massimo è 16 TiB. Archiviazione viene ridimensionato in incrementi di 1 GiB e può essere incrementato dopo la creazione del server.
Nota
L'archiviazione può essere solo aumentata, non ridotta.
È possibile monitorare il consumo di archiviazione nella portale di Azure (con Monitoraggio di Azure) usando le metriche usate per il limite di archiviazione, la percentuale di archiviazione e l'archiviazione. Per informazioni sulle metriche, vedere l'articolo sul monitoraggio.
Raggiungimento del 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 spazio di archiviazione con provisioning GiB inferiore a 100 GiB sono contrassegnati in sola lettura se lo spazio di archiviazione disponibile è inferiore al 5% delle dimensioni di archiviazione di cui è stato effettuato il provisioning. I server con più di 100 giB di archiviazione con provisioning vengono contrassegnati in lettura solo quando lo spazio di archiviazione disponibile è inferiore a 5 GiB.
Ad esempio, se è stato effettuato il provisioning di 110 GiB di spazio di archiviazione e l'utilizzo effettivo supera 105 GiB, il server è contrassegnato come di sola lettura. In alternativa, se è stato effettuato il provisioning di 5 GiB di archiviazione, il server viene contrassegnato come di sola lettura quando lo spazio di archiviazione disponibile raggiunge meno di 256 MB.
Mentre il servizio tenta di eseguire il server di 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 avranno esito negativo. 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. Una volta incrementato, il server è pronto ad accettare di nuovo le transazioni di scrittura.
È consigliabile configurare un avviso per ricevere una notifica quando l'archiviazione del server sta raggiungendo la soglia, in modo da evitare di accedere allo stato di sola lettura. Per altre informazioni, vedere la documentazione sulla documentazione sugli avvisi su come configurare un avviso.
Archiviazione aumento automatico
Archiviazione aumento automatico impedisce al server di esaurire lo spazio di archiviazione e di diventare di sola lettura. Se l'aumento automatico dell'archiviazione è abilitato, l'archiviazione aumenta automaticamente senza influire sul carico di lavoro. Archiviazione aumento automatico è abilitato per impostazione predefinita per tutti i nuovi server creati. Per i server con spazio di archiviazione con provisioning inferiore a 100 GB, le dimensioni di archiviazione con provisioning aumentano di 5 GB quando lo spazio di archiviazione disponibile è inferiore al 10% dello spazio di archiviazione di cui è stato effettuato il 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 aumentano a 25 GB quando sono disponibili meno di 2 GB di spazio di archiviazione.
Tenere presente che l'archiviazione dopo la scalabilità automatica non può essere ridotta.
Nota
Archiviazione aumento automatico è abilitato per impostazione predefinita per un server configurato a disponibilità elevata e non può essere disabilitato.
IOPS
Database di Azure per MySQL server flessibile supporta operazioni di I/O al secondo con provisioning preliminare e operazioni di I/O al secondo con scalabilità automatica. Altre informazioni. Le operazioni di I/O al secondo minime sono 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 altre informazioni sul numero massimo di operazioni di I/O al secondo per ogni dimensione di calcolo, vedere la tabella.
Importante
**Le operazioni di I/O al secondo minimo sono 360 per tutte le dimensioni di calcolo
**Le operazioni di I/O al secondo massime sono determinate dalle dimensioni di calcolo selezionate.
È possibile monitorare il consumo di I/O nel portale di Azure (con Monitoraggio di Azure) usando la metrica percentuale di I/O. 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, è necessario ridimensionare il calcolo del server.
Operazioni di I/O al secondo con provisioning preliminare
Database di Azure per MySQL server flessibile offre operazioni di I/O al secondo con provisioning preliminare, consentendo di allocare un numero specifico di operazioni di I/O al secondo all'istanza del server flessibile Database di Azure per MySQL. Questa impostazione garantisce prestazioni coerenti e prevedibili per i carichi di lavoro. Con il pre-provisioning delle operazioni di I/O al secondo, è 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 provisioning preliminare 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 di scalabilità automatica
L'elemento fondamentale di Database di Azure per MySQL server flessibile è la possibilità di ottenere prestazioni ottimali per i carichi di lavoro di livello 1, che possono essere migliorati abilitando le prestazioni di scalabilità automatica dei server di database (I/O) dei server di database in base alle esigenze del carico di lavoro. Si tratta di una funzionalità di consenso esplicito che 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 di scalabilità automatica in primo piano, è ora possibile usufruire della gestione delle operazioni di I/O gratuite in Database di Azure per MySQL server flessibile perché il server ridimensiona automaticamente le operazioni di I/O in base alle esigenze del carico di lavoro.
Con le operazioni di I/O al secondo di scalabilità automatica, si paga solo per l'uso del server di I/O e non è più necessario effettuare il provisioning e pagare le risorse che non usano completamente, risparmiando tempo e denaro. Inoltre, le applicazioni di livello 1 cruciali possono ottenere prestazioni coerenti 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 per offrire prestazioni ottimali al minimo per i clienti di server flessibili Database di Azure per MySQL.
Scalabilità dinamica: le operazioni di I/O al secondo di 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: le operazioni di I/O al secondo di scalabilità automatica consentono 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 coerente anche durante i periodi di utilizzo di picco.
Risparmio sui costi: a differenza delle operazioni di I/O al secondo con provisioning preliminare in cui viene specificato un limite di operazioni di I/O al secondo fisso e pagato indipendentemente dall'utilizzo, le operazioni di I/O con scalabilità automatica consentono di pagare solo per il numero di operazioni di I/O usate.
Backup
Il servizio esegue automaticamente il backup del server. È possibile selezionare un periodo di conservazione compreso tra 1 e 35 giorni. Altre 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) e la quantità di spazio di archiviazione e il periodo di conservazione dei backup. Le dimensioni di calcolo possono essere ridimensionate verso l'alto o verso il basso. Il periodo di conservazione dei backup può essere ridimensionato o ridotto da 1 a 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. Non è possibile tornare a una dimensione di archiviazione inferiore dopo l'aumento.
Quando si modifica il livello di calcolo o le dimensioni di calcolo, il server viene riavviato per rendere effettivo il nuovo tipo di server. Durante l'intervallo nel quale 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 varia, ma nella maggior parte dei casi, è compresa tra 60 e 120 secondi.
La scalabilità dell'archiviazione e la modifica del periodo di conservazione dei backup sono operazioni online e non richiedono un riavvio del server.
Prezzi
Per le informazioni più aggiornate sui prezzi, vedere la pagina dei prezzi. Per visualizzare il costo per la configurazione desiderata, il portale di Azure mostra il costo mensile 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 vuole ottimizzare i costi del server, è possibile prendere in considerazione i suggerimenti seguenti:
- Ridurre il livello di calcolo o le dimensioni di calcolo (vCore) se il calcolo è sottoutilizzato.
- Valutare la possibilità di passare al livello di calcolo burstable se il carico di lavoro non richiede la capacità di calcolo completa in modo continuo dai livelli Utilizzo generico e Business Critical.
- Arrestare il server quando non è in uso.
- Ridurre il periodo di conservazione dei backup se non è necessaria una conservazione più lunga del backup.
Contenuto correlato
- Informazioni su come creare un'istanza del server flessibile Database di Azure per MySQL nel portale.
- Informazioni sulle limitazioni del servizio.