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

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

La migrazione automatica sul posto dal server singolo di Database di Azure per MySQL al server flessibile è una migrazione sul posto avviata dal servizio durante la finestra di manutenzione pianificata per carichi di lavoro di database del server singolo con SKU Basic, Utilizzo generico o Ottimizzato per la memoria e senza funzionalità complesse abilitate (chiavi gestite dal cliente, Microsoft Entra ID, replica in lettura, rete virtuale, doppia crittografia dell'infrastruttura, endpoint servizio/regole di rete virtuale). 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 offline self-healing a resilienza elevata durante una finestra di manutenzione pianificata, con meno di 5 minuti di tempo di inattività per SKU di utilizzo generico e ottimizzato per la memoria e fino a 30 min per SKU Basic. Usa la tecnologia di backup e ripristino per tempi di migrazione più rapidi. La migrazione evita di dover eseguire la migrazione manuale del server e consente di usufruire dei vantaggi offerti dal server flessibile, tra cui miglior prezzo e prestazioni, controllo dettagliato 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 tutte 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.
• Cambio e cutover del DNS vengono eseguiti correttamente all'interno della finestra di manutenzione pianificata con tempi di inattività minimi, consentendo la manutenzione della stessa stringa di connessione dopo la migrazione. Le applicazioni client si connettono facilmente al server flessibile di destinazione senza aggiornamenti manuali gestiti dall'utente. Oltre a entrambi i formati di stringa di connessione (server singolo e flessibile) supportati nel server flessibile migrato, anche entrambi i formati di nome utente (nomeutente@nome_server e nomeutente) sono supportati nel server flessibile migrato.
• Il server flessibile migrato è online e ora può essere gestito tramite il portale di Azure o l'interfaccia della riga di comando di Azure. Il server singolo arrestato viene eliminato sette giorni dopo la migrazione.

Idoneità

Se si dispone di un carico di lavoro server singolo senza funzionalità complesse abilitate (chiavi gestite dal cliente, Microsoft Entra ID, replica in lettura, rete virtuale, doppia crittografia dell'infrastruttura, endpoint servizio/Regole di rete virtuale), è ora possibile nominare se stessi (se tale operazione non è già pianificata dal servizio) per la migrazione automatica inviando i dettagli del server un ticket di supporto Azure.

Per rendere il server non idoneo per la migrazione automatica, seguire questa procedura:

• Lo stato dell'istanza del server singolo deve essere impostato su Pronto e l'istanza non deve essere arrestata durante la finestra di manutenzione pianificata per l'esecuzione della migrazione automatica.
• Se l'istanza di Database di Azure per MySQL - Server singolo di origine 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'istanza di Database di Azure per MySQL - Server singolo di origine 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 il server dispone di repliche in lettura, eliminare Repliche di lettura. È possibile configurare repliche di lettura dopo la migrazione automatica.
• Se nel server sono abilitati Endpoint servizio (regole di rete virtuale) o Configurazione della rete virtuale, è consigliabile eliminarli o passare alla funzionalità di collegamento privato nell'istanza del server singolo.
• Se nel server è abilitata la Doppia crittografia dell'infrastruttura, è consigliabile passare alla funzionalità Chiave gestita dal cliente nell'istanza del server singolo.

Configurare gli avvisi di migrazione

I server idonei per la migrazione automatica sul posto ricevono 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 la migrazione automatica ricevono una notifica tramite posta elettronica.
• Configurare gli avvisi di integrità dei servizi per ricevere notifiche di pianificazione e stato 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 e configurare la pianificazione e i dettagli della migrazione

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

• 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 vuole rinviare la migrazione, è possibile farlo per un mese alla volta, accedendo al pannello Migrazione dell'istanza del server singolo nel portale di Azure e riprogrammando la migrazione, selezionando un'altra finestra di migrazione entro un mese.

• Se il server singolo ha uno 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 l'istanza del server singolo dispone di uno o più di Collegamento privato, Chiave gestita dal cliente (CMK) e Amministratore di Microsoft Entra abilitato, la migrazione automatica sul posto richiede input obbligatori per gli endpoint privati, CMK e Microsoft Entra admin per la migrazione dall'istanza del server singolo all'istanza del server flessibile di destinazione. Gli input utente devono essere forniti 2 giorni prima della finestra di migrazione pianificata. Se gli input dell'utente non vengono forniti prima che i dettagli della migrazione siano bloccati, la migrazione verrà ripianificata in un secondo momento. Dopo aver specificato tutti gli input, assicurarsi di salvare la configurazione nella procedura guidata di migrazione automatica. Passaggi per fornire l'input dell'utente:

  • Passare al pannello Migrazione dell'istanza del server singolo e selezionare Modifica migrazione pianificata.
  • Nella sezione Dettagli migrazione automatica fare clic sul pulsante Autentica per autenticare e salvare la connessione API ARM per eseguire la migrazione del server.
  • Se nel server è configurato Microsoft Entra Admin, è possibile fornire input nella sezione Microsoft Entra Admin nella procedura guidata di migrazione automatica:
    • La migrazione dell'amministratore di Microsoft Entra per il server di destinazione richiede l'aggiunta di un'identità al server flessibile di Database di Azure per MySQL. Per l'identità sono necessari i privilegi seguenti: User.Read.All, GroupMember.Read.All e Application.Read.All. Selezionare un'identità gestita assegnata dall'utente appropriata e concedere le autorizzazioni appropriate seguendo questa procedura.
  • Se nel server è configurata la chiave gestita dal cliente, è possibile fornire input nella sezione Crittografia dati della procedura guidata per la migrazione automatica:
    • La migrazione della crittografia della chiave gestita dal cliente richiede l'aggiunta di un'identità al server flessibile di Database di Azure per MySQL. Selezionare un'identità gestita assegnata dall'utente appropriata. L'identificatore di chiave/chiave elencato viene migrato dal server di origine al server di destinazione e deve essere concesso i privilegi seguenti: Get, Wrap Key, Unwrap Key per accedere all'insieme di credenziali delle chiavi.
  • Se il server singolo ha endpoint privati, eseguire i passaggi obbligatori seguenti quando si esamina la pianificazione della migrazione almeno 2 giorni prima della migrazione pianificata:
    • Rivedere 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 e la zona DNS privata appropriate.
      • La zona DNS privato personalizzata non è supportata dalla migrazione automatica. La zona DNS privato deve essere privatelink.mysql.database.azure.com.
      • Il metodo di approvazione della connessione degli endpoint privati deve essere impostato come approvazione automatica e non come approvazione manuale. Gli endpoint privati di approvazione manuale non sono supportati dalla migrazione automatica.
    • Assicurarsi di disporre dell'accesso al ruolo Collaboratore a livello di sottoscrizione o gruppo di risorse per evitare problemi di autorizzazioni durante l'autenticazione.
    • Selezionare la casella di controllo di conferma dopo aver eseguito i controlli dei prerequisiti elencati per la migrazione degli endpoint privati.

  Nota

  Se gli input obbligatori per la migrazione non vengono forniti almeno 2 giorni prima della migrazione pianificata, la migrazione viene riprogrammata in una data successiva.

  Nota

  Per l'istanza server singolo con endpoint privati, eliminare l'istanza di origine server singolo dopo la convalida della migrazione. Se non viene eseguita alcuna operazione di eliminazione del server, l'istanza di origine viene mantenuta fino a 14 giorni dopo la quale verrà eliminata dal servizio.

Controlli dei prerequisiti per la migrazione automatica sul posto

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

• Lo stato dell'istanza del server singolo deve essere impostato su Pronto e l'istanza non deve essere arrestata durante la finestra di manutenzione pianificata per l'esecuzione della migrazione automatica.
• I parametri del server, le impostazioni, la configurazione e le regole del firewall dell'istanza del server singolo non devono essere aggiornati durante la finestra di 2 giorni prima della migrazione automatica pianificata.
• Per l'istanza del server singolo con SSL abilitato, assicurarsi di avere tutti e tre i certificati (BaltimoreCyberTrustRoot, DigiCertGlobalRootG2 Root CA e DigiCertGlobalRootCA Root CA) disponibili nell'archivio radice attendibile. Inoltre, se il certificato è stato aggiunto alla 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, l'ordinamento potrebbe essere stato modificato. Se il conservazione 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'istanza del server singolo di Database di Azure per MySQL di origine 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'istanza del server singolo di Database di Azure per MySQL di origine 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'istanza del server singolo di Database di Azure per MySQL di origine ha nomi di regole del firewall superiori a 80 caratteri, rinominarle per garantire che la lunghezza del nome sia inferiore a 80 caratteri. La lunghezza per i nomi delle regole del firewall supportata nel server flessibile è di 80 caratteri, mentre nel server singolo la lunghezza consentita è di 128 caratteri.
• Se il server singolo di Database di Azure per MySQL di origine usa porte non predefinite, ad esempio 3308.3309 e 3310, modificare la porta di connettività su 3306 poiché le porte non predefinite indicate in precedenza non sono supportate nel server flessibile.

Come viene effettuato 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 effettuato in base al piano tariffario e ai vCore del server singolo di origine in linea con i dettagli nella tabella seguente.

• La versione MySQL, l'area, le *dimensioni di archiviazione, la sottoscrizione e il gruppo di risorse per il server flessibile di destinazione sono uguali a quelli 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, corrispondenti al limite di archiviazione minimo per il server flessibile di Database di Azure per MySQL.
• Entrambi i formati, nomeutente@nome_server (server singolo) e nomeutente (server flessibile) sono supportati nel server flessibile migrato.
• Entrambi i formati di stringa di connessione per server singolo e server flessibile sono supportati nel server flessibile migrato.
• Per l'istanza del server singolo con Query Store abilitato, il parametro del server "slow_query_log" nell'istanza di destinazione è impostato su SÌ per garantire la parità delle funzionalità durante la migrazione al server flessibile. Per determinati carichi di lavoro, questo potrebbe influire sulle prestazioni. Se si osserva una simile riduzione delle prestazioni, impostare questo parametro del server su "NO" nell'istanza del server flessibile.

Passaggi post-migrazione

Informazioni necessarie per le attività successive alla migrazione sul posto:

• Copiare le proprietà seguenti dal server singolo di origine al server flessibile di destinazione dopo il completamento dell'operazione di migrazione sul posto:
  • Impostazioni della pagina Monitoraggio (impostazioni di Avvisi, Metriche e Diagnostica) e impostazioni di blocco
  • Tutti gli script di Terraform/interfaccia della riga di comando per gestire l'istanza del server singolo devono essere aggiornati con riferimenti al server flessibile.
• Per l'istanza del server singolo con Query Store abilitato, il parametro del server "slow_query_log" nell'istanza di destinazione è impostato su SÌ 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. Se si osserva una simile riduzione delle prestazioni, impostare questo parametro del server su "NO" nell'istanza del server flessibile.
• Per l'istanza server singolo con endpoint privati, eliminare l'istanza di origine server singolo dopo la convalida della migrazione. Se non viene eseguita alcuna operazione di eliminazione del server, l'istanza di origine viene mantenuta fino a 14 giorni dopo la quale verrà eliminata dal servizio.
• Per l'istanza del server singolo con Microsoft Defender per il cloud abilitato, viene eseguita la migrazione dello stato di abilitazione. Per ottenere la parità dopo la migrazione automatica al server flessibile per le proprietà che è possibile configurare nel server singolo, prendere in considerazione i dettagli nella tabella seguente:

Domande frequenti (FAQ)

D. Per quale motivo 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? Quali elementi vengono migrati?

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 trasferisce tutti i file di dati del server (inclusi schema, dati, accessi) oltre ai parametri del server (tutti i parametri del server modificati nell'origine vengono copiati nel server di destinazione, mentre i parametri del server non modificati assumono 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 pianificazione e stato 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 posticipare 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 farlo al massimo per un mese, accedendo al pannello Migrazione dell'istanza del server singolo nel portale di Azure e riprogrammando la migrazione, selezionando un'altra finestra di migrazione entro un mese. I dettagli della migrazione vengono bloccati sette giorni prima della finestra di migrazione pianificata, dopo i quali non sarà possibile riprogrammarla. 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 nomeutente@nome_server (formato per il server singolo) e nomeutente (formato per il server flessibile) sono supportati per il server flessibile migrato e quindi non è necessario aggiornarli per mantenere la continuità dell'applicazione dopo la migrazione. Inoltre, entrambi i formati di stringa di connessione (formato per il server singolo e flessibile) saranno supportati anche per il server flessibile migrato.

D. Come si abilita la disponibilità elevata per il server migrato automaticamente?

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 e ottimizzato per la memoria nel Server flessibile di destinazione, in quanto la migrazione da SKU Basic a SKU con possibilità di burst non supporta la configurazione della disponibilità elevata.

D. È prevista una differenza di prezzo nel potenziale passaggio dal server singolo di base MySQL al server flessibile MySQL?

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

Contenuto correlato

• Gestire un server flessibile di Database di Azure per MySQL tramite il portale di Azure.