2013-05-14 6 views
7

Si tratta in particolare di mantenere la sicurezza nell'utilizzo di varie soluzioni di replica che sarebbe possibile eseguire il failover sull'altro server senza perdita di dati. O in una situazione di master-master che potresti conoscere entro un ragionevole lasso di tempo se uno dei database non è più sincronizzato.verifica della coerenza dei dati tra due database postgresql

Esistono strumenti per questo oppure le persone generalmente dipendono dal sistema di replica stesso per avvisare di eventuali incoerenze? Attualmente sono più familiare con la distribuzione WAL postgresql in una configurazione master-standby, ma sto considerando una configurazione master-master con qualcosa come PgPool. Tuttavia, poiché tale soluzione è un po 'meno direttamente legata a PostgreSQL stesso (la mia comprensione di base è che fornisce la connessione che un'app userebbe, intercettando quindi le varie istruzioni SQL, e quindi invierà tali messaggi a qualunque server fosse nel suo pool) , mi ha fatto pensare di più sulla verifica effettiva della coerenza dei dati.

Requisiti specifici:

  1. non sto parlando di struttura solo tavolo. Vorrei sapere che i dati dei record effettivi sono gli stessi, in modo da sapere se i record sono corrotti o mancanti (nel qual caso, re-inizializzo il database non valido con un backup recente + i file WAL prima di riportarlo indietro nella piscina)

  2. I database sono nell'ordine di 30-50 GB. Dubito che le query SELECT RAW funzionino molto bene.

  3. Non vedo la necessità di un controllo in tempo reale (anche se, ovviamente, sarebbe bello). Ogni ora o anche ogni giorno sarebbe meglio di niente.

  4. Il controllo a livello di blocco non funzionava. Sarebbe due database con storage indipendente.

Oppure questo tipo di verifica semplicemente non è realistico?

+0

primo pensiero che viene in mente che è il database agnostico è quello di hash file su entrambi i lati e capire come confrontare gli hash per ogni riga db1 a DB2. Il caricamento iniziale di questo sarebbe lento, ma se lo facessi in modo incrementale andando avanti potrebbe non essere poi così male. – Kuberchaun

+0

Ecco un link di interesse per estendere il mio commento precedente. http: // StackOverflow.it/questions/9607063/checksum-field-in-postgresql-to-content-comparison – Kuberchaun

risposta

0

Se siete alla ricerca di tutto il tavolo si dovrebbe essere in grado di fare qualcosa del genere (assumendo un tavolo che si adatta abbastanza facilmente in RAM):

SELECT md5(array_to_string(array_agg(mytable), ' ')) 
    FROM mytable order by id; 

che vi darà un hash sulla rappresentazione tupla sui tavoli

Nota che è possibile suddividerlo in base all'intervallo, ecc. A seconda del tipo di replica, è possibile scomporlo per intervallo di pagine (per la replica dello streaming).

+0

Ovviamente l'ORDINE BY deve andare all'interno dell'array_agg(), altrimenti questa query non funzionerà affatto. – intgr

3

È possibile controllare le posizioni WAL corrente su entrambe le macchine ... Se essi rappresentano lo stesso valore, significa che il database sottostanti sono coerenti con l'altro ...

$ psql -c "SELECT pg_current_xlog_location()" -h192.168.0.10 (do it on primary host) 
pg_current_xlog_location 
-------------------------- 
0/2000000 
(1 row) 

$ psql -c "select pg_last_xlog_receive_location()" -h192.168.0.20 (do it on standby host) 
pg_last_xlog_receive_location 
------------------------------- 
0/2000000 
(1 row) 

$ psql -c "select pg_last_xlog_replay_location()" -h192.168.0.20 (do it on standby host) 
pg_last_xlog_replay_location 
------------------------------ 
0/2000000 
(1 row) 

è anche possibile controllare questo con l'aiuto di processi walsender e walreceiver:

[do it on primary] $ ps -ef | grep sender 
postgres 6879 6831 0 10:31 ?  00:00:00 postgres: wal sender process postgres 127.0.0.1(44663) streaming 0/2000000 

[ do it on standby] $ ps -ef | grep receiver 
postgres 6878 6872 1 10:31 ?  00:00:01 postgres: wal receiver process streaming 0/2000000