Condividi tramite

Migrazione automatica sul posto dal Database di Azure per MySQL - Server singolo a server flessibile

  • Articolo

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

La migrazione automatica sul posto da Database di Azure per MySQL - Server singolo a server flessibile è una migrazione sul posto avviata dal servizio durante la finestra di manutenzione pianificata per carichi di lavoro di database a server singolo con SKU Basic, Utilizzo generico o Ottimizzato per la memoria, archiviazione dei dati usata <= 100 GiB e nessuna funzionalità complessa (CMK, Microsoft Entra ID, Read Replica, Rete virtuale, crittografia a doppia infrastruttura, endpoint servizio/regole di rete virtuale) abilitata. I server idonei vengono identificati dal servizio e ricevono una notifica anticipata che contiene i passaggi per esaminare i dettagli della migrazione.

La migrazione sul posto offre un'esperienza di migrazione offline altamente resiliente e auto-guarigione durante una finestra di manutenzione pianificata, con meno di 5 minuti di tempo di inattività. Usa la tecnologia di backup e ripristino per tempi di migrazione più rapidi. Questa migrazione elimina il sovraccarico per eseguire manualmente la migrazione del server e assicurarsi di sfruttare i vantaggi del server flessibile, tra cui prezzi e prestazioni migliori, controllo granulare sulla configurazione del database e finestre di manutenzione personalizzate. Di seguito sono descritte le fasi principali della migrazione:

  • Il server flessibile di destinazione viene distribuito, ereditando tutti i set di funzionalità e le proprietà (inclusi i parametri del server e le regole del firewall) dal server singolo di origine. Il server singolo di origine è impostato su sola lettura e il backup dal server singolo di origine viene copiato nel server flessibile di destinazione.
  • Il cambio e il cutover DNS vengono eseguiti correttamente all'interno della finestra di manutenzione pianificata con tempi di inattività minimi, consentendo la manutenzione dello stesso stringa di connessione dopo la migrazione. Le applicazioni client si connettono facilmente al server flessibile di destinazione senza aggiornamenti manuali basati sull'utente. Oltre ai formati di stringa di connessione (server singolo e flessibile) supportati nel server flessibile migrato, entrambi i formati di nome utente, username@server_name e nome utente sono supportati anche nel server flessibile migrato.
  • Il server flessibile migrato è online e può ora essere gestito tramite portale di Azure/interfaccia della riga di comando. Il server singolo arrestato viene eliminato sette giorni dopo la migrazione.

Nota

Se l'istanza del server singolo dispone di archiviazione per utilizzo generico V1, l'istanza pianificata subirà un'operazione di riavvio aggiuntiva 12 ore prima dell'ora di migrazione pianificata. Questa operazione di riavvio consente di abilitare il parametro del server log_bin necessario per aggiornare l'istanza all'archiviazione per utilizzo generico V2 prima di eseguire la migrazione automatica sul posto.

Idoneità

Se si è proprietari di un carico di lavoro a server singolo con archiviazione dati usata <= 100 GiB e non sono abilitate funzionalità complesse (CMK, Microsoft Entra ID, Replica in lettura, Rete virtuale, doppia crittografia infra, endpoint servizio/regole della rete virtuale) è ora possibile candidarsi (se non è già pianificato dal servizio) per l'invio automatico dei dettagli del server tramite questo modulo.

Configurare gli avvisi di migrazione

I server idonei per la migrazione automatica sul posto vengono inviati una notifica anticipata dal servizio.

Di seguito sono descritti i modi per controllare e configurare le notifiche di migrazione automatica:

  • I proprietari delle sottoscrizioni per i server singoli pianificati per l'invio automatico ricevono una notifica tramite posta elettronica.
  • Configurare gli avvisi di integrità dei servizi per ricevere notifiche di stato e pianificazione della migrazione sul posto tramite posta elettronica/SMS seguendo questa procedura.
  • Controllare la notifica di migrazione sul posto nel portale di Azure seguendo questa procedura.

Esaminare la pianificazione della migrazione

Di seguito sono descritti i modi per esaminare la pianificazione della migrazione dopo aver ricevuto la notifica di migrazione automatica sul posto:

Nota

La pianificazione della migrazione verrà bloccata 7 giorni prima della finestra di migrazione pianificata dopo la quale non sarà possibile riprogrammare.

  • La pagina di panoramica server singolo per l'istanza visualizza un banner del portale con informazioni sulla pianificazione della migrazione.
  • Per i server singoli pianificati per la migrazione automatica, nel portale viene visualizzato un nuovo pannello Migrazione. È possibile esaminare la pianificazione della migrazione passando al pannello Migrazione dell'istanza del Server singolo.
  • Se si desidera rinviare la migrazione, è possibile rinviare di un mese alla volta passando al pannello Migrazione dell'istanza del server singolo nella portale di Azure e riprogrammando la migrazione selezionando un'altra finestra di migrazione entro un mese.
  • Se il server singolo dispone di SKU per utilizzo generico, è possibile abilitare la disponibilità elevata durante la revisione della pianificazione della migrazione. Poiché la disponibilità elevata può essere abilitata solo durante la creazione per un server flessibile MySQL, è consigliabile abilitare questa funzionalità quando si esamina la pianificazione della migrazione.
  • Se il server singolo dispone di endpoint privati, seguire questa procedura obbligatoria quando si esamina la pianificazione della migrazione almeno 7 giorni prima della migrazione pianificata:
    • Esaminare gli endpoint privati elencati per la migrazione. Assicurarsi che siano contrassegnati come Pronto per la migrazione. Se sono contrassegnati come non idonei, selezionare la sottoscrizione appropriata e la zona DNS privata.
    • Selezionare la casella di controllo di conferma dopo aver eseguito i controlli dei prerequisiti elencati per la migrazione di endpoint privati.
    • Fare clic sul pulsante Autentica per autenticare la connessione ARM necessaria per eseguire la migrazione degli endpoint privati dal server di origine al server di destinazione.

Controlli dei prerequisiti per la migrazione automatica sul posto

Esaminare i prerequisiti seguenti per garantire una corretta migrazione automatica sul posto:

  • L'istanza del server singolo deve essere in stato pronto e non deve essere arrestata durante la finestra di manutenzione pianificata per l'esecuzione della migrazione automatica.
  • Per l'istanza di Server singolo con SSL abilitato, assicurarsi di disporre di tutti e tre i certificati (BaltimoreCyberTrustRootRoot, DigiCertGlobalRootG2 Root CA e DigiCertGlobalRootCA Root CA) disponibili nell'archivio radice attendibile. Inoltre, se il certificato è stato aggiunto al stringa di connessione creare un certificato CA combinato con tutti e tre i certificati prima della migrazione automatica pianificata per garantire la continuità aziendale dopo la migrazione.
  • Il motore MySQL non garantisce alcun ordinamento se non è presente alcuna clausola 'SORT' nelle query. Dopo la migrazione automatica sul posto, è possibile osservare una modifica nell'ordinamento. Se il mantenimento dell'ordinamento è fondamentale, assicurarsi che le query vengano aggiornate in modo da includere la clausola 'SORT' prima della migrazione automatica sul posto pianificata.
  • Se l'origine Database di Azure per MySQL server singolo dispone della versione del motore v8.x, assicurarsi di aggiornare la versione del driver client .NET del server di origine alla versione 8.0.32 per evitare eventuali incompatibilità di codifica dopo la migrazione al server flessibile.
  • Se l'origine Database di Azure per MySQL server singolo dispone della versione del motore v8.x, assicurarsi di aggiornare la versione TLS del server di origine dalla versione 1.0 o v1.1 a TLS v1.2 prima della migrazione perché le versioni precedenti di TLS sono state deprecate per il server flessibile.
  • Se l'origine Database di Azure per MySQL server singolo ha nomi di regole del firewall superiori a 80 caratteri, rinominarli per garantire che la lunghezza del nome sia inferiore a 80 caratteri. La lunghezza del nome della regola del firewall supportata nel server flessibile è di 80 caratteri, mentre nel server singolo la lunghezza consentita è di 12 8 caratteri.
  • Se l'origine Database di Azure per MySQL server singolo usa porte non predefinite, ad esempio 3308.3309 e 3310, modificare la porta di connettività su 3306 come le porte non predefinite indicate in precedenza non sono supportate nel server flessibile.

Come viene eseguito il provisioning automatico del server flessibile MySQL di destinazione?

Il provisioning del livello di calcolo e dello SKU per il server flessibile di destinazione viene eseguito in base al piano tariffario del server singolo di origine e ai VCore in base ai dettagli nella tabella seguente.

Piano tariffario Server singolo vCore Server singolo Livello server flessibile Nome SKU server flessibile
Di base 1 Con possibilità di burst Standard_B1s
Di base 2 Con possibilità di burst Standard_B2s
Utilizzo generico 4 Utilizzo generico Standard_D4ds_v4
Utilizzo generico 8 Utilizzo generico Standard_D8ds_v4
Utilizzo generico 16 Utilizzo generico Standard_D16ds_v4
Utilizzo generico 32 Utilizzo generico Standard_D32ds_v4
Utilizzo generico 64 Utilizzo generico Standard_D64ds_v4
Con ottimizzazione per la memoria 4 MemoryOptimized Standard_E4ds_v4
Con ottimizzazione per la memoria 8 MemoryOptimized Standard_E8ds_v4
Con ottimizzazione per la memoria 16 MemoryOptimized Standard_E16ds_v4
Con ottimizzazione per la memoria 32 MemoryOptimized Standard_E32ds_v4
  • La versione mySQL, l'area, le dimensioni di archiviazione, la sottoscrizione e il gruppo di risorse per il server flessibile di destinazione è uguale a quello del server singolo di origine.
  • Per i server singoli con spazio di archiviazione inferiore a 20 GiB, le dimensioni di archiviazione sono impostate su 20 GiB in quanto è il limite di archiviazione minimo per Database di Azure per MySQL - Server flessibile.
  • Entrambi i formati di nome utente: username@server_name (server singolo) e nome utente (server flessibile) sono supportati nel server flessibile migrato.
  • Entrambi i formati stringa di connessione: server singolo e server flessibile sono supportati nel server flessibile migrato.
  • Per l'istanza di Server singolo con Query Store abilitato, il parametro del server 'slow_query_log' nell'istanza di destinazione è impostato su ON per garantire la parità delle funzionalità durante la migrazione al server flessibile. Per determinati carichi di lavoro questo potrebbe influire sulle prestazioni e, se si osserva una riduzione delle prestazioni, impostare questo parametro del server su 'OFF' nell'istanza del server flessibile.

Passaggi post-migrazione

Ecco le informazioni necessarie per la migrazione sul posto:

Nota

Dopo la migrazione non riavviare l'istanza server singolo arrestata perché potrebbe ostacolare la connettività del client e dell'applicazione.

  • Copiare le proprietà seguenti dal server singolo di origine nel server flessibile di destinazione dopo il completamento dell'operazione di migrazione sul posto:
    • Impostazioni della pagina monitoraggio (avvisi, metriche e impostazioni di diagnostica)
    • Tutti gli script Terraform/CLI ospitati per gestire l'istanza di Server singolo devono essere aggiornati con riferimenti al server flessibile.
  • Per l'istanza di Server singolo con Query Store abilitato, il parametro del server 'slow_query_log' nell'istanza di destinazione è impostato su ON per garantire la parità delle funzionalità durante la migrazione al server flessibile. Si noti che per determinati carichi di lavoro questo potrebbe influire sulle prestazioni e, se si osserva una riduzione delle prestazioni, impostare questo parametro del server su "OFF" nell'istanza del server flessibile.
  • Per l'istanza di Server singolo con Microsoft Defender per il cloud abilitata, viene eseguita la migrazione dello stato di abilitazione. Per ottenere parità nel server flessibile dopo la migrazione automatica per le proprietà che è possibile configurare in Server singolo, prendere in considerazione i dettagli nella tabella seguente:
Proprietà Impostazione
properties.disabledAlerts È possibile disabilitare tipi di avviso specifici usando la piattaforma Microsoft Defender per il cloud. Per altre informazioni, vedere l'articolo Eliminare gli avvisi da Microsoft Defender per il cloud guida.
properties.emailAccountAdmins, properties.emailAddresses È possibile definire centralmente la notifica tramite posta elettronica per gli avvisi di Microsoft Defender per il cloud per tutte le risorse in una sottoscrizione. Per altre informazioni, vedere l'articolo Configurare le notifiche tramite posta elettronica per gli avvisi di sicurezza.
properties.retentionDays, properties.storageAccountAccessKey, properties.storageEndpoint La piattaforma Microsoft Defender per il cloud espone gli avvisi tramite Azure Resource Graph. È possibile esportare gli avvisi in un archivio diverso e gestire separatamente la conservazione. Per altre informazioni sull'esportazione continua, vedere l'articolo Configurare l'esportazione continua nel portale di Azure - Microsoft Defender per il cloud.

Domande frequenti (FAQ)

D. Perché viene eseguita la migrazione automatica?

R. L’istanza di Database di Azure per MySQL - Server singolo è idonea per la migrazione sul posto all’offerta principale Database di Azure per MySQL - Server flessibile. La migrazione sul posto rimuoverà l'onere di dover eseguire la migrazione manualmente del server, consentendo di usufruire dei vantaggi offerti da Server flessibile, tra cui miglior prezzo & prestazioni, controllo dettagliato sulla configurazione del database e finestre di manutenzione personalizzate.

D. Come avviene la migrazione automatica? Che cosa ne viene eseguita la migrazione?

R. Viene effettuato il provisioning di Server flessibile in modo che corrisponda agli stessi VCore e alle stesse risorse di archiviazione di Server singolo. Successivamente, il Server singolo di origine viene arrestato, lo snapshot del file di dati viene creato e copiato nel Server flessibile di destinazione. Viene effettuato uno switch DNS per instradare tutte le connessioni esistenti verso la destinazione, e il Server flessibile viene portato online. La migrazione automatica esegue la migrazione dei file di dati dell'intero server (inclusi schema, dati, account di accesso) oltre ai parametri del server (tutti i parametri del server modificati nell'origine vengono copiati nella destinazione, i parametri server non modificati accettano il valore predefinito definito dal server flessibile) e le regole del firewall. Si tratta di una migrazione offline in cui vengono visualizzati tempi di inattività fino a 5 minuti o meno.

D. Come è possibile configurare o visualizzare gli avvisi di migrazione sul posto?

R. Di seguito sono riportati i modi in cui è possibile configurare gli avvisi:

  • Configurare gli avvisi di integrità dei servizi per ricevere notifiche di stato e pianificazione della migrazione sul posto tramite posta elettronica/SMS seguendo questa procedura.
  • Controllare la notifica di migrazione sul posto nel portale di Azure seguendo questa procedura.

D. Come è possibile rinviare la migrazione pianificata?

R. È possibile esaminare la pianificazione della migrazione passando al pannello Migrazione dell'istanza del Server singolo. Se si vuole rinviare la migrazione, è possibile rinviare al massimo un mese passando al pannello Migrazione dell'istanza del server singolo nella portale di Azure e riprogrammando la migrazione selezionando un'altra finestra di migrazione entro un mese. I dettagli della migrazione verranno bloccati sette giorni prima della finestra di migrazione pianificata dopo la quale non è possibile riprogrammare. Questa migrazione sul posto può essere posticipata mensilmente fino al 16 settembre 2024.

D. Quale nome utente e stringa di connessione sono supportate per il Server flessibile migrato? ​​

R. Entrambi i formati di nome utente: username@server_name (formato server singolo) e nome utente (formato server flessibile) sono supportati per il server flessibile migrato e pertanto non è necessario aggiornarli per mantenere la continuità dell'applicazione dopo la migrazione. Inoltre, entrambi i formati di stringa di connessione (formato server singolo e flessibile) sono supportati anche per il server flessibile migrato.

D. Come abilitare la disponibilità elevata (disponibilità elevata) per il server di cui è stata eseguita la migrazione automatica?

R. Per impostazione predefinita, la migrazione automatica configura la migrazione a un'istanza non a disponibilità elevata. Poiché la disponibilità elevata può essere abilitata solo in fase di creazione del server, è necessario abilitarla prima della migrazione automatica pianificata usando l'opzione di modifica della pianificazione della migrazione automatica nel portale. La disponibilità elevata può essere abilitata solo per GLI SKU per utilizzo generico\Ottimizzato per la memoria nel server flessibile di destinazione, perché la migrazione dello SKU di base a burst non supporta la configurazione a disponibilità elevata.

D. Viene visualizzata una differenza di prezzo per il passaggio potenziale dal server singolo MySQL Basic al server flessibile MySQL??

R. Alcuni server potrebbero visualizzare un piccolo aumento del prezzo dopo la migrazione (i costi stimati possono essere visualizzati selezionando l'opzione di modifica della pianificazione della pianificazione automatica nel portale), poiché il limite di archiviazione minimo per entrambe le offerte è diverso (5 GiB su server singolo; 20 GiB su server flessibile) e il costo di archiviazione (0,11$ su server singolo; 0,115$ su server flessibile) per il server flessibile è leggermente superiore al server singolo. Per i server interessati, questo aumento dei prezzi nel server flessibile offre una velocità effettiva e prestazioni migliori rispetto al server singolo.

Contenuto correlato