Che cos'è Database di Azure per MySQL - Server flessibile?
SI APPLICA A:
Database di Azure per MySQL - Server flessibile
Questo articolo offre una panoramica e un'introduzione ai concetti di base del modello di distribuzione del server flessibile. Per informazioni sull'opzione di distribuzione appropriata per il proprio carico di lavoro, vedere la scelta dell'opzione del server MySQL corretta in Azure.
Il server flessibile di Database di Azure per MySQL è un servizio di database relazionale in Microsoft Cloud basato sul motore di database MySQL Community Edition (disponibile con licenza GPLv2), versioni 5.6 (ritirata), 5.7 e 8.0. Il server flessibile di Database di Azure per MySQL fornisce:
- Disponibilità elevata con ridondanza della zona o nella stessa zona.
- Controllo massimo con la possibilità di selezionare la finestra di manutenzione pianificata.
- Protezione dati usando backup automatici e ripristino temporizzato per un periodo fino a 35 giorni.
- Manutenzione e applicazione automatica delle patch per hardware, sistema operativo e motore di database sottostanti per mantenere il servizio sempre sicuro e aggiornato.
- Prestazioni prevedibili, con piano tariffario tutto incluso e pagamento in base al consumo.
- Scalabilità elastica in pochi secondi.
- Controlli di ottimizzazione dei costi con SKU con possibilità di burst a basso costo e la possibilità di arrestare/avviare il server.
- Sicurezza di livello aziendale e conformità leader di settore, per proteggere dati sensibili inattivi e in transito.
- Monitoraggio e automazione per semplificare la gestione e il monitoraggio per distribuzioni su larga scala.
- Esperienza di supporto leader di settore.
Queste funzionalità richiedono attività di amministrazione minime e sono tutte disponibili senza costi aggiuntivi. Consentono di concentrarsi sullo sviluppo rapido di app e di accelerare i tempi di immissione nel mercato, evitando l'allocazione di tempo e risorse preziose per la gestione delle macchine virtuali e dell'infrastruttura. Inoltre, è possibile continuare a sviluppare l'applicazione con la piattaforma e gli strumenti open source preferiti per fornire la rapidità e l'efficienza per soddisfare i requisiti aziendali senza l'acquisizione di nuove competenze.
Panoramica
Il server flessibile di Database di Azure per MySQL è un servizio di database pronto per la produzione e completamente gestito, progettato per un controllo più granulare e una maggiore flessibilità rispetto alle funzioni di gestione e alle impostazioni di configurazione del database. L'architettura del server flessibile consente agli utenti di scegliere la disponibilità elevata all'interno di una singola zona di disponibilità e tra più zone di disponibilità. I server flessibili forniscono controlli di ottimizzazione dei costi migliori con la possibilità di arrestare/avviare il server e il livello di calcolo con possibilità di burst, ideale per i carichi di lavoro che non richiedono capacità di calcolo completa in modo continuo. Il server flessibile del Database di Azure per MySQL supporta anche istanze riservate che consentono di risparmiare fino al 63% dei costi; una soluzione ideale per i carichi di lavoro di produzione con requisiti di capacità di calcolo prevedibili. Il servizio supporta la versione community di MySQL 5.7 e 8.0. Il servizio è attualmente disponibile a livello generale in diverse aree di Azure.
L'opzione di distribuzione del server flessibile offre tre livelli di calcolo: Possibilità di burst, Utilizzo generico e Business critical. Ogni livello offre diverse capacità di calcolo e memoria per il supporto dei carichi di lavoro del database. È possibile compilare la prima app in un livello con possibilità di burst a fronte di un costo mensile minimo, quindi regolare la scalabilità in base ai requisiti della propria soluzione. La scalabilità dinamica consente al database di rispondere in modo trasparente ai requisiti delle risorse soggetti a rapidi cambiamenti. Si paga solo per le risorse necessarie e solo quando sono necessarie. Per informazioni dettagliate, vedere Calcolo e archiviazione.
I server flessibili sono ideali per
- Facilità di distribuzione, ridimensionamento semplificato e basso sovraccarico di gestione del database per i backup, disponibilità elevata, sicurezza e monitoraggio.
- Sviluppi di applicazioni che richiedono una versione della community di MySQL per aumentare il controllo e le personalizzazioni.
- Carichi di lavoro di produzione con la stessa zona, disponibilità elevata con ridondanza della zona e finestre di manutenzione gestite.
- Esperienza di sviluppo semplificata.
- Sicurezza, conformità e privacy di livello aziendale.
Per gli aggiornamenti più recenti sul server flessibile di Database di Azure per MySQL, vedere Novità nel server flessibile di Database di Azure per MySQL.
Offerta gratuita di 12 mesi
Con un account gratuito di Azure, è possibile usare il server flessibile di Database MySQL di Azure gratuitamente per 12 mesi, con limiti mensili fino a:
- 750 ore di istanza B1MS con possibilità di burst, sufficienti per eseguire un'istanza di database continuamente ogni mese.
- Archiviazione di 32 GB e archiviazione di backup di 32 GB.
È possibile usare questa offerta per sviluppare e distribuire applicazioni per il server flessibile di Database di Azure per MySQL. Per informazioni su come creare e usare gratuitamente il server flessibile di Database di Azure per MySQL tramite l'account gratuito di Azure, vedere questa esercitazione.
Disponibilità elevata in e tra zone di disponibilità
Il server flessibile di Database di Azure per MySQL consente di configurare la disponibilità elevata con failover automatico. La soluzione a disponibilità elevata è progettata per garantire che i dati di cui è stato eseguito il commit non vengano mai persi a causa di errori e per migliorare il tempo di attività complessivo per l'applicazione. Quando è configurata la disponibilità elevata, il server flessibile effettua automaticamente il provisioning e gestisce una replica di standby. All'utente viene addebitato il calcolo e l'archiviazione di cui è stato effettuato il provisioning per la replica primaria e secondaria. Esistono due modelli architetturali a disponibilità elevata:
- Disponibilità elevata (HA) con ridondanza della zona: questa opzione è preferibile per l'isolamento completo e la ridondanza dell'infrastruttura tra più zone di disponibilità. Offre il massimo livello di disponibilità, ma richiede la configurazione della ridondanza dell'applicazione tra le zone. La disponibilità elevata (HA) con ridondanza della zona è preferibile quando si desidera ottenere il massimo livello di disponibilità in caso di guasto dell'infrastruttura nella zona di disponibilità e quando la latenza nella zona di disponibilità è accettabile. La disponibilità elevata (HA) con ridondanza della zona è disponibile in un sottoinsieme di aree di Azure in cui l'area supporta più zone di disponibilità e sono disponibili condivisioni di file Premium con ridondanza della zona.
- Disponibilità elevata (HA) nella stessa zona: questa opzione è preferibile per la ridondanza dell'infrastruttura con una latenza di rete inferiore perché il server primario e di standby si trovano nella stessa zona di disponibilità. Offre una disponibilità elevata senza configurazione della ridondanza dell'applicazione tra le zone. La disponibilità elevata (HA) nella stessa zona è preferibile quando si desidera ottenere il massimo livello di disponibilità all'interno di una singola zona di disponibilità con la latenza di rete più bassa. La disponibilità elevata (HA) nella stessa zona è disponibile in tutte le aree di Azure in cui è possibile usare istanze del server flessibile di Database di Azure per MySQL.
Per altre informazioni, vedere i concetti di disponibilità elevata.
Applicazione automatica delle patch con la finestra di manutenzione gestita
Il servizio esegue l'applicazione automatica di patch dell'hardware, del sistema operativo e del motore di database sottostanti. L'applicazione di patch include aggiornamenti di sicurezza e software. Per il motore MySQL, sono inclusi anche aggiornamenti della versione secondaria nel rilascio della manutenzione pianificata. Gli utenti possono configurare la pianificazione dell'applicazione di patch in modo che sia gestita dal sistema o definire una pianificazione personalizzata. Durante la pianificazione della manutenzione, viene applicata la patch e potrebbe essere necessario riavviare il server come parte di questo processo di applicazione di patch per completare l'aggiornamento. Con la pianificazione personalizzata gli utenti possono prevedere il ciclo di applicazione delle patch e scegliere una finestra di manutenzione con un impatto minimo sull'attività. Il servizio segue una pianificazione di rilascio per il rilascio e l'integrazione continua.
Per altre informazioni, vedere Manutenzione pianificata.
Backup automatici
Il servizio del server flessibile di Database di Azure per MySQL crea automaticamente i backup del server e li invia nell'archiviazione con ridondanza geografica o ridondanza locale configurata dall'utente. I backup possono essere usati per ripristinare il server in modo temporizzato entro il periodo di conservazione del backup. Il periodo di conservazione predefinito è sette giorni, ma può essere impostato tra 1 e 35 giorni. Tutti i backup vengono crittografati con crittografia AES a 256 bit.
Per altre informazioni, vedere Concetti di backup.
Isolamento della rete
Per connettersi al server flessibile di Database di Azure per MySQL, sono disponibili due opzioni di rete: accesso privato (integrazione rete virtuale) e accesso pubblico (indirizzi IP consentiti).
Accesso privato (integrazione rete virtuale): è possibile distribuire il server flessibile di Database di Azure per MySQL nella rete virtuale di Azure. Le reti virtuali di Azure forniscono comunicazioni private e sicure. Le risorse di una rete virtuale possono comunicare tramite indirizzi IP privati.
Scegliere l'opzione di integrazione rete virtuale per ottenere le funzionalità seguenti:
- Connettersi dalle risorse di Azure nella stessa rete virtuale all'istanza del server flessibile di Database di Azure per MySQL usando indirizzi IP privati.
- Usare una VPN o Azure ExpressRoute per connettersi da risorse non di Azure all'istanza del server flessibile di Database di Azure per MySQL.
- Nessun endpoint pubblico.
Accesso pubblico (indirizzi IP consentiti): è possibile distribuire l'istanza del server flessibile di Database di Azure per MySQL con un endpoint pubblico. L'endpoint pubblico è un indirizzo DNS risolvibile pubblicamente. L'espressione "indirizzi IP consentiti" si riferisce a un intervallo di indirizzi IP a cui si sceglie di concedere l'autorizzazione per l'accesso al server. Queste autorizzazioni si definiscono regole del firewall.
Per altre informazioni, vedere Concetti di rete.
Regolare prestazioni e scalabilità in pochi secondi
Il server flessibile di Database di Azure per MySQL è disponibile in tre livelli di servizio: Possibilità di burst, Utilizzo generico e Business critical. Il livello Possibilità di burst è particolarmente adatto per lo sviluppo a basso costo e per carichi di lavoro a bassa concorrenza che non richiedono capacità di calcolo completa in modo continuo. Utilizzo generico e Business critical sono più adatti per carichi di lavoro di produzione che richiedono concorrenza elevata, scalabilità e prevedibilità delle prestazioni. È possibile compilare la prima app in un database di piccole dimensioni a fronte di un costo mensile minimo, quindi regolare con facilità la scalabilità in base ai requisiti della propria soluzione. Il dimensionamento dello spazio di archiviazione è online e supporta l'aumento automatico. Il server flessibile di Database di Azure per MySQL consente di effettuare il provisioning di operazioni di I/O al secondo aggiuntive fino a 80.000 operazioni di I/O al secondo oltre il limite di operazioni di I/O al secondo gratuito indipendente dall'archiviazione. 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. La scalabilità dinamica consente al database di rispondere in modo trasparente ai requisiti delle risorse soggetti a rapidi cambiamenti. Verranno addebitati i costi solo per le risorse usate.
Per altre informazioni, vedere Concetti di calcolo e archiviazione.
Aumentare il carico di lavoro di lettura con un totale di 10 repliche in lettura
MySQL è uno dei motori di database più diffusi per l'esecuzione di applicazioni Web e per dispositivi mobili su scala Internet. I clienti di Microsoft lo usano per la formazione online, lo streaming di video, soluzioni di pagamento digitale, piattaforme di e-commerce, servizi per videogiochi, portali di notizie, siti Web di enti pubblici e assistenza sanitaria. Questi servizi devono poter essere ampliati con l'aumento del traffico delle applicazioni Web o per dispositivi mobili.
Sul lato applicazioni, l'applicazione generalmente viene sviluppata in Java o PHP e migrata per l'esecuzione in set di scalabilità di macchine virtuali di Azure o Servizi app Azure oppure containerizzata per l'esecuzione nel servizio Azure Kubernetes (AKS). Usando il set di scalabilità di macchine virtuali, il servizio app o il servizio Azure Kubernetes come infrastruttura sottostante, si semplifica il ridimensionamento dell'applicazione tramite il provisioning istantaneo di nuove VM e la replica dei componenti senza stato dell'applicazione per soddisfare le richieste, ma spesso il database finisce col diventare un collo di bottiglia come componente con stato centralizzato.
La funzionalità di replica in lettura consente di replicare i dati di un'istanza del server flessibile di Database di Azure per MySQL in un server di sola lettura. È possibile creare fino a 10 repliche da un server di origine. Le repliche vengono aggiornate in modo asincrono tramite la tecnologia di replica basata sulla posizione del file di log binario (binlog) nativo del motore MySQL. È possibile usare una soluzione proxy del servizio di bilanciamento del carico come ProxySQL per aumentare in modo omogeneo il carico di lavoro dell'applicazione per repliche in lettura senza costi di refactoring dell'applicazione.
Per altre informazioni, vedere Concetti - Repliche in lettura.
Configurare la sincronizzazione di dati ibridi o multicloud con la replica dei dati in ingresso
La replica dei dati in ingresso consente di sincronizzare i dati da un server MySQL esterno nel server flessibile di Database di Azure per MySQL. Il server esterno può trovarsi in locale, in macchine virtuali, in un singolo server di Database di Azure per MySQL o può essere un servizio di database ospitato da altri provider di servizi cloud. La replica dei dati in ingresso si basa sulla posizione nel file di log binario (binlog). Gli scenari principali da considerare riguardo all’uso della replica dei dati in ingresso sono i seguenti:
- Sincronizzazione di dati ibrida
- Sincronizzazione multicloud
- Migrazione con tempo di inattività minimo al server flessibile di Database di Azure per MySQL
Per altre informazioni, vedere Concetti di replica dei dati in ingresso.
Arrestare/avviare il server per ottimizzare i costi
Il server flessibile di Database di Azure per MySQL consente di arrestare e avviare il server su richiesta per ottimizzare i costi. La fatturazione del livello di calcolo viene interrotta immediatamente quando il server viene arrestato. Questa funzionalità può consentire un notevole risparmio sui costi durante lo sviluppo, il test e i carichi di lavoro di produzione prevedibili con limiti temporali. Il server rimane in stato arrestato per 30 giorni a meno che non venga riavviato prima.
Per altre informazioni, vedere Concetti di server.
Sicurezza, conformità e privacy di livello aziendale
Il server flessibile di Database di Azure per MySQL usa il modulo crittografico convalidato FIPS 140-2 per la crittografia dei dati archiviati inattivi. I dati, inclusi i backup e i file temporanei creati durante l'esecuzione di query, vengono crittografati. Il servizio usa la crittografia AES a 256 bit inclusa nella crittografia di archiviazione di Azure e le chiavi possono essere gestite dal sistema (predefinito). È anche possibile usare una chiave CMK (Customer Manager Key) o BYOK (Bring You Own Key) archiviata in Azure Key Vault o HSM (Hardware Security Module) gestito per la crittografia dei dati inattivi.
Per altre informazioni, vedere la crittografia dei dati con chiavi gestite dal cliente per le istanze del server flessibile di Database di Azure per MySQL.
Il server flessibile di Database di Azure per MySQL esegue la crittografia dei dati in transito con TLS (Transport Layer Security) applicato per impostazione predefinita. Il server flessibile di Database di Azure per MySQL supporta solo connessioni crittografate con Transport Layer Security (TLS 1.2) e tutte le connessioni in ingresso con TLS 1.0 e TLS 1.1 vengono negate. È possibile disabilitare l'imposizione TSL/SSL impostando il parametro del server require_secure_transport e quindi impostando il tls_version minimo per il server.
Per altre informazioni, vedere come usare connessioni crittografate alle istanze del server flessibile di Database di Azure per MySQL.
Le istanza del server flessibile di Database di Azure per MySQL consentono l'accesso privato completo ai server tramite l'integrazione della rete virtuale di Azure (rete virtuale). I server nella rete virtuale di Azure possono essere raggiunti e connessi solo tramite indirizzi IP privati. Con l'integrazione della rete virtuale, l'accesso pubblico viene negato e non è possibile raggiungere i server usando endpoint pubblici.
Per altre informazioni, vedere Concetti di rete.
Monitoraggio e avviso
Il server flessibile di Database di Azure per MySQL è dotato di funzionalità predefinite di monitoraggio e avvisi delle prestazioni. Tutte le metriche di Azure hanno una frequenza di un minuto e offrono ciascuna una cronologia di 30 giorni. È possibile configurare avvisi in base alle metriche. Il server flessibile di Database di Azure per MySQL espone le metriche del server host per monitorare l'uso delle risorse e consente la configurazione di log di query lente. Grazie a questi strumenti è possibile ottimizzare rapidamente i carichi di lavoro e configurare il server per ottenere prestazioni ottimali. Database di Azure, che è un server MySQL flessibile, consente di visualizzare dati di log di controllo e query lente tramite cartelle di lavoro di Monitoraggio di Azure. Con le cartelle di lavoro è possibile ottenere un canvas flessibile per l'analisi dei dati e la creazione di report visivi all'interno del portale di Azure. Il server flessibile di Database di Azure per MySQL offre tre modelli di cartella di lavoro pronti all'uso, incluso Panoramica del server, Controllo e Query Performance Insights. La cartella di lavoro Query Performance Insights consente di dedicare meno tempo alla risoluzione dei problemi di prestazioni del database offrendo i vantaggi seguenti:
- Prime N query a esecuzione prolungata e relative tendenze.
- Dettagli della query: visualizzare il testo della query e la cronologia di esecuzione con tempo di query minimo, massimo, medio e deviazione standard.
- Uso delle risorse (CPU, memoria e archiviazione).
Inoltre, è possibile l'uso e l'integrazione con strumenti di monitoraggio della community come Percona Monitoring and Management con il server flessibile di Database di Azure per MySQL.
Per altre informazioni, vedere Concetti di monitoraggio.
Migrazione
Il server flessibile di Database di Azure per MySQL esegue la versione della community di MySQL. Ciò consente la compatibilità completa delle applicazioni e richiede un costo di refactoring minimo per eseguire la migrazione di applicazioni esistenti sviluppate sul motore di MySQL a un server flessibile di Database di Azure per MySQL. La migrazione al server flessibile di Database di Azure per MySQL può essere eseguita usando l'opzione seguente:
Migrazioni offline
- L'uso del servizio di migrazione dei dati di Azure quando la larghezza di banda di rete tra l'origine e Azure è ottimale, ad esempio ExpressRoute ad alta velocità. Per altre informazioni, vedere istruzioni dettagliate: Eseguire la migrazione offline di MySQL al server flessibile di Database di Azure per MySQL tramite Servizio Migrazione del database di Azure (DMS)
- Usare mydumper/myloader per usare le impostazioni di compressione per spostare in modo efficiente i dati su reti a bassa velocità (ad esempio Internet pubblico). Per altre informazioni, vedere le istruzioni dettagliate: Eseguire la migrazione di database di grandi dimensioni al server flessibile di Database di Azure per MySQL usando mydumper/myloader
Migrazioni online o con tempo di inattività minimo
Usare la replica dei dati in ingresso con backup/ripristino coerente con mydumper/myloader per il seeding iniziale. Per altre informazioni, vedere le istruzioni dettagliate: Esercitazione: Migrazione con tempo di inattività minimo per server singolo di Database di Azure per MySQL al server flessibile di Database di Azure per MySQL.
Per eseguire la migrazione dal server singolo di Database di Azure per MySQL al server flessibile di Database di Azure per MySQL in cinque passaggi semplici, fare riferimento a questo blog.
Per altre informazioni, vedere Selezionare gli strumenti appropriati per la migrazione al server flessibile di Database di Azure per MySQL.
Aree di Azure
Uno dei vantaggi dell'esecuzione del carico di lavoro in Azure è la copertura globale. Il server flessibile di Database di Azure per MySQL ora è disponibile nelle aree di Azure seguenti:
| Paese | Disponibilità | Disponibilità elevata (HA) nella stessa zona | Disponibilità elevata con ridondanza della zona | Backup con ridondanza geografica |
|---|---|---|---|---|
| Australia centrale | ✔️ | ✔️ | ❌ | ❌ |
| Australia orientale | ✔️ | ✔️ | ✔️ | ✔️ |
| Australia sud-orientale | ✔️ | ✔️ | ❌ | ✔️ |
| Brasile meridionale | ✔️ | ✔️ | ✔️ | ✔️ |
| Canada centrale | ✔️ | ✔️ | ✔️ | ✔️ |
| Canada orientale | ✔️ | ✔️ | ❌ | ✔️ |
| India centrale | ✔️ | ✔️ | ✔️ | ✔️ |
| Stati Uniti centrali | ✔️ | ✔️ | ❌ | ✔️ |
| Cina orientale 2 | ✔️ | ✔️ | ❌ | ✔️ |
| Cina orientale 3 | ✔️ | ✔️ | ❌ | ✔️ |
| Cina settentrionale 2 | ✔️ | ✔️ | ❌ | ✔️ |
| Cina settentrionale 3 | ✔️ | ✔️ | ✔️ | ✔️ |
| Asia orientale (RAS di Hong Kong) | ✔️ | ✔️ | ✔️ | ✔️ |
| Stati Uniti orientali | ✔️ | ✔️ | ✔️ | ✔️ |
| Stati Uniti orientali 2 | ✔️ | ✔️ | ✔️ | ✔️ |
| Francia centrale | ✔️ | ✔️ | ✔️ | ✔️ |
| Francia meridionale | ✔️ | ✔️ | ❌ | ✔️ |
| Germania centro-occidentale | ✔️ | ✔️ | ✔️ | ✔️ |
| Germania settentrionale | ✔️ | ✔️ | ❌ | ✔️ |
| Israele centrale | ✔️ | ✔️ | ✔️ | ❌ |
| Italia settentrionale | ✔️ | ✔️ | ✔️ | ❌ |
| Giappone orientale | ✔️ | ✔️ | ✔️ | ✔️ |
| Giappone occidentale | ✔️ | ✔️ | ❌ | ✔️ |
| India occidentale Jio | ✔️ | ✔️ | ❌ | ❌ |
| Corea centrale | ✔️ | ✔️ | ✔️ | ✔️ |
| Corea meridionale | ✔️ | ✔️ | ❌ | ✔️ |
| Stati Uniti centro-settentrionali | ✔️ | ✔️ | ❌ | ✔️ |
| Europa settentrionale | ✔️ | ✔️ | ✔️ | ✔️ |
| Norvegia orientale | ✔️ | ✔️ | ✔️ | ✔️ |
| Norvegia occidentale | ✔️ | ✔️ | ❌ | ❌ |
| Polonia Centrale | ✔️ | ✔️ | ❌ | ❌ |
| Qatar centrale | ✔️ | ✔️ | ✔️ | ❌ |
| Sudafrica settentrionale | ✔️ | ✔️ | ✔️ | ❌ |
| Sudafrica occidentale | ✔️ | ✔️ | ❌ | ❌ |
| Stati Uniti centro-meridionali | ✔️ | ✔️ | ✔️ | ✔️ |
| India meridionale | ✔️ | ✔️ | ❌ | ✔️ |
| Asia sud-orientale | ✔️ | ✔️ | ✔️ | ✔️ |
| Spagna centrale | ✔️ | ✔️ | ❌ | ✔️ |
| Svezia centrale | ✔️ | ✔️ | ✔️ | ❌ |
| Svizzera settentrionale | ✔️ | ✔️ | ✔️ | ✔️ |
| Svizzera occidentale | ✔️ | ✔️ | ❌ | ✔️ |
| Taiwan settentrionale | ✔️ | ✔️ | ❌ | ❌ |
| Taiwan Nord-Occidentale | ✔️ | ✔️ | ❌ | ❌ |
| Emirati Arabi Uniti centrali | ✔️ | ✔️ | ❌ | ✔️ |
| Emirati Arabi Uniti settentrionali | ✔️ | ✔️ | ✔️ | ✔️ |
| Regno Unito meridionale | ✔️ | ✔️ | ✔️ | ✔️ |
| Regno Unito occidentale | ✔️ | ✔️ | ❌ | ✔️ |
| USGov Virginia | ✔️ | ✔️ | ❌ | ❌ |
| USGov Arizona | ✔️ | ✔️ | ❌ | ✔️ |
| USGov Texas | ✔️ | ✔️ | ❌ | ✔️ |
| Stati Uniti centro-occidentali | ✔️ | ✔️ | ❌ | ✔️ |
| Europa occidentale | ✔️ | ✔️ | ✔️ | ✔️ |
| Stati Uniti occidentali | ✔️ | ✔️ | ❌ | ✔️ |
| Stati Uniti occidentali 2 | ✔️ | ✔️ | ✔️ | ✔️ |
| Stati Uniti occidentali 3 | ✔️ | ✔️ | ✔️ | ✔️ |
Feedback e supporto
Per eventuali domande o suggerimenti sull'uso del server flessibile di Database di Azure per MySQL, prendere in considerazione i punti di contatto seguenti:
- Per contattare il supporto di Azure, creare un ticket dal portale di Azure.
- Per risolvere un problema relativo all'account, inviare una richiesta di supporto nel portale di Azure.
- Per fornire commenti e suggerimenti o richiedere nuove funzionalità, creare una richiesta tramite UserVoice.
Contenuto correlato
- Creare un'istanza del server flessibile di Database di Azure per MySQL tramite il portale di Azure
- Creare un'istanza del server flessibile di Database di Azure per MySQL tramite l'interfaccia della riga di comando di Azure
- Gestire un server flessibile di Database di Azure per MySQL tramite l'interfaccia della riga di comando di Azure
- Python
- PHP