Condividi tramite

Procedure consigliate per la compilazione di un'applicazione con Database di Azure per MySQL

  • Articolo

SI APPLICA A:Database di Azure per MySQL - Server singolo Database di Azure per MySQL - Server flessibile

Importante

Il server singolo del Database di Azure per MySQL è in fase di ritiro. È consigliabile eseguire l'aggiornamento al server flessibile del Database di Azure per MySQL. Per altre informazioni sulla migrazione a Database di Azure per MySQL - Server flessibile, vedere Cosa succede 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 funzionalità di rete accelerata è abilitata in una macchina virtuale, si riduce la latenza, l'instabilità e l'utilizzo della CPU nella macchina virtuale. Per ulteriori informazioni, consultare Procedure consigliate per il servizio Azure Kubernetes e Database di Azure per MySQL.

Ottimizzare i parametri del server

Per ottimizzare i parametri del server con carichi di lavoro con un numero elevato di operazioni di lettura, tmp_table_size e max_heap_table_size possono contribuire all’ottimizzazione per ottenere prestazioni migliori. Per calcolare i valori necessari per queste variabili, esaminare i valori totali per connessione e memoria di base. La somma dei parametri di memoria per connessione, escluso 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

La 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 di Database di Azure per MySQL per utilizzo generico a due vCore, 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 fuori dalle ore 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 delle query lente può contribuire a identificare eventuali colli di bottiglia delle prestazioni e procedere alla risoluzione dei problemi.

I log di controllo sono disponibili anche tramite log di diagnostica di Azure in log di Monitoraggio di Azure, negli hub eventi di Azure e nell'account di archiviazione. Vedere 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, occorre ridurre il numero di connessioni stabilite e il tempo necessario per stabilire connessioni nei percorsi chiave del codice. Usare il pool di connessioni per connettersi a Database di Azure per MySQL per migliorare la resilienza e le prestazioni.

È possibile usare il pooler 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, entro 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, nel punto in cui l'applicazione considera l'operazione non riuscita, in modo da poter approfondire l'analisi. 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 le repliche di lettura.

Si riscontra un ritardo tra l'origine e la replica perché la replica è asincrona. Il ritardo sulla rete possono influire 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 è compreso tra pochi secondi e un paio di minuti.

Distribuzione di database

Configurare un'attività di 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:

  1. Creare una copia di un database di produzione in un nuovo database usando mysqldump o MySQL Workbench.
  2. Aggiornare il nuovo database con le nuove modifiche dello schema o gli aggiornamenti necessari per il database.
  3. 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.
  4. Testare l'applicazione con il database appena aggiornato dal passaggio 1.
  5. Distribuire le modifiche dell'applicazione e verificare che l'applicazione usi ora il nuovo database con gli aggiornamenti più recenti.
  6. Mantenere il database di produzione precedente per eseguire il rollback delle modifiche. È quindi possibile valutare se 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 al di fuori delle ore di punta, quando il traffico verso l'app è ridotto, in modo da minimizzare l'impatto poiché 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, influendo 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 metrica created_tmp_disk_tables indica il numero di tabelle create su disco. Dato il carico di lavoro, la metrica created_tmp_table indica quante tabelle temporanee devono essere formate in memoria. Per determinare se una specifica query usa tabelle temporanee, eseguire l'istruzione EXPLAIN nella query. Il dettaglio nella colonna extra indica Using temporary se la query viene eseguita usando tabelle temporanee.

Per calcolare la percentuale del carico di lavoro con query di spill 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 è maggiore o uguale al 25%, è consigliabile modificare due parametri del server, tmp_table_size e max_heap_table_size.

Schema del database e query

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 SELECT

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.