Descrivere la replica e la decodifica logica

Completato

Il parametro wal_level consente di definire la quantità di informazioni da scrivere nel log. Sono disponibili due opzioni: LOGICAL o REPLICA. REPLICA è l'impostazione predefinita. Questo parametro viene impostato all'avvio del server.

Disponibilità elevata

La disponibilità elevata è un servizio di Database di Azure per PostgreSQL, che offre un server di standby pronto per eseguire l'operazione se si verifica un errore nel server live. La disponibilità elevata nel server flessibile di Database di Azure per PostgreSQL usa la replica per aggiornare automaticamente il server di standby con modifiche ai dati.

Quando si configura la disponibilità elevata per il server flessibile di Database di Azure per PostgreSQL, il server primario viene inserito in una zona di disponibilità e viene creato un server di standby in una zona di disponibilità diversa. I dati vengono replicati dal server primario al server di standby usando la replica di streaming PostgreSQL in modalità sincrona.

Ogni zona di disponibilità è costituita da uno o più data center. Le zone di disponibilità hanno propri sistemi di alimentazione, propri sistemi di raffreddamento e una propria infrastruttura di rete e così via, cosa che le rende indipendenti una dall'altra. Tre copie dei file di dati e i file write-ahead log (WAL) vengono archiviati con ridondanza locale all'interno di ogni zona di disponibilità, fornendo l'isolamento fisico tra i server primario e di standby. Se una zona di disponibilità ha esito negativo, le altre due probabilmente continueranno a funzionare. Le zone di disponibilità all'interno di un'area sono connesse da reti a fibra ottica ad alta velocità con latenza di round trip inferiore a 2 millisecondi.

Nota

Non tutte le aree hanno zone di disponibilità.

Con la disponibilità elevata, i dati vengono duplicati per tutto il tempo in cui il database è in uso, offrendo una copia aggiornata dell'originale. Se si verifica un arresto anomalo, la replica può essere usata al posto dell'originale. La replica ha un server primario e un server di standby. Il server primario invia i file di log WAL al server di standby che riceve i file di log WAL.

Il server di standby fornisce al server primario informazioni quali l'ultimo log write-ahead scritto, l'ultima posizione di scaricamento, ecc. Per definire la frequenza minima per fare in modo che il ricevitore WAL restituisca un report, impostare il parametro wal_receiver_status_interval. Il parametro max_replication_slots definisce il numero massimo di slot di replica supportati dal server. Quando wal_level è impostato su REPLICA, max_replication_slots deve essere impostato almeno su uno, anche se l'intervallo di valori consentito è compreso tra e 0 e 262.143.

Il parametro max_wal_senders imposta il numero massimo di processi del mittente WAL.

I server primario e di standby vengono monitorati e vengono eseguite azioni appropriate per correggere i problemi, tra cui l'attivazione di un failover nel server di standby. Di seguito sono elencati gli stati di disponibilità elevata con ridondanza della zona:

• Inizializzazione: creazione di un nuovo server di standby in corso.
• Replica: la replica dei dati è in stato stabile ed è integra.
• Integro: il server di standby viene aggiornato dal server primario.
• Failover: viene effettuato il failover del server di database primario nel server di standby.
• Rimozione del server di standby: eliminazione del server di standby in corso.
• Non abilitata: la disponibilità elevata con ridondanza della zona non è abilitata.

È possibile aggiungere la disponibilità elevata per un server di database esistente. Se si abilita o si disabilita la disponibilità elevata in un server live, eseguire l'operazione in un momento di attività limitata.

Dal portale di Azure:

1. Passare al server di Database di Azure per PostgreSQL.
2. Nella sezione Panoramica selezionare la Configurazione corrente. Viene visualizzata la sezione Calcolo e archiviazione.
3. In Disponibilità elevata selezionare la casella di controllo Disponibilità elevata con ridondanza della zona per abilitare la disponibilità elevata. La disponibilità elevata non è supportata per il livello con possibilità di burst.

È importante notare che la disponibilità elevata è un'opzione di ripristino di emergenza. Non è possibile usare il server di standby per altri scopi, ad esempio consentire l'accesso ai database di sola lettura. È tuttavia possibile configurare la replica tra due server di Database di Azure per PostgreSQL usando un server di pubblicazione e un modello di sottoscrittore. Questa configurazione mantiene due server con i dati replicati tra di essi. Si avrà quindi accesso completo al server sottoscrittore e si potranno usare i database per qualsiasi scopo. Sarà possibile esercitarsi in questa configurazione nell'esercizio alla fine di questo modulo.

Decodifica logica

La decodifica logica usa anche i dati inviati al log write-ahead. Come suggerisce il nome, viene eseguita la decodifica delle voci nel log write-ahead per renderle comprensibili. Tutte le modifiche INSERT, UPDATE e DELETE sono disponibili per la decodifica logica.

La decodifica logica può essere usata per il controllo, l'analisi o qualsiasi altro motivo per cui si è interessati a individuare cosa è stato modificato e quando è stata eseguita la modifica.

La decodifica logica estrae le modifiche da tutte le tabelle del database. È diversa dalla replica poiché non può inviare le modifiche a un'altra istanza di PostgreSQL. Un'estensione PostgreSQL, invece, fornisce un plug-in per lo streaming delle modifiche.

La decodifica logica consente di decodificare il contenuto del log write-ahead in un formato facile da comprendere, che può essere interpretato senza conoscenza della struttura del database. Database di Azure per PostgreSQL supporta la decodifica logica usando l'estensione wal2json, installata nei server di Database di Azure per PostgreSQL.

Possono essere usate altre estensioni, ad esempio l'estensione pglogical che consente la replica di streaming logica.

Per usare la decodifica logica, in Parametri del server impostare:

• wal_level su LOGICAL
• max_replication_slots = 10
• max_wal_senders = 10

Il server deve essere riavviato dopo aver apportato queste modifiche.

Per usare l'estensione pglogical dal portale di Azure:

1. Passare al server di Database di Azure per PostgreSQL.
2. Selezionare Parametri del server e cercare shared_preload_libraries. Nella casella a discesa selezionare pglogical.
3. Cercare azure.extensions. Nella casella a discesa selezionare pglogical.
4. Per applicare le modifiche, riavviare il server.

È anche necessario concedere le autorizzazioni utente amministratore per la replica:

ALTER ROLE <adminname> WITH REPLICATION;

Per altre informazioni, vedere la documentazione online dell'estensione pglogical.

La decodifica logica genera modifiche ai dati sotto forma di flusso chiamato slot di replica logica.

1. Ogni slot ha un plug-in di output, che è possibile definire.
2. Ogni slot fornisce le modifiche di un solo database, ma un database può avere più slot.
3. Ogni modifica dei dati viene normalmente generata una volta per ogni slot.
4. Se PostgreSQL viene riavviato, uno slot può generare di nuovo modifiche, che il client dovrà gestire.
5. Gli slot devono essere monitorati. Gli slot non utilizzati conterranno tutti i file WAL per le modifiche non utilizzate. Questa situazione può comportare il completamento di una risorsa di archiviazione o il wraparound dell'ID delle transazioni.