Procedure consigliate per la compilazione di un'applicazione con Database di Azure per MySQL
SI APPLICA A:
Database di Azure per MySQL - Server singolo Database di Azure per MySQL - Server flessibile
Importante
Database di Azure per MySQL server singolo si trova nel percorso di ritiro. È consigliabile eseguire l'aggiornamento a Database di Azure per MySQL server flessibile. Per altre informazioni sulla migrazione a Database di Azure per MySQL server flessibile, vedere Che cosa accade a Database di Azure per MySQL server singolo?
Ecco alcune procedure consigliate per creare un'applicazione pronta per il cloud usando Database di Azure per MySQL. Queste procedure consigliate possono ridurre il tempo di sviluppo per l'app.
Configurazione delle risorse dell'applicazione e del database
Mantenere l'applicazione e il database nella stessa area
Assicurarsi che tutte le dipendenze si trovino nella stessa area durante la distribuzione dell'applicazione in Azure. La distribuzione delle varie istanze in aree o zone di disponibilità diverse causa latenza di rete, con potenziali effetti negativi sulle prestazioni complessive dell'applicazione.
Mantenere sicuro il server MySQL
Configurare il server MySQL in modo che sia sicuro e non accessibile pubblicamente. Usare una di queste opzioni per proteggere il server:
Per la sicurezza, è necessario connettersi sempre al server MySQL tramite SSL e configurare il server MySQL e l'applicazione per l'uso di TLS 1.2. Vedere Come configurare SSL/TLS.
Usare la rete avanzata con il servizio Azure Kubernetes
Quando la rete accelerata è abilitata in una macchina virtuale, è presente una latenza inferiore, una riduzione del jitter e una riduzione dell'utilizzo della CPU nella macchina virtuale. Per altre informazioni, vedere Procedure consigliate per servizio Azure Kubernetes e Database di Azure per MySQL.
Ottimizzare i parametri del server
Per ottimizzare i parametri tmp_table_size del server con carichi di lavoro con un numero elevato di operazioni di lettura e max_heap_table_size ottimizzare le prestazioni migliori. Per calcolare i valori necessari per queste variabili, esaminare i valori totali per connessione e memoria di base. Somma dei parametri di memoria per connessione, esclusi tmp_table_size, combinati con gli account di memoria di base per la memoria totale del server.
Per calcolare le dimensioni massime possibili di tmp_table_size e max_heap_table_size, usare la formula seguente:
(total memory - (base memory + (sum of per-connection memory * # of connections)) / # of connections
Nota
Memoria totale indica la quantità totale di memoria presente nel server tra i vCore di cui è stato effettuato il provisioning. Ad esempio, in un server Database di Azure per MySQL due vCore per utilizzo generico, la memoria totale sarà di 5 GB * 2. Per altre informazioni sulla memoria per ogni livello, vedere la documentazione del piano tariffario.
La memoria di base indica le variabili di memoria, ad esempio query_cache_size e innodb_buffer_pool_size, che MySQL inizializzerà e allocherà all'avvio del server. La memoria per connessione, ad esempio sort_buffer_size e join_buffer_size, è la memoria allocata solo quando è necessaria una query.
Creare utenti non amministratori
Creare utenti non amministratori per ogni database. In genere, i nomi utente vengono identificati come nomi di database.
Reimpostare la password
È possibile reimpostare la password per il server MySQL usando il portale di Azure.
La reimpostazione della password del server per un database di produzione può comportare l'arresto dell'applicazione. È consigliabile reimpostare la password per tutti i carichi di lavoro di produzione alle ore non di punta per ridurre al minimo l'impatto sugli utenti dell'applicazione.
Prestazioni e resilienza
Ecco alcuni strumenti e procedure per eseguire il debug dei problemi di prestazioni dell'applicazione.
Abilitare i log di query lente per identificare i problemi di prestazioni
È possibile abilitare log di query lente e log di controllo nel server. L'analisi dei log di query lente consente di identificare i colli di bottiglia delle prestazioni per la risoluzione dei problemi.
I log di controllo sono disponibili anche tramite i log di Diagnostica di Azure nei log di Monitoraggio di Azure, nei Hub eventi di Azure e negli account di archiviazione. Vedere Come risolvere i problemi di prestazioni delle query.
Utilizzare un pool di connessioni
La gestione delle connessioni di database può avere un impatto significativo sulle prestazioni dell'applicazione nel suo complesso. Per ottimizzare le prestazioni, è necessario ridurre il numero di connessioni stabilite e il tempo per stabilire connessioni nei percorsi di codice chiave. Usare il pool di connessioni per connettersi a Database di Azure per MySQL per migliorare la resilienza e le prestazioni.
È possibile usare il pool di connessioni ProxySQL per gestire le connessioni in modo efficiente. L'uso di un pooler di connessioni può ridurre le connessioni inattive e riutilizzare le connessioni esistenti, evitando così problemi. Per altre informazioni, vedere Come configurare ProxySQL .
Logica di ripetizione dei tentativi per gestire gli errori temporanei
L'applicazione potrebbe riscontrare errori temporanei in cui le connessioni al database vengono eliminate o perse in modo intermittente. In tali situazioni, il server è attivo e in esecuzione dopo uno o due tentativi in 5-10 secondi.
È consigliabile attendere 5 secondi prima del primo tentativo. Aumentare quindi gradualmente l'attesa per ogni tentativo successivo, fino a 60 secondi. Limitare il numero massimo di tentativi, a questo punto l'applicazione considera l'operazione non riuscita, in modo da poter analizzare ulteriormente. Per altre informazioni, vedere Come risolvere gli errori di connessione.
Abilitare la replica di lettura per attenuare i failover
Per gli scenari di failover, è possibile usare la replica dei dati in ingresso. Non si verifica alcun failover automatico tra server di origine e di replica quando si usano repliche in lettura.
Si noterà un ritardo tra l'origine e la replica perché la replica è asincrona. Il ritardo di rete può essere influenzato da molti fattori, ad esempio le dimensioni del carico di lavoro in esecuzione nel server di origine e la latenza tra data center. Nella maggior parte dei casi, il ritardo della replica varia da pochi secondi a pochi minuti.
Distribuzione di database
Configurare un'attività database di Azure per MySQL nella pipeline di distribuzione CI/CD
In alcuni casi, è necessario distribuire le modifiche al database. In questi casi, è possibile usare l'integrazione continua (CI) e il recapito continuo (CD) tramite Azure Pipelines e usare un'attività per il server MySQL per aggiornare il database eseguendo uno script personalizzato su di esso.
Usare un processo efficace per la distribuzione manuale del database
Durante la distribuzione manuale del database, seguire questa procedura per ridurre al minimo i tempi di inattività o ridurre il rischio di distribuzione non riuscita:
- Creare una copia di un database di produzione in un nuovo database usando mysqldump o MySQL Workbench.
- Aggiornare il nuovo database con le nuove modifiche dello schema o gli aggiornamenti necessari per il database.
- Inserire il database di produzione in uno stato di sola lettura. Sarebbe consigliabile non avere operazioni di scrittura nel database di produzione fino al completamento della distribuzione.
- Testare l'applicazione con il database appena aggiornato dal passaggio 1.
- Distribuire le modifiche dell'applicazione e assicurarsi che l'applicazione usi ora il nuovo database con gli aggiornamenti più recenti.
- Mantenere il database di produzione precedente per eseguire il rollback delle modifiche. È quindi possibile valutare di eliminare il database di produzione precedente o esportarlo in Archiviazione di Azure, se necessario.
Nota
Se l'applicazione è simile a un'app di e-commerce e non è possibile inserirla in uno stato di sola lettura, distribuire le modifiche direttamente nel database di produzione dopo aver eseguito un backup. Queste modifiche devono verificarsi durante le ore non di punta con traffico ridotto verso l'app per ridurre al minimo l'impatto perché alcuni utenti potrebbero riscontrare richieste non riuscite.
Assicurarsi che il codice dell'applicazione gestisca anche eventuali richieste non riuscite.
Usare le metriche native di MySQL per verificare se il carico di lavoro supera le dimensioni delle tabelle temporanee in memoria
Con un carico di lavoro di lettura elevato, le query sul server MySQL potrebbero superare le dimensioni delle tabelle temporanee in memoria. Un carico di lavoro di lettura elevato può causare il passaggio del server alla scrittura di tabelle temporanee su disco, che influiscono sulle prestazioni dell'applicazione. Per determinare se il server sta scrivendo su disco in seguito al superamento delle dimensioni temporanee della tabella, esaminare le metriche seguenti:
show global status like 'created_tmp_disk_tables';
show global status like 'created_tmp_tables';
La created_tmp_disk_tables metrica indica il numero di tabelle create su disco. Dato il carico di lavoro, la created_tmp_table metrica indica quante tabelle temporanee devono essere formate in memoria. Per determinare se una query specifica usa tabelle temporanee, eseguire l'istruzione EXPLAIN nella query. Il dettaglio nella extra colonna indica Using temporary se la query viene eseguita usando tabelle temporanee.
Per calcolare la percentuale del carico di lavoro con query di spilling su dischi, usare i valori delle metriche nella formula seguente:
(created_tmp_disk_tables / (created_tmp_disk_tables + created_tmp_tables)) * 100
Idealmente, questa percentuale deve essere inferiore al 25%. Se la percentuale è del 25% o superiore, è consigliabile modificare due parametri del server, tmp_table_size e max_heap_table_size.
Schema e query del database
Ecco alcuni suggerimenti da ricordare durante la compilazione dello schema e delle query del database.
Usare il tipo di dati corretto per le colonne della tabella
L'uso del tipo di dati corretto in base al tipo di dati da archiviare può ottimizzare l'archiviazione e ridurre gli errori a causa di tipi di dati non corretti.
Usare gli indici
Per evitare query lente, è possibile usare gli indici. Gli indici consentono di trovare rapidamente righe con colonne specifiche. Vedere Come usare gli indici in MySQL.
Usare EXPLAIN per le query edizione Standard LECT
Usare l'istruzione EXPLAIN per ottenere informazioni dettagliate sulle operazioni eseguite da MySQL per eseguire la query. Può essere utile per rilevare colli di bottiglia o problemi con la query. Vedere Come usare EXPLAIN per profilare le prestazioni delle query.