Condividi tramite

Procedure consigliate per le operazioni sul server di Database di Azure per MySQL - Server flessibile

  • Articolo

Informazioni sulle procedure consigliate per lavorare con il server flessibile di Database di Azure per MySQL. Man mano che vengono aggiunte nuove funzionalità alla piattaforma, ci concentriamo sulla ridefinizione delle procedure consigliate descritte in questa sezione.

Linee guida operative sul server flessibile di Database di Azure per MySQL

Di seguito sono riportate le linee guida operative da seguire quando si lavora con il server flessibile di Database di Azure per MySQL per migliorare le prestazioni del database:

  • Coubicazione: per ridurre la latenza di rete, posizionare il client e il server di database nella stessa area di Azure.

  • Monitorare l'utilizzo della memoria, della CPU e dell'archiviazione: è possibile configurare avvisi per essere avvisati quando i modelli di utilizzo cambiano o quando ci si avvicina alla massima capacità della distribuzione, in modo da poter mantenere le prestazioni e la disponibilità del sistema.

  • Log accelerati per prestazioni migliorate: l'abilitazione della funzionalità dei log accelerati ottimizza le operazioni correlate ai log transazionali, aumentando la velocità effettiva e le prestazioni del server. Questa funzionalità, disponibile senza costi aggiuntivi, è un'aggiunta significativa alle procedure consigliate operative per gli utenti del livello di servizio Business Critical.

  • Aumentare le prestazioni dell'istanza di database: è possibile aumentare le prestazioni quando ci si avvicina ai limiti della capacità di archiviazione. È necessario disporre di un buffer nell'archiviazione e nella memoria per supportare aumenti imprevisti della domanda dalle applicazioni. È anche possibile abilitare la funzionalità di aumento automatico dell'archiviazione impostandola su "ON" solo per assicurarsi che il servizio ridimensioni automaticamente lo spazio di archiviazione quando si avvicina ai limiti di archiviazione.

  • Configurare i backup: abilitare i backup locali o con ridondanza geografica in base ai requisiti dell'azienda. Si modifica anche il periodo di conservazione relativo al tempo di disponibilità dei backup per la continuità aziendale.

  • Ottimizzare la capacità di I/O con operazioni di I/O al secondo con scalabilità automatica: se il carico di lavoro del database richiede più operazioni di I/O rispetto al provisioning, il ripristino o altre operazioni transazionali per il database saranno lenti. Per aumentare la capacità di input/output di un'istanza del server, eseguire una delle operazioni seguenti:

    • Usare operazioni di I/O al secondo con scalabilità automatica: le operazioni di I/O al secondo con scalabilità automatica eliminano la necessità di effettuare il pre-provisioning di un numero specifico di operazioni di I/O al secondo. Il server potrà invece modificare automaticamente le operazioni IOPS in base ai requisiti del carico di lavoro 1. Ciò significa che il server può aumentare o ridurre automaticamente le operazioni di I/O al secondo in base alle esigenze del carico di lavoro.

    • Il server flessibile di Database di Azure per MySQL offre il ridimensionamento delle operazioni di I/O al secondo alla velocità di tre operazioni di I/O al secondo per GB di archiviazione di cui è stato effettuato il provisioning. Aumentare l'archiviazione di cui è stato effettuato il provisioning per ridimensionare le operazioni di I/O al secondo e ottenere prestazioni migliori.

    • Se si usa già l'archiviazione con provisioning delle operazioni di I/O al secondo, effettuare il provisioning della capacità effettiva aggiuntiva.

  • Calcolo della scalabilità: il carico di lavoro del database può anche essere limitato a causa della CPU o della memoria e questo può avere un impatto grave sull'elaborazione delle transazioni. Il calcolo (piano tariffario) può essere ridimensionato verso l'alto o verso il basso tra i livelli per utilizzo generico o ottimizzato per la memoria.

  • Test per il failover: testare manualmente il failover per l'istanza del server per comprendere il tempo necessario al processo per il caso d'uso e per assicurarsi che l'applicazione che accede all'istanza del server possa connettersi automaticamente alla nuova istanza del server dopo il failover.

  • Usare la chiave primaria: assicurarsi che le tabelle abbiano una chiave primaria o univoca quando si opera nell'istanza del server flessibile di Database di Azure per MySQL. Ciò consente di eseguire backup, repliche e così via, migliorando le prestazioni.

  • Configurare il valore TTL: se l'applicazione client memorizza nella cache i dati DNS (Domain Name Service) delle istanze del server, impostare un valore TTL (Time-to-Live) inferiore a 30 secondi. Poiché l'indirizzo IP sottostante di un'istanza del server può cambiare dopo un failover, la memorizzazione nella cache dei dati DNS per un periodo di tempo prolungato può causare errori di connessione se l'applicazione tenta di connettersi a un indirizzo IP che non è più in servizio.

  • Utilizzare un pool di connessioni per evitare di raggiungere ilimiti massimi di connessionee usare la logica di ripetizione dei tentativi per evitare problemi di connessione intermittenti.

  • Se si usa la replica, usare ProxySQL per bilanciare il carico tra il server primario e il server di replica secondaria leggibile. Vedere i passaggi di configurazione qui.

  • Quando si effettua il provisioning della risorsa, assicurarsi di aver abilitato l'aumento automatico per l'istanza del Server flessibile di Database di Azure per MySQL. Questo non aggiunge alcun costo aggiuntivo e protegge il database da eventuali colli di bottiglia di archiviazione che potrebbero verificarsi.

Usare InnoDB con Database di Azure per MySQL server flessibile

  • Se si usa la funzionalità ibdata1, ovvero un file di dati dello spazio tabelle di sistema non può essere compattato o eliminato rimuovendo i dati dalla tabella o spostando la tabella in file per tabella tablespaces.

  • Per i database di dimensioni maggiori di 1 TB, è necessario creare la tabella in innodb_file_per_tabletablespace. Per una singola tabella di dimensioni superiori a 1 TB, usare la tabella di partizione.

  • Per un server con un numero elevato di tablespace, l'avvio del motore è molto lento a causa dell'analisi sequenziale dello spazio di tabella durante l'avvio o il failover del server flessibile di Database di Azure per MySQL.

  • Impostare innodb_file_per_table = ON prima di creare una tabella, se il numero di tabella totale è minore di 500.

  • Se sono presenti più di 500 tabelle in un database, esaminare le dimensioni della tabella per ogni singola tabella. Per una tabella di grandi dimensioni, è comunque consigliabile usare lo spazio di tabella file per tabella per evitare che il file dello spazio di tabella di sistema raggiunga il limite massimo di archiviazione.

Nota

Per le tabelle di dimensioni inferiori a 5 GB, è consigliabile usare lo spazio tabelle di sistema

CREATE TABLE tbl_name ... *TABLESPACE* = *innodb_system*;

  • Partizionare la tabella in fase di creazione se si dispone di una tabella di grandi dimensioni potenzialmente superiore a 1 TB.

  • Usare più istanze del server flessibile di Database di Azure per MySQL e distribuire le tabelle tra tali server. Evitare di inserire troppe tabelle in un singolo server se sono presenti circa 10.000 tabelle o più.

Contenuto correlato