Condividi tramite

Endpoint virtuali per le repliche in lettura in Database di Azure per PostgreSQL - Server flessibile

  • Articolo

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Gli endpoint virtuali sono endpoint listener di lettura/scrittura e di sola lettura, che rimangono coerenti indipendentemente dal ruolo corrente dell'istanza del server flessibile di Database di Azure per PostgreSQL. Ciò significa che non è necessario aggiornare la stringa di connessione dell'applicazione dopo aver eseguito l'azione Alza di livello a server primario, perché gli endpoint punteranno automaticamente all'istanza corretta dopo una modifica del ruolo.

Tutte le operazioni che coinvolgono endpoint virtuali, che si tratti di aggiunta, modifica o rimozione, vengono eseguite nel contesto del server primario. Nel portale di Azure questi endpoint vengono gestiti nella pagina del server primario. Analogamente, quando si usano strumenti come l'interfaccia della riga di comando, l'API REST o altre utilità, i comandi e le azioni usano il server primario per la gestione degli endpoint.

Gli endpoint virtuali offrono due tipi distinti di punti di connessione:

Endpoint writer (lettura/scrittura): questo endpoint punta sempre al server primario corrente. Garantisce che le operazioni di scrittura vengano indirizzate al server corretto, indipendentemente dal trigger degli utenti delle operazioni di promozione. Non è possibile modificare questo endpoint in modo che punti a una replica.

Endpoint di sola lettura: questo endpoint può essere configurato dagli utenti per puntare a una replica di lettura o al server primario. Tuttavia, può specificare come destinazione un solo server alla volta. Il bilanciamento del carico tra più server non è supportato. È possibile modificare il server di destinazione per questo endpoint in qualsiasi momento, sia prima che dopo l'innalzamento di livello.

Nota

È possibile creare un solo writer e un solo endpoint di sola lettura per ogni replica primaria e una delle relative repliche.

Endpoint virtuali e comportamento di innalzamento di livello

In caso di azione di innalzamento di livello, il comportamento di questi endpoint rimane prevedibile. Le sezioni seguenti illustrano in che modo questi endpoint reagiscono sia agli scenari Alza di livello a server primario che a quello Alza di livello a server indipendente.

Endpoint virtuale Destinazione originale Comportamento quando viene attivato "Alza di livello al server primario" Comportamento quando viene attivato "Alza di livello a server indipendente"
Endpoint writer Principale Punta al nuovo server primario. Rimane invariato.
Endpoint di sola lettura Replica Punta alla nuova replica (precedentemente il server primario). Punta al server primario.
Endpoint di sola lettura Principale Non supportato. Rimane invariato.

Comportamento quando viene attivato "Alza di livello al server primario"

  • Endpoint writer: questo endpoint viene aggiornato in modo che punti al nuovo server primario, riflettendo il cambio di ruolo.
  • Endpoint di sola lettura
    • Se l'endpoint di sola lettura punta alla replica: dopo l'azione di innalzamento di livello, l'endpoint di sola lettura punterà alla nuova replica (la precedente replica primaria).
    • Se l'endpoint di sola lettura punta al server primario: per il corretto funzionamento dell'innalzamento di livello, l'endpoint di sola lettura deve puntare al server che deve essere alzato di livello. Puntare al server primario, in questo caso, non è un'operazione supportata ed è necessario modificare la configurazione in modo da puntare alla replica prima dell'innalzamento di livello.

Comportamento quando viene attivato il messaggio "Alza di livello a server indipendente e rimuovi dalla replica"

  • Endpoint writer: questo endpoint rimane invariato. Continua a indirizzare il traffico al server, mantenendo il ruolo primario.
  • Endpoint di sola lettura
    • Se l'endpoint di sola lettura punta alla replica: l'endpoint di sola lettura viene reindirizzato dalla replica alzata di livello in modo che punti al server primario.
    • Se l'endpoint di sola lettura punta al server primario: l'endpoint di sola lettura rimane invariato, continuando a puntare allo stesso server.

Uso di endpoint virtuali per il nome host coerente durante il ripristino temporizzato (PITR) o snapshot

Questa sezione illustra come usare endpoint virtuali nel server flessibile di Database di Azure per PostgreSQL per mantenere un nome host coerente durante il ripristino temporizzato (PITR) o il ripristino snapshot, assicurando che le stringhe di connessione dell'applicazione rimangano invariate. Seguire questa procedura:

  1. Aggiungere endpoint virtuale al server primario:

    • Passare all'istanza del server primario nel portale di Azure.
    • Passare alla scheda Replica e in Endpoint virtuali fare clic su Aggiungi endpoint virtuale.
    • Configurare l'endpoint virtuale con un nome host coerente, ad esempio mydb-virtual-endpoint.postgres.database.azure.com.
    • Fare clic su Salva per salvare la configurazione.
    • Aggiornare l'applicazione per usare questo endpoint virtuale nella stringa di connessione.

  2. Eseguire il ripristino temporizzato (PITR) o il ripristino dello snapshot:

    • Avviare il ripristino:
      • Passare alla sezione Backup del server primario.
      • Scegliere l'opzione di ripristino appropriata (PITR o snapshot) e specificare il punto desiderato nel tempo.
    • Aggiornare l'endpoint virtuale:
      • Dopo aver creato la nuova istanza, tornare alla scheda Replica del server primario precedente.
      • Rimuovere l'endpoint virtuale dal server primario originale. Il database primario precedente deve trovarsi nello stato succeeded per rimuovere l'endpoint virtuale
      • Aggiungere lo stesso endpoint virtuale al server appena creato.

  3. Convalida:

    • Assicurarsi che l'applicazione si connetta usando l'endpoint virtuale e verificare le operazioni del database dopo il ripristino.

Contenuto correlato