Procedure consigliate per prestazioni ottimali di Database di Azure per MySQL - Server flessibile
Informazioni su come ottenere prestazioni ottimali durante l'uso di Database di Azure per MySQL server flessibile. Man mano che si aggiungono nuove funzionalità alla piattaforma, si continuerà a perfezionare le raccomandazioni in questa sezione.
Prossimità fisica
Assicurarsi di distribuire un'applicazione e il database nella stessa area. Prima di avviare qualsiasi esecuzione del benchmarking delle prestazioni, è necessario verificare rapidamente la latenza di rete tra il client e il database usando una semplice query SELECT 1.
Quando le risorse come un'applicazione Web e il database associato vengono eseguite in aree diverse, potrebbe verificarsi una maggiore latenza nella comunicazione tra tali risorse. Un altro effetto collaterale possibile di avere l'applicazione e il database in aree separate è correlato ai costi di trasferimento dei dati in uscita.
Per migliorare le prestazioni e l'affidabilità di un'applicazione in una distribuzione ottimizzata per i costi, è consigliabile che il servizio applicazione Web e la risorsa server flessibile Database di Azure per MySQL si trovino nella stessa area e nella stessa zona di disponibilità. Questa condivisione è ideale per le applicazioni sensibili alla latenza e offre anche la migliore velocità effettiva, in quanto le risorse sono strettamente abbinate.
Rete accelerata
Usare la rete accelerata per il server applicazioni se si usa una macchina virtuale di Azure, Azure Kubernetes o Servizi app. La funzionalità Rete accelerata abilita Single Root I/O Virtualization (SR-IOV) per le macchine virtuali (VM), migliorandone le prestazioni di rete. Questo percorso a prestazioni elevate esclude l'host dal percorso dati, riducendo così la latenza, l'instabilità e l'utilizzo della CPU e può essere usato con i carichi di lavoro di rete più impegnativi nei tipi di VM supportati.
Efficienza della connessione
Stabilire una nuova connessione è sempre un'attività costosa e dispendiosa in termini di tempo. Quando un'applicazione richiede una connessione di database, assegna la priorità all'allocazione di connessioni di database inattive esistenti anziché crearne una nuova. Ecco alcune opzioni per le procedure di connessione consigliate:
ProxySQL: usare ProxySQL, che fornisce il pool di connessioni predefinito, e bilanciare il carico di lavoro a più repliche in lettura in base alle esigenze con eventuali modifiche nel codice dell'applicazione.
Proxy dati Heimdall: in alternativa, è anche possibile usare Heimdall Data Proxy, una soluzione proxy proprietaria indipendente dal fornitore. Supporta la memorizzazione nella cache delle query e la suddivisione in lettura/scrittura con il rilevamento del ritardo della replica. È anche possibile fare riferimento a come accelerare le prestazioni di MySQL con il proxy Heimdall.
Connessione persistente o di lunga durata: se l'applicazione dispone di transazioni o query brevi in genere con tempo di esecuzione < 5-10 ms, sostituire le connessioni brevi con connessioni persistenti. Sostituire le connessioni brevi con connessioni persistenti richiede solo modifiche minime al codice, ma ha un effetto importante in termini di miglioramento delle prestazioni in molti scenari tipici dell'applicazione. Assicurarsi di impostare il timeout o chiudere la connessione al termine della transazione.
Replica: se si usa la replica, usare ProxySQL per bilanciare il carico tra il server primario e il server di replica secondaria leggibile. Informazioni su come configurare ProxySQL.
Pool di connessioni
Il pool di connessioni è un meccanismo che gestisce la creazione e l'allocazione delle connessioni di database e protegge un database da picchi di connessione. Prendere in considerazione il pool di connessioni se l'applicazione apre molte connessioni in tempi relativamente brevi e le connessioni sono di breve durata. Questi tipi di connessioni possono verificarsi, ad esempio, su una grandezza di centinaia o migliaia al secondo, e il tempo necessario per stabilire e chiuderli è significativo rispetto alla durata totale della connessione.
Se il framework di sviluppo dell'applicazione non supporta il pool di connessioni, usare invece un proxy di connessione, ad esempio ProxySQL o Heimdall proxy, tra l'applicazione e il server di database.
Gestire il ridimensionamento delle connessioni
Un approccio comune per il ridimensionamento delle applicazioni Web per soddisfare la domanda fluttuante consiste nell'aggiungere e rimuovere server applicazioni. Ogni server applicazioni può usare un pool di connessioni con il database. Questo approccio determina l'aumento del numero totale di connessioni in un server di database rispetto al numero di server applicazioni. Ad esempio, se un server di database dispone di 10 server applicazioni e ognuno di essi è configurato per 100 connessioni di database, ciò fornirà 1.000 connessioni di database. Se il carico di lavoro dell'applicazione viene ridimensionato a causa di un'attività utente superiore o durante le ore di punta e se vengono aggiunti altri 50 server applicazioni, le connessioni al database totali sarebbero pari a 6.000. In genere, la maggior parte di queste connessioni sarà inattiva, dopo essere stata creata dai server applicazioni. Poiché le connessioni inattive usano risorse (memoria e CPU) per rimanere aperte, la scalabilità del database potrebbe essere interessata.
Altre potenziali sfide comportano la gestione del numero totale di connessioni al server di database. Ciò dipende dal numero di server applicazioni connessi al server di database, ognuno dei quali crea un proprio set di connessioni. In questi scenari è consigliabile modificare i pool di connessioni nei server applicazioni. Provare a ridurre il numero di connessioni in ogni pool a un minimo accettabile per garantire che non siano presenti connessioni sul lato server di database. Considerare questo come un rimedio a breve termine per contrastare gli effetti del ridimensionamento del server applicazioni anziché una soluzione permanente per affrontare la crescita dell'applicazione.
Come soluzione a lungo termine, introdurre un proxy di connessione, ad esempio ProxySQL o Heimdall proxy, tra il server di database e il server applicazioni. Ciò è utile perché il proxy:
- Stabilirà una connessione al server di database con un numero fisso di connessioni.
- Accetterà le connessioni dell'applicazione e fungerà da buffer per potenziali tempeste di connessione.
I proxy possono fornire altre funzionalità, ad esempio la memorizzazione nella cache delle query, il buffer di connessione, la riscrittura/routing delle query e il bilanciamento del carico. Per una scalabilità ancora maggiore, è consigliabile usare più istanze proxy.
Gestione delle connessioni per la tolleranza di errore e ripristino più rapido
Quando si progettano applicazioni e ambienti per la tolleranza di errore e un ripristino più rapido, considerare che in un ambiente di database è probabile che si verifichino interruzioni della connessione o errori hardware. Tenere presente anche la necessità di azioni operative, ad esempio ridimensionamento delle dimensioni delle istanze, applicazione di patch ed esecuzione del failover manuale.
Si consideri, ad esempio, uno scenario in cui il server di database completa il failover entro un minuto, ma l'applicazione è inattiva per diversi minuti a causa di elementi come il TTL DNS troppo lungo sul lato applicazione. In questi casi, la semplice riduzione del valore TTL fornirà un ripristino più rapido o l'integrazione di un proxy di connessione tra l'applicazione e il server di database può aiutare a gestire tali errori.
Partizione
Quando il carico di lavoro di produzione usa tabelle estremamente grandi, il partizionamento è un ottimo metodo per migliorare le prestazioni del database e semplificare la manutenzione. Il partizionamento semplifica la gestione di tabelle di grandi dimensioni, questo approccio consente di aggiungere ed eliminare partizioni per gestire in modo efficace tabelle di grandi dimensioni. Il partizionamento può anche aiutare il motore a ridurre la contesa interna della struttura, ad esempio blocchi interni per tabella o per indice (ad esempio, prendere in considerazione il btr_search_latch in InnoDB).
Aggiungendo cinque partizioni, ad esempio, si suddivide essenzialmente una tabella di grandi dimensioni con molte attività in cinque tabelle più piccole ed efficienti. Ciò può essere utile principalmente per i casi in cui l'operazione principale è la ricerca di chiavi primarie nella tabella, in modo che le query possano sfruttare l'"eliminazione della partizione". Tuttavia, il partizionamento può essere utile anche in termini di analisi delle tabelle.
Anche se il partizionamento offre vantaggi, presenta anche alcune limitazioni, ad esempio la mancanza di supporto per le chiavi esterne nelle tabelle partizionate, la mancanza di cache delle query e così via. Per un elenco completo di queste limitazioni, vedere il capitolo Restrizioni e limitazioni sul partizionamento nel manuale di riferimento di MySQL.
Separare letture e scritture
La maggior parte delle applicazioni legge principalmente dal database, con solo una piccola percentuale delle interazioni che coinvolgono scritture. Il numero di connessioni attive nel database primario calcolato per i pool di connessioni include probabilmente il traffico di lettura. L'offload del maggior numero possibile di query per le repliche in lettura e la conservazione dell'accesso all'istanza scrivibile primaria aumenta la quantità di attività complessiva del database eseguita dai server applicazioni senza aumentare il carico sul database primario. Se non si accede già alle repliche in lettura almeno per query con esecuzione più lunga, ad esempio i report, è consigliabile spostare immediatamente report o analisi in repliche in lettura.
Un uso più ampio della scalabilità delle repliche in lettura potrebbe richiedere una considerazione più attenta, perché le repliche ritardano leggermente rispetto alla replica primaria a causa della natura asincrona della replica. Trovare il maggior numero possibile di aree dell'applicazione che possono essere gestite con letture dalle repliche con modifiche minime al codice. È anche consigliabile applicare questo metodo a livelli più elevati relativi alla memorizzazione nella cache, che consentono di usare più contenuto di sola lettura o a modifica lenta da un livello di memorizzazione nella cache dedicato, ad esempio Cache Redis di Azure.
Ridimensionamento e partizionamento orizzontale delle operazioni di scrittura
Nel corso del tempo, le applicazioni si evolvono e vengono aggiunte nuove funzionalità. Per praticità o pratica generale, le tabelle vengono aggiunte al database primario. Per gestire carichi di traffico in crescita in un database, identificare le aree dell'applicazione che possono essere spostate facilmente in database separati e prendere in considerazione la suddivisione orizzontale o la suddivisione verticale del database.
Il partizionamento orizzontale di un database funziona creando più copie dello schema dell'applicazione in database separati e separando i clienti e tutti i dati associati in base all'ID cliente, all'area geografica o ad altri attributi per cliente o tenant. Questo funziona molto bene per le applicazioni SaaS o B2C in cui i singoli clienti sono piccoli e il carico sull'applicazione dipende dall'utilizzo aggregato di milioni di clienti. Tuttavia, è più difficile con le applicazioni B2B in cui i clienti hanno dimensioni diverse e singoli clienti di grandi dimensioni potrebbero dominare il carico di traffico per una particolare partizione.
Suddividere il carico verticalmente partizionando il database in modo funzionale, spostando domini applicazione separati (o microservizi) nei propri database. In questo modo il carico viene distribuito dal database primario per separare i database per servizio. Esempi semplici includono una tabella di registrazione o informazioni di configurazione del sito che non devono trovarsi nello stesso database della tabella ordini caricata pesantemente. Esempi più complessi includono l'interruzione dei domini dei clienti e degli account, a parte gli ordini o i domini di evasione. In alcuni casi, ciò potrebbe richiedere modifiche all'applicazione, ad esempio per modificare le code di messaggi di posta elettronica o processi in background in modo che siano autonome e non basarsi sui join a un cliente o a una tabella degli ordini. Lo spostamento di tabelle e dati esistenti in un nuovo database primario può essere eseguito con Database di Azure per MySQL repliche in lettura server flessibile e promuovendo la replica e puntando parti dell'applicazione al database scrivibile appena creato. Il database appena creato deve limitare l'accesso con pool di connessioni, ottimizzare le query e distribuire il carico con le proprie repliche esattamente come la replica primaria originale.
Configurazioni di importazione dei dati
- È possibile ridimensionare temporaneamente l'istanza a dimensioni più elevate prima di avviare un'operazione di importazione dei dati e quindi ridurre le prestazioni quando l'importazione ha esito positivo.
- È possibile importare i dati con tempi di inattività minimi usando Eseguire la migrazione locale di MySQL a Database di Azure per MySQL per migrazioni online o offline.
raccomandazioni sulla memoria del server flessibile Database di Azure per MySQL
Una Database di Azure per MySQL procedura consigliata per le prestazioni del server flessibile consiste nell'allocare ram sufficiente in modo che il working set risieda quasi completamente in memoria.
- Controllare se la percentuale di memoria usata per raggiungere i limiti usando le metriche per Database di Azure per MySQL server flessibile.
- Configurare avvisi su tali numeri per assicurarsi che, man mano che il server raggiunge i limiti, è possibile eseguire azioni di richiesta per correggerlo. In base ai limiti definiti, verificare se aumentare le prestazioni dello SKU del database, fino a dimensioni di calcolo superiori o a un piano tariffario migliore, con un notevole aumento delle prestazioni.
- Aumentare le prestazioni fino a quando i numeri di prestazioni non si abbassano più drasticamente dopo un'operazione di ridimensionamento. Per informazioni sul monitoraggio delle metriche di un'istanza del database, vedere metriche del database del server flessibile Database di Azure per MySQL.
Usare il warmup del pool di buffer InnoDB
Dopo il riavvio dell'istanza del server flessibile Database di Azure per MySQL, le pagine di dati che risiedono nell'archiviazione vengono caricate quando vengono eseguite query sulle tabelle, con conseguente aumento della latenza e prestazioni più lente per la prima esecuzione delle query. Questo potrebbe non essere accettabile per i carichi di lavoro sensibili alla latenza.
L'utilizzo del pool di buffer InnoDB riduce il periodo di riscaldamento ricaricando le pagine del disco presenti nel pool di buffer prima del riavvio anziché attendere che le operazioni DML o SELECT accedano alle righe corrispondenti.
È possibile ridurre il periodo di riscaldamento dopo il riavvio dell'istanza del server flessibile Database di Azure per MySQL, che rappresenta un vantaggio per le prestazioni configurando i parametri del server del pool di buffer InnoDB. InnoDB salva una percentuale delle pagine usate più di recente per ogni pool di buffer all'arresto del server e ripristina queste pagine all'avvio del server.
È anche importante notare che le prestazioni migliorate sono a scapito del tempo di avvio più lungo per il server. Quando questo parametro è abilitato, è previsto un aumento del tempo di avvio e riavvio del server a seconda delle operazioni di I/O al secondo di cui è stato effettuato il provisioning nel server.
È consigliabile testare e monitorare l'ora di riavvio per assicurarsi che le prestazioni di avvio/riavvio siano accettabili perché il server non è disponibile durante tale periodo. Non è consigliabile usare questo parametro con meno di 1000 operazioni di I/O al secondo con provisioning (o in altre parole, quando è stato effettuato il provisioning dell'archiviazione è inferiore a 335 GB).
Per salvare lo stato del pool di buffer all'arresto del server, impostare il parametro innodb_buffer_pool_dump_at_shutdown del server su ON. Analogamente, impostare il parametro innodb_buffer_pool_load_at_startup del server su ON per ripristinare lo stato del pool di buffer all'avvio del server. È possibile controllare l'effetto sul tempo di avvio/riavvio riducendo e ottimizzando il valore del parametro innodb_buffer_pool_dump_pctdel server. Per impostazione predefinita, il parametro è impostato su 25.
Nota
I parametri di riscaldamento del pool di buffer innoDB sono supportati solo nei server di archiviazione per utilizzo generico con un massimo di 16 TB di archiviazione. Per altre informazioni, vedere Database di Azure per MySQL opzioni di archiviazione del server flessibile.