Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La definizione di baseline delle prestazioni è fondamentale per la migrazione di database MySQL da ambienti locali a Database di Azure per MySQL. Questo articolo illustra l'importanza delle baseline delle prestazioni, fornendo una guida dettagliata sulla misurazione e l'analisi delle prestazioni correnti del database. Comprendendo le metriche delle prestazioni esistenti, è possibile impostare aspettative realistiche e identificare le aree per il miglioramento durante il processo di migrazione. Questa guida fornisce le conoscenze per creare baseline di prestazioni accurate, assicurandosi che i database migrati soddisfino o superino i livelli di prestazioni correnti nell'ambiente Azure. Sia che si voglia ottimizzare le prestazioni delle query, migliorare la scalabilità o garantire un'esperienza utente coerente, questo articolo fornisce le informazioni dettagliate necessarie per raggiungere gli obiettivi di prestazioni.
Prerequisiti
Eseguire la migrazione di MySQL in locale a Database di Azure per MySQL: Piani di test
Panoramica
Comprendere il carico di lavoro MySQL esistente è uno degli investimenti migliori che possono essere effettuati per garantire una migrazione corretta. Prestazioni di sistema eccellenti dipendono da hardware adeguato e da un ottimo design dell'applicazione. Gli elementi come CPU, memoria, disco e rete devono essere ridimensionati e configurati in modo appropriato per il carico previsto. L'hardware e la configurazione fanno parte dell'equazione delle prestazioni del sistema. Lo sviluppatore deve comprendere il carico delle query del database e le query più costose da eseguire. Concentrarsi sulle query più costose può influire significativamente sulle metriche delle prestazioni complessive.
La creazione di baseline delle prestazioni delle query è fondamentale per un progetto di migrazione. Le linee di base delle prestazioni possono essere usate per verificare la configurazione della zona di destinazione di Azure per i carichi di lavoro di dati migrati. La maggior parte dei sistemi viene eseguita 24/7 e presenta tempi di carico di picco diversi. È importante acquisire i carichi di lavoro di picco per la baseline. Le metriche vengono acquisite più volte. Più avanti nel documento vengono esaminati i parametri del server di origine e come sono essenziali per l'immagine generale della baseline delle prestazioni. I parametri del server non devono essere trascurati durante un progetto di migrazione.
Strumenti
Di seguito sono riportati gli strumenti usati per raccogliere le metriche del server e le informazioni sul carico di lavoro del database. Usare le metriche acquisite per determinare il database di Azure appropriato per il livello MySQL e le opzioni di ridimensionamento associate.
Telemetria di MySQL Enterprise: questo strumento enterprise edition non gratuito può fornire un elenco ordinato delle query più costose, delle metriche del server, delle operazioni di I/O dei file e delle informazioni sulla topologia
Percona Monitoring and Management (PMM): una soluzione di monitoraggio dei database open source di qualità migliore. Consente di ridurre la complessità, ottimizzare le prestazioni e migliorare la sicurezza degli ambienti di database business critical, indipendentemente dalla posizione distribuita.
Parametri del server
Le configurazioni predefinite del server MySQL potrebbero non supportare adeguatamente un carico di lavoro. C'è una pletora di parametri del server in MySQL, ma nella maggior parte dei casi, il team di migrazione deve concentrarsi su una manciata. I parametri seguenti devono essere valutati negli ambienti di origine e di destinazione . Le configurazioni non corrette possono influire sulla velocità della migrazione. Questi parametri vengono rivisitati quando si eseguono i passaggi di migrazione.
innodb_buffer_pool_size: un valore elevato garantisce che le risorse in memoria vengano usate prima di usare l'I/O del disco. I valori tipici sono compresi tra l'80% e il 90% della memoria disponibile. Ad esempio, un sistema con 8 GB di memoria deve allocare 5-6 GB per le dimensioni del pool.
innodb_log_file_size: i log di rollforward garantiscono scritture veloci e durevoli. Questo backup transazionale è utile durante un arresto anomalo del sistema. A partire da innodb_log_file_size = 512M (dando 1 GB di log di rollforward) dovrebbe dare un sacco di spazio per le scritture. Le applicazioni a elevato utilizzo di scrittura che usano MySQL 5.6 o versione successiva devono iniziare con innodb_log_file_size = 4G.
max_connections: questo parametro può contribuire ad alleviare l'errore
Too many connections. Il valore predefinito è 151 connessioni. È preferibile usare un pool di connessioni a livello di applicazione, ma potrebbe essere necessario aumentare anche la configurazione della connessione server.innodb_file_per_table: questa impostazione indica a InnoDB se deve archiviare dati e indici nello spazio di tabella condiviso o in un file separato.ibd per ogni tabella. La presenza di un file per tabella consente al server di recuperare spazio quando le tabelle vengono eliminate, troncate o ricompilate. I database contenenti molte tabelle non devono usare la tabella per ogni configurazione di file. A partire da MySQL 5.6, il valore predefinito è ON. Le versioni precedenti del database devono impostare la configurazione su ON prima del caricamento dei dati. Questa impostazione influisce solo sulle tabelle appena create.
innodb_flush_log_at_trx_commit: l'impostazione predefinita di un valore indica che InnoDB è completamente conforme a ACID. Questa configurazione delle transazioni a basso rischio può comportare un sovraccarico significativo nei sistemi con dischi lenti a causa delle sincronizzazioni aggiuntive necessarie per scaricare ogni modifica nei log di rollforward. L'impostazione del parametro su 2 è un po' meno affidabile perché le transazioni di cui è stato eseguito il commit verranno scaricate nei log di rollforward solo una volta al secondo. Il rischio può essere accettabile in alcune situazioni master ed è un buon valore per una replica. Il valore 0 consente prestazioni migliori del sistema, ma il server di database è più simile a perdere alcuni dati durante un errore. La riga inferiore consiste nell'usare il valore 0 solo per una replica.
innodb_flush_method: questa impostazione controlla la modalità di scaricamento dei dati e dei log su disco. Usare
O_DIRECTquando in presenza di un controller RAID hardware con una cache writeback protetta da batteria. Usarefdatasync(valore predefinito) per altri scenari.innodb_log_buffer_size: questa impostazione è la dimensione del buffer per le transazioni che devono ancora essere sottoposte a commit. Il valore predefinito (1 MB) è accettabile. Le transazioni con campi BLOB/testo di grandi dimensioni possono riempire rapidamente il buffer e attivare un carico di I/O aggiuntivo. Esaminare la
Innodb_log_waitsvariabile di stato e, se non è 0, aumentareinnodb_log_buffer_size.query_cache_size: la cache delle query è un collo di bottiglia noto che può essere visualizzato durante la concorrenza moderata. Il valore iniziale deve essere impostato su 0 per disabilitare la cache, ad esempio query_cache_size = 0. Si tratta dell'impostazione predefinita in MySQL 5.6 e versioni successive.
log_bin: questa impostazione abilita la registrazione binaria. L'abilitazione della registrazione binaria è obbligatoria se il server deve fungere da master di replica.
server_id: questa impostazione è univoca per i server identity nelle topologie di replica.
expire_logs_days: questa impostazione controlla il numero di giorni in cui i log binari verranno eliminati automaticamente.
skip_name_resolve: utente per eseguire la risoluzione del nome host client. Se il DNS è lento, la connessione è lenta. Quando si disabilita la risoluzione dei nomi, le istruzioni GRANT devono usare solo indirizzi IP. Per usare l'INDIRIZZO IP, è necessario ripetere le istruzioni GRANT precedenti.
Eseguire il comando seguente per esportare i parametri del server in un file da rivedere. Usando un'analisi semplice, l'output può riapplicare gli stessi parametri del server dopo la migrazione, se appropriato, al server Database di Azure per MySQL. Riferimento Configurare i parametri del server in Database di Azure per MySQL usando il portale di Azure.
mysql -u root -p -A -e "SHOW GLOBAL VARIABLES;" > settings.txt
I parametri predefiniti del server installati per MySQL 5.5.60 sono disponibili nell'appendice.
Prima dell'inizio della migrazione, esportare le impostazioni di configurazione mySQL di origine. Confrontare questi valori con le impostazioni dell'istanza della zona di destinazione di Azure dopo la migrazione. Se sono state modificate impostazioni rispetto all'impostazione predefinita nell'istanza della zona di destinazione di Azure, assicurarsi che siano impostate di nuovo dopo la migrazione. Inoltre, l'utente di migrazione deve verificare che i parametri del server possano essere impostati prima della migrazione.
Per un elenco di parametri del server che non possono essere configurati, fare riferimento ai parametri del server non configurabili.
Dati in ingresso e in uscita
I parametri del server MySQL di origine e destinazione devono essere modificati per ogni rispettivo strumento di migrazione dei dati e percorso per supportare il più veloce possibile in uscita e in ingresso. A seconda dello strumento, i parametri potrebbero essere diversi. Ad esempio, uno strumento che esegue una migrazione in parallelo potrebbe richiedere più connessioni tra l'origine e la destinazione rispetto a uno strumento a thread singolo.
Esaminare tutti i parametri di timeout che potrebbero essere interessati dai set di dati. tra cui:
Esaminare anche tutti i parametri che influiscono sui valori massimi:
Nota
Un errore di migrazione comune è MySQL server has gone away. I parametri indicati di seguito sono i tipici responsabili della risoluzione di questo errore.
Scenario WWI
WWI ha esaminato il carico di lavoro del database conference e ha determinato che aveva un carico ridotto. Anche se un server di livello basic funzionava per loro, non volevano eseguire il lavoro in un secondo momento per eseguire la migrazione a un altro livello. Il server distribuito ospiterà infine gli altri carichi di lavoro di dati MySQL, in modo che abbiano scelto il General Performance livello.
Quando si esamina il database MySQL, è stato rilevato che il server MySQL 5.5 viene eseguito con i parametri del server predefiniti impostati durante l'installazione iniziale.