Questo articolo descrive come configurare, monitorare lo stato di salute e risolvere i problemi server TIE replica del database PostgreSQL.
Nota A partire dalla versione TIE Server 2.1.0, la convenzione di denominazione per le operazioni master/slave è stata modificata con principali/secondarie. Ovvero:
Master diventa principale
Slave diventa secondario
Le versioni precedenti del server TIE mantengono le designazioni master/slave originali.
Esaminare la configurazione del database di PostgreSQL primaria e secondaria server TIE corrente:
Il file di configurazione per server TIE la replica del database PostgreSQL è:
/data/tieserver_pg/postgresql.conf. Questo file contiene i parametri di configurazione della replica, ad esempio
wal_level,
archive_mode, archive_command, max_wal_senders, wal_keep_segments, e
hot_standby. Per informazioni su questi parametri di configurazione, consultare la documentazione ufficiale di PostgreSQL all'indirizzo:
http://www.postgresql.org/docs/9.3/static/runtime-config-wal.html.
McAfee consiglia di eseguire
non modificare la configurazione. Consente l'server TIE
PostgreSQL database per utilizzare la replica in streaming nativa in una configurazione primaria o secondaria. Le configurazioni primarie o secondarie potrebbero disporre di funzionalità di standby a caldo che consentono la scalabilità per le operazioni di lettura. È possibile sintonizzare i parametri di seguito, in base alle esigenze per risolvere ritardi insoliti:
- max_wal_senders: Da impostare nell'istanza primaria. Consente di specificare il numero massimo di connessioni contemporanee possibili dal server secondario al server principale. L'aumento di questo valore potrebbe velocizzare il processo di sincronizzazione. Non può essere impostato in un valore superiore a quello complessivo max_connections configurazione del parametro.
- wal_keep_segments: Da impostare nell'istanza primaria. Consente di specificare il numero minimo di segmenti di file di registro passati conservati nel pg_xlog Directory. L'aumento di questo valore contribuisce a impedire al server primario di rimuovere un segmento WAL ancora necessario per la modalità standby, nel qual caso la connessione di replica si chiude. Questa situazione è potenzialmente possibile quando l'architettura di Data Exchange Layer (DXL) presenta nodi con connettività lenta. Di conseguenza, il processo di replica PostgreSQL è lento.
Dopo aver modificato questi valori, è necessario eseguire ulteriori operazioni di monitoraggio e test per valutare l'impatto complessivo. I fattori oltre a ogni latenza di collegamento dell'ambiente includono:
- Il numero di broker
- Numero di endpoint
- La combinazione di file in esecuzione su ogni immagine dell'endpoint
Monitorare Replica server TIE database PostgreSQL:
Accedere come "super utente" ed eseguire il
replication-monitoring.sh script disponibile nella Home Directory. Lo script ha lo scopo di aiutare gli amministratori:
- Comprendere lo stato della replica in un server secondario.
- Per ripristinare il server secondario se il processo di replica non è riuscito, riconfigurarlo.
Utilizzare replication-monitoring.sh
Opzioni:
- -c – Comando da eseguire:
- monitor – Mostra le informazioni sullo stato di replica (vedere la sezione Tabella delle informazioni di monitoraggio per una spiegazione dei possibili campi di output).
- reset – Consente di riconfigurare il server secondario di replica.
- autoreset – Consente di riconfigurare il server secondario di replica quando il divario tra il server primario e il server secondario raggiunge una soglia (differenza di 1 megabyte per impostazione predefinita).
- -t – Soglia in byte per determinare quando il server secondario di replica viene riconfigurato. Per impostazione predefinita, questo valore è 1048576 byte (1 megabyte).
- --color – Includi colori nell'output. Semplifica la lettura dell'output.
- --help – Mostra guida.
Esempi
- replication-monitoring.sh -c monitor – Restituisce lo stato di replica del server secondario corrente.
- replication-monitoring.sh -c monitor --color – Restituisce lo stato di replica del server secondario corrente utilizzando i colori per semplificare la lettura.
- replication-monitoring.sh -c reset – Consente di riconfigurare il server secondario. Crea un nuovo backup del database dal server principale.
- replication-monitoring.sh -c autoreset -t 2097152 – Consente di riconfigurare il server secondario quando la replica del server secondario è inferiore alla differenza di 2 megabyte con il server principale. Questa convalida viene eseguita una sola volta quando viene eseguito il script. (Non imposta un trigger se la soglia viene raggiunta in futuro). Per convalidare nuovamente, è necessario eseguire nuovamente il comando.
Monitoraggio delle informazioni:
| Campo |
Descrizione |
| Replica in corso |
True se il server è impostato come server secondario e la replica è stata configurata correttamente. |
| La replica viene sospesa |
È possibile sospendere la replica. Restituisce true se la replica viene sospesa. |
| Ultimo indirizzo di ricezione di xLog |
Ultimo registro di replica ricevuto nel server secondario. I registri possono essere ricevuti, ma non ancora riprodotti. |
| Posizione xLog corrente nel server |
Registro di replica corrente nel server principale. Per ottenere questo valore, lo script esegue un query remoto al server principale. |
| Gap tra il server e la ricezione |
La differenza di byte tra il server principale e l'ultimo registro ricevuto sul server secondario. Aiuta a determinare come dietro il processo di replica è. |
| Ultima xLog percorso di riproduzione |
Ultimo registro di replica riprodotto nel server secondario. |
| Divario tra server e riproduzione |
La differenza di byte tra il server principale e il server secondario. È probabilmente il valore più importante per determinare lo stato di salute del processo di replica. |
| Ultima xLog tempo di riproduzione |
L'ora in cui l'ultimo registro è stato riprodotto nel server secondario.
Se nel server principale non è presente alcuna attività, l'attività di replica non si verifica nel server secondario e il valore rimane invariato. Il valore è lo stesso non significa che la replica non è riuscita. |
Inoltre, una nuova
Stato Salute viene aggiunta la sezione per riflettere lo stato di replica del database secondario. Per visualizzare lo stato di salute, visitare il sito
Menu, Server Settings, TIE Server Topology Management video.
Risoluzione dei problemi server TIE replica del database PostgreSQL:
Come si riconfigura la replica in un server secondario?
Eseguire il comando seguente:
/usr/sbin/replication-monitoring.sh -c reset
Come si verifica se la replica sta funzionando?
Eseguire il comando seguente:
/usr/sbin/replication-monitoring.sh -c monitor. Quindi, convalidare il valore di
Divario tra server e riproduzione è 0 byte o vicino a 0.
Che cosa significano le seguenti voci di registro?
- FATAL: Could not connect to the primary server: FATAL: No pg_hba.conf entry for replication connection from host "xx.xx.xx.xx", user "rep", SSL on
La configurazione dell'utente di replica è errata. Convalidare le autorizzazioni nel file /data/tieserver_pg/pg_hba.conf sul server principale. Deve essere presente una voce simile alla seguente:
hostssl replication rep xx.xx.xx.xx/xx cert clientcert=1 map=rep
In cui xx.xx.xx.xx/xx deve essere l'indirizzo IP e la maschera di maschere del server a cui si sta replicando il server principale.
Inoltre, nel file deve essere presente una voce simile a quella riportata di seguito. /data/tieserver_pg/pg_ident.conf:
rep xx.xx.xx.xx rep
In cui xx.xx.xx.xx deve essere l'indirizzo IP del server al quale si sta replicando il server principale.
- FATAL: Could not receive data from WAL stream:
Si sono verificati problemi di connettività tra il server secondario e il server primario.
- FATAL: Could not receive data from WAL stream: ERROR: Requested WAL segment xxxxxxxxxxxxxxxxxxxxxxxx has already been removed
Il server principale potrebbe aver rimosso un segmento WAL ancora necessario per il server secondario. Per risolvere il problema, eseguire il comando /usr/sbin/replication-monitoring.sh -c reset per riconfigurare il server secondario e iniziare con un nuovo backup.
