Creare e gestire repliche in lettura in Database di Azure per PostgreSQL - Server flessibile dall'API REST portale di Azure, interfaccia della riga di comando o API REST
Articolo
SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile
Questo articolo illustra come creare e gestire repliche in lettura in Database di Azure per PostgreSQL server flessibile dal portale di Azure, dall'interfaccia della riga di comando e dall'API REST. Per altre informazioni sulle repliche in lettura, vedere la panoramica.
Prerequisiti
Un'istanza del server flessibile Database di Azure per PostgreSQL essere il server primario.
Nota
Quando si distribuiscono repliche in lettura per carichi di lavoro primari a elevato utilizzo di scrittura persistente, il ritardo di replica potrebbe continuare a crescere e non può mai essere aggiornato con il database primario. Questo potrebbe anche aumentare l'utilizzo dell'archiviazione nel database primario perché i file WAL vengono eliminati solo una volta ricevuti nella replica.
Esaminare le impostazioni primarie
Prima di configurare una replica di lettura per Database di Azure per PostgreSQL server flessibile, verificare che il server primario sia configurato per soddisfare i prerequisiti necessari. Le impostazioni specifiche nel server primario possono influire sulla possibilità di creare repliche.
Aumento automatico dell'archiviazione: le impostazioni di aumento automatico dell'archiviazione nel server primario e le relative repliche in lettura devono rispettare linee guida specifiche per garantire coerenza e impedire interruzioni della replica. Per informazioni dettagliate su regole e impostazioni, vedere Aumento automatico archiviazione .
SSD Premium v2: la versione corrente non supporta la creazione di repliche in lettura per i server primari che usano l'archiviazione SSD Premium v2. Se il carico di lavoro richiede repliche in lettura, scegliere un'opzione di archiviazione diversa per il server primario.
Nella portale di Azure scegliere l'istanza del server flessibile Database di Azure per PostgreSQL desiderata per la replica.
Nella finestra di dialogo Panoramica prendere nota della versione di PostgreSQL (ad esempio 15.4). Si noti anche che l'area primaria viene distribuita in (ad esempio, East US).
Nella barra laterale del server, in Impostazioni, selezionare Calcolo e archiviazione.
Esaminare e prendere nota delle impostazioni seguenti:
Livello di calcolo, Processore, Dimensioni (ad esempio Standard_D4ads_v5).
Storage
Dimensioni di archiviazione (ad esempio 128GB)
Aumento automatico
Disponibilità elevata
Abilitato/Disabilitato
Impostazioni della zona di disponibilità
Impostazioni backup
Periodo di memorizzazione
Opzioni di ridondanza
In Impostazioni selezionare Rete.
Rivedere le impostazioni di rete.
Nota
I comandi forniti in questa guida sono applicabili per l'interfaccia della riga di comando di Azure versione 2.56.0 o successiva. Assicurarsi di disporre della versione necessaria o di una versione successiva installata per eseguire correttamente questi comandi. È possibile controllare la versione corrente dell'interfaccia della riga di comando di Azure eseguendo az --version nell'interfaccia della riga di comando. Per aggiornare l'interfaccia della riga di comando di Azure alla versione più recente, seguire le istruzioni fornite nella documentazione dell'interfaccia della riga di comando di Azure.
Per visualizzare la configurazione e lo stato corrente di un server flessibile di Azure PostgreSQL, usare il az postgres flexible-server show comando . Questo comando fornisce informazioni dettagliate sul server specificato.
az postgres flexible-server show \
--resource-group <resource-group> \
--name <server-name>
Sostituire <resource-group> e <server-name> con il gruppo di risorse specifico e il nome del server da visualizzare.
Esaminare e prendere nota delle impostazioni seguenti:
Livello di calcolo, Processore, Dimensioni (ad esempio Standard_D8ads_v5).
Per ottenere informazioni sulla configurazione di un server in Database di Azure per PostgreSQL server flessibile, in particolare per visualizzare le impostazioni per le funzionalità introdotte di recente, ad esempio l'aumento automatico dell'archiviazione o il collegamento privato, è consigliabile usare la versione 2023-06-01-previewpiù recente dell'API . La GET richiesta verrà formattata come segue:
Sostituire {subscriptionId}, {resourceGroupName}e {serverName} con l'ID sottoscrizione di Azure, il nome del gruppo di risorse e il nome del server primario da esaminare rispettivamente. Questa richiesta consente di accedere ai dettagli di configurazione del server primario, assicurandosi che sia configurata correttamente per la creazione di una replica in lettura.
Esaminare e prendere nota delle impostazioni seguenti:
Livello di calcolo, Processore, Dimensioni (ad esempio Standard_D8ads_v5).
Selezionare un'istanza del server flessibile Database di Azure per PostgreSQL esistente da usare come server primario.
Nella barra laterale del server, in Impostazioni, selezionare Replica.
Selezionare Crea replica.
Immettere il modulo Informazioni di base con le informazioni seguenti.
Selezionare Rivedi e crea per confermare la creazione della replica o Avanti: Rete se si desidera aggiungere, eliminare o modificare le regole del firewall.
Lasciare le impostazioni predefinite rimanenti e quindi selezionare il pulsante Rivedi e crea nella parte inferiore della pagina oppure passare ai moduli successivi per aggiungere tag o modificare il metodo di crittografia dei dati.
Esaminare le informazioni nella finestra di conferma finale. Al termine, selezionare Crea. Viene creata una nuova distribuzione.
Durante la distribuzione viene visualizzato lo stato primario Updating .
Dopo aver creato la replica di lettura, può essere visualizzata dalla finestra Replica .
Sostituire <replica-name>, <resource-group>, <source-server-name>e <location> con i valori specifici.
Dopo aver creato la replica di lettura, è possibile ottenere le proprietà di tutti i server, ovvero le repliche di una replica primaria usando il az postgres flexible-server replica create comando .
az postgres flexible-server replica list \
--name <source-server-name> \
--resource-group <resource-group>
Sostituire <source-server-name>e <resource-group> con i valori specifici.
Avviare una HTTP PUT richiesta usando l'API create dai server:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2022-12-01
In questo caso, è necessario sostituire {subscriptionId}, {resourceGroupName}e {replicaserverName} con l'ID sottoscrizione di Azure specifico, il nome del gruppo di risorse e il nome desiderato rispettivamente per la replica in lettura.
Dopo aver creato la replica in lettura, è possibile ottenere le proprietà di tutti i server, ovvero le repliche di una replica primaria avviando una HTTP GET richiesta tramite l'elenco di repliche in base all'API del server:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/replicas?api-version=2022-12-01
In questo caso è necessario sostituire {subscriptionId}, {resourceGroupName}e {sourceserverName} con l'ID sottoscrizione di Azure specifico, il nome del gruppo di risorse e il nome assegnato rispettivamente alla replica primaria.
Si tratta di una procedura consigliata di Cloud Adoption Framework (CAF) per usare una convenzione di denominazione delle risorse che consentirà di determinare facilmente l'istanza a cui ci si connette o si sta gestendo e dove si trova.
Selezionare una località diversa da quella primaria, ma si noti che è possibile selezionare la stessa area.
Impostare il calcolo e l'archiviazione su ciò che è stato registrato dall'istanza primaria. Se il calcolo visualizzato non corrisponde, selezionare Configura server e selezionare quello appropriato.
Nota
Se si seleziona una dimensione di calcolo inferiore a quella primaria, la distribuzione avrà esito negativo. Tenere presente anche che le dimensioni di calcolo potrebbero non essere disponibili in un'area diversa.
Per evitare problemi durante la promozione delle repliche, modificare costantemente i parametri del server seguenti nelle repliche prima di applicarli al database primario: max_connections, max_prepared_transactions, max_locks_per_transaction, max_wal_senders, max_worker_processes.
Creare endpoint virtuali
Nota
Tutte le operazioni che coinvolgono endpoint virtuali, ad esempio l'aggiunta, la modifica o la rimozione, vengono eseguite nel contesto del server primario.
Sostituire <resource-group>, <primary-name>, <virtual-endpoint-name>e <replica-name> con i valori specifici.
Per creare un endpoint virtuale usando l'API REST di Azure, usare una HTTP PUT richiesta. La richiesta sarà simile alla seguente:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/virtualendpoints/{virtualendpointName}?api-version=2023-06-01-preview
Il corpo JSON a accompagnamento per questa richiesta è il seguente:
In questo caso, {replicaserverName} deve essere sostituito con il nome del server di replica incluso come destinazione dell'endpoint lettore in questo endpoint virtuale.
Elencare gli endpoint virtuali
Per elencare gli endpoint virtuali, seguire questa procedura:
Nella portale di Azure selezionare il server primario.
Nella barra laterale del server, in Impostazioni, selezionare Replica.
Nella parte superiore della pagina vengono visualizzati sia gli endpoint lettore che gli endpoint del writer, insieme ai nomi dei server a cui puntano.
È possibile visualizzare i dettagli dell'endpoint virtuale usando il list comando o show . Dato che è consentito un solo endpoint virtuale per ogni coppia di repliche primaria, entrambi i comandi producono lo stesso risultato.
Ecco un esempio di come usare il list comando :
az postgres flexible-server virtual-endpoint list \
--resource-group <resource-group> \
--server-name <server-name>
Sostituire <server-name> con il nome del server primario e <resource-group> con il nome del gruppo di risorse.
Ecco come usare il show comando :
az postgres flexible-server virtual-endpoint show \
--name <virtual-endpoint-name>
--resource-group <resource-group> \
--server-name <server-name>
In questo comando sostituire <virtual-endpoint-name>,<server-name> e <resource-group> con i rispettivi nomi. <server-name> è il nome del server primario.
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{sourceserverName}/virtualendpoints?api-version=2023-06-01-preview
In questo caso, {sourceserverName} deve essere il nome del server primario da cui si gestiscono gli endpoint virtuali.
Modificare l'applicazione in modo che punti all'endpoint virtuale
Modificare tutte le applicazioni che usano l'istanza del server flessibile Database di Azure per PostgreSQL per usare i nuovi endpoint virtuali ,ad esempio corp-pg-001.writer.postgres.database.azure.com e corp-pg-001.reader.postgres.database.azure.com.
Alzare di livello le repliche
Con tutti i componenti necessari, è possibile eseguire un'operazione di promozione alla replica primaria.
Per alzare di livello la replica dal portale di Azure, seguire questa procedura:
Nella portale di Azure selezionare l'istanza del server flessibile Database di Azure per PostgreSQL primaria.
Nel menu del server, in Impostazioni, selezionare Replica.
In Server selezionare l'icona Alza di livello per la replica.
Nella finestra di dialogo verificare che l'azione sia Alza di livello al server primario.
Per Sincronizzazione dati assicurarsi che i dati pianificati - sincronizzano prima di promuovere l'opzione .
Selezionare Alza di livello per avviare il processo. Al termine, i ruoli si invertono: la replica diventa primaria e la replica primaria assume il ruolo della replica.
Quando si promuove una replica in un server primario nel server flessibile di Azure PostgreSQL, usare il az postgres flexible-server replica promote comando . Questo processo è essenziale per elevare un server di replica in modo che funzioni come server primario e abbassamento di livello del ruolo primario corrente per la replica. Specificare --promote-mode switchover e --promote-option planned nel comando .
Sostituire <resource-group> e <replica-server-name> con il nome del server di replica e del gruppo di risorse specifico. Questo comando garantisce una transizione uniforme della replica a un ruolo primario in modo pianificato.
Quando si promuove una replica in un server primario, usare una HTTP PATCH richiesta con un corpo specifico JSON per impostare le opzioni di promozione. Questo processo è fondamentale quando è necessario elevare un server di replica per fungere da server primario.
La HTTP richiesta è strutturata nel modo seguente:
In questo JSON, l'innalzamento di livello viene impostato in switchover modalità con un'opzione planned di promozione. Anche se sono disponibili due opzioni per l'innalzamento di livello, planned oppure forced , scegliere planned per questo esercizio.
Nota
La replica che si promuove deve avere l'endpoint virtuale lettore assegnato oppure verrà visualizzato un errore durante l'innalzamento di livello.
Testare le applicazioni
Per eseguire alcune operazioni, riavviare le applicazioni e quindi tentare tali operazioni. Le applicazioni devono funzionare senza problemi senza modificare l'endpoint virtuale stringa di connessione o le voci DNS. Lasciare le applicazioni in esecuzione questa volta.
Failback nel server e nell'area originali
Ripetere le stesse operazioni per alzare di livello il server originale al server primario.
Nella barra laterale del server, in Impostazioni, selezionare Replica
In Server selezionare l'icona Alza di livello per la replica.
Nella finestra di dialogo verificare che l'azione sia Alza di livello al server primario.
Per Sincronizzazione dati assicurarsi che i dati pianificati - sincronizzano prima di promuovere l'opzione .
Selezionare Alza di livello, viene avviato il processo. Al termine, i ruoli si invertono: la replica diventa primaria e la replica primaria assume il ruolo della replica.
Questa volta, modificare nel <replica-server-name>az postgres flexible-server replica promote comando per fare riferimento al server primario precedente, che attualmente funge da replica ed eseguire di nuovo la richiesta.
Sostituire <resource-group> e <replica-server-name> con il gruppo di risorse specifico e il nome del server di replica corrente.
Questa volta, modificare nella {replicaserverName} richiesta API per fare riferimento al server primario precedente, che attualmente funge da replica ed eseguire di nuovo la richiesta.
In questo JSON, l'innalzamento di livello viene impostato in switchover modalità con un'opzione planned di promozione. Anche se sono disponibili due opzioni per l'innalzamento di livello, planned oppure forced , scegliere planned per questo esercizio.
Testare le applicazioni
Anche in questo caso, passare a una delle applicazioni che utilizzano. Attendere che lo stato primario e di replica venga modificato Updating in e quindi tentare di eseguire alcune operazioni. Durante la promozione della replica, l'applicazione potrebbe riscontrare problemi di connettività temporanei all'endpoint:
Aggiungere una replica in lettura secondaria
Creare una replica di lettura secondaria in un'area separata per modificare l'endpoint virtuale lettore e consentire la creazione di un server indipendente dalla prima replica.
Nella portale di Azure scegliere l'istanza del server flessibile Database di Azure per PostgreSQL primaria.
Nella barra laterale del server, in Impostazioni, selezionare Replica.
Selezionare Crea replica.
Immettere il modulo Informazioni di base con le informazioni in una terza area (ad esempio westus e corp-pg-westus-001)
Selezionare Rivedi e crea per confermare la creazione della replica o Avanti: Rete se si desidera aggiungere, eliminare o modificare le regole del firewall.
Verificare le impostazioni del firewall. Si noti che le impostazioni primarie vengono copiate automaticamente.
Lasciare le impostazioni predefinite rimanenti e quindi selezionare il pulsante Rivedi e crea nella parte inferiore della pagina oppure passare ai moduli seguenti per configurare la sicurezza o aggiungere tag.
Esaminare le informazioni nella finestra di conferma finale. Al termine, selezionare Crea. Viene creata una nuova distribuzione.
Durante la distribuzione viene visualizzato lo stato primario Updating .
Scegliere un nome distinto per <replica-name> distinguerlo dal server primario e da qualsiasi altra replica.
Sostituire <resource-group>, <source-server-name>e <location> con i valori specifici.
È possibile creare una replica di lettura secondaria usando l'API di creazione dei server:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.DBForPostgreSql/flexibleServers/{replicaserverName}?api-version=2022-12-01
Scegliere un nome distinto per {replicaserverName} distinguerlo dal server primario e da qualsiasi altra replica.
Nella portale di Azure scegliere l'istanza del server flessibile Database di Azure per PostgreSQL primaria.
Nella barra laterale del server, in Impostazioni, selezionare Replica.
Selezionare i puntini di sospensione e quindi selezionare Modifica.
Nella finestra di dialogo selezionare la nuova replica secondaria.
Seleziona Salva. L'endpoint del lettore è ora associato alla replica secondaria e l'operazione di promozione è ora associata a questa replica.
È ora possibile modificare l'endpoint del lettore in modo che punti alla replica secondaria appena creata usando un az postgres flexible-server virtual-endpoint update comando . Ricordarsi di sostituire <replica-name> con il nome della replica di lettura appena creata.
Sostituire <resource-group>, <server-name>, <virtual-endpoint-name>e <replica-name> con i valori specifici.
È ora possibile modificare l'endpoint del lettore in modo che punti alla replica secondaria appena creata usando una PATCH richiesta. Ricordarsi di sostituire {replicaserverName} con il nome della replica di lettura appena creata.
Nella portale di Azure scegliere il server primario del server flessibile Database di Azure per PostgreSQL.
Nella barra laterale del server, nel menu del server, in Impostazioni selezionare Replica.
In Server selezionare l'icona Alza di livello per la replica da alzare di livello a un server indipendente.
Nella finestra di dialogo verificare che l'azione sia Alza di livello al server indipendente e rimuovere dalla replica. Questo non influirà sul server primario.
Per Sincronizzazione dati assicurarsi che i dati pianificati - sincronizzano prima di promuovere l'opzione .
Selezionare Alza di livello, viene avviato il processo. Al termine, il server non è più una replica del database primario.
Quando si alza di livello una replica nel server flessibile di Azure PostgreSQL, il comportamento predefinito consiste nel promuoverlo in un server indipendente. L'innalzamento di livello viene ottenuto usando il az postgres flexible-server replica promote comando senza specificare l'opzione --promote-mode , perché standalone la modalità viene presupposta per impostazione predefinita.
In questo comando sostituire <resource-group> e <replica-server-name> con il nome del gruppo di risorse specifico e il nome del primo server di replica creato, che non fa più parte dell'endpoint virtuale.
È possibile alzare di livello una replica a un server autonomo usando una PATCH richiesta. Inviare una PATCH richiesta all'URL dell'API REST di gestione di Azure specificato con il primo JSON corpo, dove PromoteMode è impostato su standalone e PromoteOption su planned. Il secondo JSON formato del corpo, l'impostazione ReplicationRole su None, è deprecata, ma è ancora menzionata qui per la compatibilità con le versioni precedenti.
Nella portale di Azure selezionare il server primario.
Nella barra laterale del server, in Impostazioni, selezionare Replica.
Nella parte superiore della pagina individuare la Virtual endpoints sezione . Passare ai tre puntini (opzioni di menu) accanto al nome dell'endpoint, espanderlo e scegliere Delete.
Viene visualizzata una finestra di dialogo di conferma dell'eliminazione. Viene visualizzato un avviso: "Questa azione elimina l'endpoint virtualendpointNamevirtuale . Tutti i client connessi con questi domini potrebbero perdere l'accesso." Confermare le implicazioni e confermare facendo clic su Elimina.
Per rimuovere un endpoint virtuale da un server flessibile di Azure PostgreSQL, è possibile usare il az postgres flexible-server virtual-endpoint delete comando . Questa azione elimina definitivamente l'endpoint virtuale specificato.
In questo comando sostituire <resource-group>, <server-name>e <virtual-endpoint-name> con il gruppo di risorse, il nome del server e il nome dell'endpoint virtuale da eliminare.
Per eliminare un endpoint virtuale usando l'API REST di Azure, è necessario eseguire una HTTP DELETE richiesta. L'URL della richiesta sarà strutturato come segue:
È possibile eliminare una replica in lettura simile alla modalità di eliminazione di un'istanza autonoma del server Database di Azure per PostgreSQL flessibile.
Nel portale di Azure aprire la pagina Panoramica relativa alla replica in lettura. Selezionare Elimina.
È anche possibile eliminare la replica in lettura dalla finestra Replica seguendo la procedura seguente:
Nella portale di Azure selezionare l'istanza del server flessibile Database di Azure per PostgreSQL primaria.
Nel menu del server, in Impostazioni, selezionare Replica.
Selezionare la replica di lettura da eliminare e quindi selezionare i puntini di sospensione. Selezionare Elimina.
Confermare l'operazione di eliminazione .
Per eliminare un server primario o di replica, usare il az postgres flexible-server delete comando . Se il server dispone di repliche in lettura, è necessario eliminare le repliche di lettura prima di eliminare il server primario.
az postgres flexible-server delete \
--resource-group <resource-group> \
--name <server-name>
Sostituire <resource-group> e <server-name> con il nome del gruppo di risorse e il nome del server di replica da eliminare.
Per eliminare un server primario o di replica, usare l'API di eliminazione dei server. Se il server dispone di repliche in lettura, è necessario eliminare le repliche di lettura prima di eliminare il server primario.
È possibile eliminare il server primario solo dopo aver eliminato tutte le repliche in lettura. Per eliminare le repliche, seguire le istruzioni nella sezione Eliminare una replica e quindi procedere con i passaggi forniti.
Per eliminare un server dal portale di Azure, seguire questa procedura:
Nella portale di Azure selezionare l'istanza del server flessibile Database di Azure per PostgreSQL primaria.
Aprire la pagina Panoramica per il server e selezionare Elimina.
Immettere il nome del server primario da eliminare. Selezionare Elimina per confermare l'eliminazione del server primario.
Per eliminare un server primario o di replica, usare il az postgres flexible-server delete comando . Se il server dispone di repliche in lettura, è necessario eliminare le repliche di lettura prima di eliminare il server primario.
az postgres flexible-server delete \
--resource-group <resource-group> \
--name <server-name>
Sostituire <resource-group> e <server-name> con il nome del gruppo di risorse e il nome del server primario da eliminare.
Per eliminare un server primario o di replica, usare l'API di eliminazione dei server. Se il server dispone di repliche in lettura, è necessario eliminare le repliche di lettura prima di eliminare il server primario.
Per monitorare le repliche in lettura sono disponibili due metriche.
Ritardo massimo replica fisica
Disponibile solo nel database primario.
La metrica Max Physical Replication Lag (Ritardo replica fisica massima) mostra il ritardo di byte tra il server primario e la replica più in ritardo.
Nella portale di Azure selezionare il server primario.
Selezionare Metriche. Nella finestra Metriche selezionare Max Physical Replication Lag ( Max Physical Replication Lag).
Selezionare Max come Aggregazione.
Metrica Read Replica Lag (Ritardo replica in lettura)
La metrica Read Replica Lag indica l'ora dell'ultima transazione riprodotta in una replica. Se non si verificano transazioni nel database primario, la metrica riflette questo intervallo di tempo. Ad esempio, se non si verificano transazioni nel server primario e l'ultima transazione è stata riprodotta 5 secondi fa, il ritardo di replica di lettura mostra un ritardo di 5 secondi.
Nella portale di Azure selezionare Replica di lettura.
Selezionare Metriche. Nella finestra Metriche selezionare Read Replica Lag (Ritardo replica lettura).