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 disponibilità elevata è una funzionalità chiave di Database di Azure per MySQL, progettata per ridurre al minimo i tempi di inattività e garantire che le applicazioni rimangano accessibili anche durante la manutenzione pianificata o interruzioni impreviste. Questo articolo illustra le domande comuni sulle opzioni a disponibilità elevata, la fatturazione, i processi di failover, gli impatti sulle prestazioni e le procedure consigliate per prendere decisioni informate per i carichi di lavoro MySQL in Azure.
Confronto tra i contratti di servizio per i server flessibili con disponibilità elevata e ridondanza nella stessa zona e quelli con ridondanza della zona.
Le informazioni sul contratto di servizio per il server flessibile di Database di Azure per MySQL sono disponibili in Contratto di servizio per Database di Azure per MySQL.
Come vengono fatturati i server a disponibilità elevata?
I server abilitati con disponibilità elevata hanno una replica primaria e secondaria. La replica secondaria si può trovare nella stessa zona o può offrire la ridondanza della zona. Vengono addebitati i costi per il calcolo e l'archiviazione di cui è stato effettuato il provisioning per la replica primaria e secondaria. Ad esempio, se si ha un database primario con 4 vCores di calcolo e 512 GB di archiviazione predefinita, la replica secondaria ha 4 vCores e 512 GB di archiviazione predefinita.
Il server a disponibilità elevata con ridondanza della zona verrà fatturato per 8 vCore e 1.024 GB di spazio di archiviazione. A seconda del volume di memoria di backup, potrebbe esserti addebitata anche la memoria di backup.
È possibile usare la replica standby per operazioni di lettura o scrittura?
Il server standby non è disponibile per le operazioni di lettura o scrittura. Si tratta di uno standby passivo per consentire il failover rapido.
Si verifica una perdita di dati quando si verifica il failover?
I log nell'archiviazione con ridondanza della zona sono accessibili anche quando il server primario non è disponibile. Questa disponibilità consente di garantire che non si verifichi alcuna perdita di dati. Dopo l'attivazione della replica standby e l'applicazione dei log binari, assume il ruolo del server primario.
È necessario eseguire un'azione dopo un failover?
I failover sono completamente trasparenti per l'applicazione client. Non è necessario eseguire alcuna azione. Le applicazioni devono usare solo la logica di ripetizione dei tentativi per le connessioni.
Cosa accade quando non si sceglie una zona specifica per la replica di standby? È possibile modificare la zona in un secondo momento?
Se non si sceglie una zona, ne viene selezionata una in modo casuale. È quello usato per il server primario. Per modificare la zona in un secondo momento, è possibile impostare Disponibilità elevata su Disabilitato nel riquadro Disponibilità elevata e quindi impostarlo di nuovo su Ridondanza della zona e scegliere una zona.
La replica tra le repliche primarie e di standby è sincrona?
La replicazione tra il database primario e lo standby è simile alla modalità semisincrona in MySQL. Quando viene eseguito il commit di una transazione, non viene necessariamente eseguito il commit nello standby. Tuttavia, quando il database primario non è disponibile, lo standby replica tutte le modifiche ai dati dal database primario per assicurarsi che non si verifichi alcuna perdita di dati.
Esiste un failover nella replica di standby per tutti gli errori non pianificati?
Se si verifica un arresto anomalo del database o un errore del nodo, la macchina virtuale del server flessibile viene riavviata nello stesso nodo. Allo stesso tempo, viene attivato un failover automatico. Se il riavvio della macchina virtuale del server flessibile ha esito positivo prima del completamento del failover, l'operazione di failover viene annullata. La determinazione del server da usare come replica primaria dipende dal processo che termina per primo.
Si verifica un impatto sulle prestazioni quando si usa la disponibilità elevata?
Per la disponibilità elevata con ridondanza della zona; benché l'impatto non sia significativo sulle prestazioni per i carichi di lavoro in lettura tra zone di disponibilità, potrebbe esserci un calo fino al 40% della latenza delle query in scrittura. L'aumento della latenza di scrittura è dovuto alla replica sincrona nella zona di disponibilità. L'impatto sulla latenza in scrittura è il doppio per la disponibilità elevata con ridondanza della zona rispetto alla disponibilità elevata nella stessa zona. Per la disponibilità elevata nella stessa zona: la latenza di replica e di conseguenza la latenza di scrittura sincrona sono inferiori poiché la replica primaria e di standby si trovano nella stessa zona.
In sintesi, se la latenza di scrittura è più critica rispetto alla disponibilità, è possibile scegliere disponibilità elevata con ridondanza locale, ma se la disponibilità e la resilienza dei dati sono più importanti a scapito dell'eliminazione della latenza di scrittura, è necessario scegliere disponibilità elevata con ridondanza della zona. Per misurare l'impatto accurato del calo della latenza nella configurazione a disponibilità elevata, è consigliabile eseguire test delle prestazioni per il carico di lavoro per prendere una decisione informata.
In che modo viene eseguita la manutenzione del server a disponibilità elevata?
Gli eventi pianificati, come il ridimensionamento del calcolo e gli aggiornamenti di versioni minori, vengono eseguiti prima sull'istanza di standby originale; successivamente, viene attivata un'operazione di failover pianificata, e poi vengono eseguiti sull'istanza primaria originale. È possibile impostare la finestra di manutenzione pianificata per i server a disponibilità elevata come per i server flessibili. La quantità di tempo di inattività corrisponde al tempo di inattività per l'istanza del server flessibile di Database di Azure per MySQL quando la disponibilità elevata è disabilitata.
È possibile eseguire un ripristino temporizzato del server a disponibilità elevata?
È possibile eseguire un ripristino temporizzato per un'istanza del server flessibile di Database di Azure per MySQL abilitata per la disponibilità elevata in una nuova istanza del server flessibile di Database di Azure per MySQL disabilitata. Se il server di origine è stato creato con alta disponibilità ridondante a zona, è possibile abilitare l'alta disponibilità ridondante a zona o l'alta disponibilità ridondante locale nel server ripristinato in un secondo momento. Se il server di origine è stato creato con disponibilità elevata e ridondanza nella stessa zona, è possibile abilitare solo la disponibilità elevata con ridondanza nella stessa zona nel server ripristinato.
È possibile abilitare la disponibilità elevata in un server dopo aver creato il server?
La disponibilità elevata con ridondanza della zona deve essere abilitata durante la creazione del server. È possibile abilitare l'alta disponibilità con ridondanza locale dopo la creazione del server, ma è necessario assicurarsi che i parametri del server enforce_gtid_consistency e gtid_mode siano impostati su ON prima di procedere.
È possibile disabilitare l'HA per un server dopo averlo creato?
È possibile disabilitare l'Alta Disponibilità in un server dopo averlo creato. La fatturazione si arresta immediatamente.
Come è possibile ridurre i tempi di inattività?
È necessario essere in grado di ridurre i tempi di inattività per l'applicazione anche quando non si usa la disponibilità elevata. Tempi di inattività del servizio, ad esempio patch pianificate, aggiornamenti di versioni secondarie o operazioni avviate dal cliente, ad esempio il ridimensionamento delle risorse di calcolo, possono essere eseguite durante le finestre di manutenzione pianificate. Per ridurre l'impatto dell'applicazione per le attività di manutenzione avviate da Azure, è possibile pianificarle in un giorno della settimana e l'ora che riduce al minimo l'impatto sull'applicazione.
È possibile usare una replica in lettura per un server abilitato per la disponibilità elevata?
Sì, le repliche in lettura sono supportate per i server a disponibilità elevata.
È possibile usare la replica dei dati in ingresso per i server a disponibilità elevata?
Il supporto per la replica in ingresso dei dati per i server con alta disponibilità è disponibile solo tramite la replica basata su GTID.
La stored procedure per la replica tramite GTID è disponibile in tutti i server abilitati per la disponibilità elevata in base al nome mysql.az_replication_with_gtid.
Per ridurre i tempi di inattività, è possibile eseguire il failover nel server di standby durante i riavvii del server o durante l'aumento o la riduzione delle prestazioni?
Attualmente, il server flessibile di Database di Azure per MySQL ha usato il failover pianificato per ottimizzare le operazioni a disponibilità elevata, tra cui l'aumento/riduzione delle prestazioni e la manutenzione pianificata per ridurre i tempi di inattività.
Al momento di avvio di tali operazioni, si procederà prima con l'istanza di standby originale, seguita dall'attivazione di un'operazione di failover pianificata, e poi con l'istanza primaria originale.
È possibile modificare la modalità di alta disponibilità (alta disponibilità con ridondanza zonale/ridondanza locale) del server**
Se si crea il server con la modalità disponibilità elevata e ridondanza della zona abilitata, è possibile passare dalla disponibilità elevata con ridondanza di zona alla disponibilità elevata nella stessa zona e viceversa.
Per modificare la modalità di disponibilità, è possibile impostare Disponibilità elevata su Disabilitato nel riquadro Disponibilità elevata e quindi impostarlo di nuovo su Ridondanza della zona o Con ridondanza locale e scegliere Modalità disponibilità elevata.