Eseguire la migrazione di MySQL in locale a Database di Azure per MySQL: Ottimizzazione
SI APPLICA A:
Database di Azure per MySQL - Server singolo Database di Azure per MySQL - Server flessibile
Prerequisiti
Monitorare le prestazioni dell'hardware e delle query
Oltre ai log di controllo e attività, le prestazioni del server possono essere monitorate anche con le metriche di Azure. Le metriche di Azure vengono fornite in una frequenza di un minuto e gli avvisi possono essere configurati da essi. Per altre informazioni, vedere Monitoraggio in Database di Azure per MySQL per informazioni specifiche sul tipo di metriche che è possibile monitorare.
Come accennato in precedenza, il monitoraggio delle metriche, ad esempio cpu_percent o memory_percent, può essere importante quando si decide di aggiornare il livello di database. Valori costantemente elevati possono indicare che è necessario un aggiornamento del livello.
Inoltre, se la CPU e la memoria non sembrano essere il problema, gli amministratori possono esplorare le opzioni basate su database, ad esempio l'indicizzazione e le modifiche alle query per query con prestazioni scarse.
Per trovare query con prestazioni scarse, eseguire le operazioni seguenti:
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.DBFORMYSQL"
| where Category == 'MySqlSlowLogs'
| project TimeGenerated, LogicalServerName\_s,
event\_class\_s, start\_time\_t , q uery\_time\_d,
sql\_text\_s| top 5 by query\_time\_d desc
Informazioni dettagliate prestazioni query
Oltre agli aspetti di monitoraggio dei server di base, Azure offre strumenti per monitorare le prestazioni delle query dell'applicazione. La correzione o il miglioramento delle query possono comportare un aumento significativo della velocità effettiva delle query. Usare lo strumento Informazioni dettagliate prestazioni query per analizzare le query con esecuzione più lunga e determinare se è possibile memorizzare nella cache tali elementi se sono deterministici entro un periodo di tempo impostato o modificare le query per aumentarne le prestazioni.
slow\_query\_log Può essere impostato in modo da visualizzare query lente nei file di log di MySQL (il valore predefinito è OFF). Il long\_query\_time parametro del server può avvisare gli utenti per tempi di query lunghi (il valore predefinito è 10 sec).
Aggiornare il livello
Il portale di Azure può essere usato per passare da General Purpose e Memory Optimized. Se si sceglie un Basic livello, non è possibile aggiornare il livello a General Purpose o Memory Optimized versione successiva. Tuttavia, è possibile usare altre tecniche per eseguire una migrazione/aggiornamento a una nuova istanza di Database di Azure per MySQL.
Per un esempio di script che esegue la migrazione da base a un altro livello server, fare riferimento a Upgrade from Basic to General Purpose or Memory Optimized tiers in Database di Azure per MySQL.For an example of a script that migrates from basic to another server tier, reference Upgrade from Basic to General Purpose or Memory Optimized tiers in Database di Azure per MySQL.
Ridimensionare il server
All'interno del livello è possibile ridimensionare i core e la memoria fino ai limiti minimi e massimi consentiti in tale livello. Se il monitoraggio mostra un numero massimo continuo di CPU o memoria, seguire la procedura per aumentare le prestazioni per soddisfare la domanda.
Spostare aree
Lo spostamento di un database in un'area di Azure diversa dipende dall'approccio e dall'architettura. A seconda dell'approccio, potrebbe causare tempi di inattività del sistema.
Il processo consigliato equivale all'utilizzo di repliche in lettura per il failover di manutenzione. Tuttavia, rispetto al metodo di manutenzione pianificata indicato in precedenza, la velocità di failover è molto più veloce quando un livello di failover è stato implementato nell'applicazione. L'applicazione deve essere inattiva solo per alcuni istanti durante il processo di failover della replica di lettura. Altri dettagli sono illustrati nella sezione Continuità aziendale e ripristino di emergenza.
Scenario WWI
Gli utenti di applicazioni e business WWI hanno espresso un elevato livello di entusiasmo per quanto riguarda la capacità di ridimensionare il database su richiesta. Erano interessati anche all'uso di Informazioni dettagliate prestazioni query per determinare se le prestazioni delle query a esecuzione prolungata devono essere risolte.
Hanno scelto di usare un server di replica in lettura per qualsiasi potenziale failover o scenario di sola lettura necessario.
Il team di migrazione, che collabora con i tecnici di Azure, configura le query KQL per monitorare eventuali problemi con le prestazioni del server MySQL. Le query KQY sono state configurate con avvisi per inviare messaggi di posta elettronica ai problemi relativi agli eventi al database e al team della conferenza.
Hanno scelto di monitorare eventuali potenziali problemi per il momento e implementare Automazione di Azure eseguire libri in un secondo momento, se necessario, per migliorare l'efficienza operativa.
Elenco di controllo per l'ottimizzazione
Monitorare le query lente.
Esaminare periodicamente il dashboard Informazioni dettagliate prestazioni.
Usare il monitoraggio per gestire gli aggiornamenti del livello e le decisioni di scalabilità.
Prendere in considerazione la modifica delle aree di spostamento degli utenti o delle esigenze dell'applicazione.