In questo post del blog, ci immergiamo nei dettagli dell'impostazione di Streaming Replication (SR) in PostgreSQL. La replica in streaming è l'elemento fondamentale per ottenere un'elevata disponibilità nel tuo hosting PostgreSQL e viene prodotta eseguendo una configurazione master-slave.

Terminologia Master-Slave

Server principale/primario

• Il server che può accettare scritture.
• Chiamato anche server di lettura/scrittura.

Server Slave/Standby

• Un server in cui i dati vengono mantenuti costantemente sincronizzati con il master.
• Chiamato anche server di backup o replica.
• Un server warm standby è un server a cui non è possibile connettersi finché non viene promosso a server master.
• Al contrario, un server hot standby può accettare connessioni e fornire query di sola lettura. Per il resto di questa discussione, ci concentreremo solo sui server hot standby.

I dati vengono scritti sul server master e propagati ai server slave. In caso di problemi con il server master esistente, uno dei server slave subentrerà e continuerà a ricevere scritture garantendo la disponibilità del sistema.

Replica basata sulla spedizione WAL

Cos'è WAL?

• WAL è l'acronimo di Write-Ahead Logging.
• Si tratta di un file di registro in cui tutte le modifiche al database vengono scritte prima di essere applicate/scritte ai file di dati.
• WAL viene utilizzato per il ripristino dopo un arresto anomalo del database, garantendo l'integrità dei dati.
• WAL viene utilizzato nei sistemi di database per ottenere atomicità e durabilità.

Come viene utilizzato WAL per la replica?

I record di registro write-ahead vengono utilizzati per mantenere i dati sincronizzati tra i server di database. Ciò si ottiene in due modi:

Spedizione log basata su file

• I file di registro WAL vengono inviati dal master ai server di standby per mantenere i dati sincronizzati.
• Il master può copiare direttamente i registri nella memoria del server di standby o può condividere la memoria con i server di standby.
• Un file di registro WAL può contenere fino a 16 MB di dati.
• Il file WAL viene spedito solo dopo aver raggiunto tale soglia.
• Ciò causerà un ritardo nella replica e aumenterà anche le possibilità di perdere dati se il master si arresta in modo anomalo e i registri non vengono archiviati

Record WAL in streaming

• I blocchi di record WAL vengono trasmessi in streaming dai server di database per mantenere i dati sincronizzati.
• Il server di standby si connette al master per ricevere i blocchi WAL.
• I record WAL vengono trasmessi in streaming man mano che vengono generati.
• Lo streaming dei record WAL non deve attendere il completamento del file WAL.
• Ciò consente a un server di standby di rimanere più aggiornato di quanto sia possibile con il log shipping basato su file.
• Per impostazione predefinita, la replica in streaming è asincrona anche se supporta anche la replica sincrona.

Entrambi i metodi hanno i loro pro e contro. L'utilizzo della spedizione basata su file consente il ripristino point-in-time e l'archiviazione continua, mentre lo streaming garantisce la disponibilità immediata dei dati sui server in standby. Tuttavia, puoi configurare PostgreSQL per utilizzare entrambi i metodi contemporaneamente e goderti i vantaggi. In questo blog, ci concentriamo principalmente sulla replica in streaming per ottenere l'elevata disponibilità di PostgreSQL.

Come configurare la replica in streaming?

Impostare la replica in streaming in PostgreSQL è molto semplice. Supponendo che PostgreSQL sia già installato su tutti i server, puoi seguire questi passaggi per iniziare:

Configurazione su Master Node

• Inizializza il database sul nodo master usando l'utilità initdb.
• Crea un ruolo/utente con privilegi di replica eseguendo il comando seguente. Dopo aver eseguito il comando, puoi verificarlo eseguendo \du per elencarli su psql.
  •   CREA UTENTE REPLICAZIONE ACCESSO PASSWORD CRIPTATA '';
• Configura le proprietà relative alla replica in streaming nel file di configurazione principale di PostgreSQL (postgresql.conf):
  

  # I valori possibili sono replica|minimal|logical wal_level =replica# richiesta per la funzionalità pg_rewind quando lo standby non è sincronizzato con il master wal_log_hints =on# imposta il numero massimo di connessioni simultanee dai server di standby. max_wal_senders =3 # Il parametro seguente viene utilizzato per indicare al master di mantenere il numero minimo di # segmenti di registri WAL in modo che non vengano eliminati prima che lo standby li consumi. # ogni segmento è 16 MB wal_keep_segments =8 # Il parametro seguente abilita la connessione di sola lettura sul nodo quando è in # ruolo standby. Questo viene ignorato quando il server è in esecuzione come master. hot_standby =il

• Aggiungi la voce di replica nel file pg_hba.conf per consentire le connessioni di replica tra i server:
  

  # Consenti connessioni di replica da localhost, # da un utente con il privilegio di replica. # TYPE    DATABASE    USER    INDIRIZZO    METODO host    replica    repl_user    IPaddress(CIDR)    md5

• Riavvia il servizio PostgreSQL sul nodo master per rendere effettive le modifiche.

Configurazione su nodo/i standby/i

• Crea il backup di base del nodo master utilizzando l'utilità pg_basebackup e utilizzalo come punto di partenza per lo standby.
  

  # Spiegazione di alcune opzioni utilizzate per l'utilità pg_basebackup # L'opzione -X viene utilizzata per includere i file di registro delle transazioni (file WAL) richiesti nel backup #. Quando specifichi lo stream, verrà aperta una seconda connessione al server # e inizierà lo streaming del registro delle transazioni contemporaneamente all'esecuzione del backup. # -c è l'opzione del checkpoint. Impostandolo su veloce, il checkpoint sarà # creato a breve. # -W forza pg_basebackup a richiedere una password prima di connettersi # a un database. pg_basebackup -D  -h -X stream -c veloce -U repl_user -W

• Crea il file di configurazione della replica se non presente (viene creato automaticamente se l'opzione -R è fornita in pg_basebackup):
  

  # Specifica se avviare il server come una attesa. Nella replica in streaming, # questo parametro deve essere attivato. modalità_attesa ='on'# Specifica una stringa di connessione utilizzata per la connessione del server di standby # con il server primario/master. primary_conninfo =‘host= port= user= password= application_name=”host_name”’# Specifica il ripristino su una sequenza temporale particolare. L'impostazione predefinita prevede il ripristino lungo la # stessa sequenza temporale corrente al momento dell'esecuzione del backup di base. # L'impostazione dell'ultima opzione ripristina l'ultima sequenza temporale trovata # nell'archivio, che è utile in un server in standby. recovery_target_timeline ='ultimo'

• Avvia lo standby.

La configurazione in standby deve essere eseguita su tutti i server in standby. Una volta completata la configurazione e avviato uno standby, si connetterà al master e avvierà lo streaming dei registri. Questo imposterà la replica e può essere verificato eseguendo l'istruzione SQL "SELECT * FROM pg_stat_replication; “.

Per impostazione predefinita, la replica in streaming è asincrona. Se desideri renderlo sincrono, puoi configurarlo utilizzando i seguenti parametri:

Synchronous_commit deve essere attivato per la replica sincrona e questa è l'impostazione predefinita. PostgreSQL fornisce opzioni molto flessibili per il commit sincrono e può essere configurato a livello di utente/database. I valori validi sono i seguenti:

• Disattiva – Il commit della transazione viene riconosciuto al client anche prima che il record della transazione venga effettivamente scaricato nel file di registro WAL su quel nodo.
• Locale –  Il commit della transazione viene riconosciuto al cliente solo dopo che il record della transazione è stato scaricato nel file di registro WAL su quel nodo.
• Scrittura_remota – Il commit della transazione viene riconosciuto al client solo dopo che i server specificati da synchronous_standby_names confermano che il record della transazione è stato scritto nella cache del disco, ma non necessariamente dopo essere stato scaricato nel file di registro WAL.
• Attivo – Il commit della transazione viene riconosciuto al client solo dopo che i server specificati da synchronous_standby_names confermano che il record della transazione è stato scaricato nel file di registro WAL.
• Applica_remoto – Il commit della transazione viene riconosciuto al client solo dopo che i server specificati da synchronous_standby_names confermano che il record della transazione è stato scaricato nel file di registro WAL e applicato al database.

L'impostazione di synchronous_commit su off o local in modalità di replica sincrona lo farà funzionare come asincrono e può aiutarti a ottenere prestazioni di scrittura migliori. Tuttavia, ciò comporterà un rischio maggiore di perdita di dati e ritardi di lettura sui server in standby. Se impostato su remote_apply, garantirà la disponibilità immediata dei dati sui server in standby, ma le prestazioni di scrittura potrebbero peggiorare poiché dovrebbe essere applicato a tutti/menzionati server in standby.

Puoi abilitare la modalità di archiviazione se prevedi di utilizzare l'archiviazione continua e il ripristino point-in-time. Sebbene non sia obbligatorio per la replica in streaming, l'abilitazione della modalità di archiviazione offre vantaggi aggiuntivi. Se la modalità di archiviazione non è attiva, dobbiamo utilizzare gli slot di replica funzionalità o assicurati che wal_keep_segments il valore è impostato sufficientemente alto in base al carico.

Fai riferimento a questa eccellente presentazione per approfondire i dettagli dell'elevata disponibilità in PostgreSQL. Nel nostro prossimo post sul blog, ti presenteremo il mondo degli strumenti utilizzati per gestire l'alta disponibilità per PostgreSQL utilizzando la replica in streaming.