Replica PostgreSQL


45

Lo facciamo costantemente in giro per l'ufficio e la domanda continua a sorgere. Come gestisci la replica PostgreSQL? Non sto nemmeno necessariamente parlando di cluster avanzati, ma sto semplicemente diventando semplice con Master-Slave, Master-MultiSlave e Master-Master. Trovo che configurarlo per MySQL sia in genere piuttosto semplice. Il failover è semplice se non perfetto, soprattutto per quanto sia facile da configurare. Abbiamo giocato con Slony, ma è un po 'troppo pratico (le modifiche allo schema richiedono un intervento, i nuovi database richiedono un intervento, ecc.). PGPool2 è stato piuttosto carino, fino a quando un nodo non è andato inattivo e non siamo riusciti a trovare un modo grazioso (oltre a far cadere tutto e a ridimensionare il nodo caduto) per riportare la replica in sincronia. Fondamentalmente ecco cosa sto cercando in genere:

  • Configurazione semplice (mi accontenterò di una configurazione difficile, ma facile da espandere)
  • Failover semplicistico
  • Il ripristino di un nodo caduto richiede solo tempo (ad esempio, come mysql. Il server si arresta, lo si attiva e si attende che la replica raggiunga)
  • Le modifiche allo schema non interrompono la replica
  • L'aggiunta di un nuovo database al server è perfetta (ad esempio, come mysql, è possibile replicare un intero server DB, quindi un nuovo database viene creato sul master, si propaga automaticamente allo slave)

MySQL gestisce la maggior parte di questi abbastanza bene, ma ho una certa predilezione per PostgreSQL. Inoltre, abbiamo alcune situazioni in cui è la nostra unica opzione e vorremmo aggiungere la replica al mix. Cosa stai usando attualmente e come ti senti sulla tua soluzione? Questo non è un post MySQL contro PostgreSQL, lo prometto, perché non è quello che sto cercando di iniziare. :)


3
Sono interessato alla risposta a questo. Provenienti da un background MySQL, le opzioni di replica per PSQL sono a dir poco agricole.
Dave Cheney,

Sì, finora ogni opzione con cui ho giocato ha avuto degli svantaggi significativi. Spero che mi manchi qualcosa di ovvio ... ma non credo di
esserlo

Ho il sospetto che non ci sia nient'altro, ma non vedo l'ora che qualcuno mi dimostri di sbagliare
Vinko Vrsalovic,

A proposito, hai provato pgsql-general@postgresql.org?
Vinko Vrsalovic,

Risposte:


9

Risposta breve: per PostgreSQL non esiste ancora una soluzione del genere se hai bisogno di slave online di sola lettura.

Ci sono due grandi progetti di sviluppo attualmente in corso in quest'area che sono inclusi in PostgreSQL 9.0 (Primavera / Estate 2010), vale a dire:

  • Replica sincrona:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

  • Sola lettura degli slave hot standby:

http://wiki.postgresql.org/wiki/Hot_Standby

che in combinazione mirano a raggiungere la facilità d'uso della replica in stile MySQL meno i bug / problemi che MySQL ha più l'affidabilità che gli utenti conoscono da PostgreSQL.

Tutto questo è stato avviato da un manifest del team centrale PostgreSQL nel 2008:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Le soluzioni di replica PostgreSQL fino ad oggi con la più ampia base di utenti sono Slony-I (più costoso per le scritture, apporta modifiche allo schema), WAL shipping / walmgr (gli slave non possono essere usati online) e pgQ / londiste da Skype / Skytools ( più strumenti / elementi costitutivi di una soluzione finita).

Ho scritto alcune cose su Log Shipping, walmgr e Slony-I, vedi

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 per ulteriori informazioni.


6
La replica sincrona + Hot Standby sono ora disponibili - vedi wiki.postgresql.org/wiki/… per un buon riassunto delle tecniche disponibili
David Fraser

5

E gettare un'altra soluzione sul ring: rubyrep.

Per confrontare con le tue esigenze:

  • Configurazione semplice
    Sì, questo è in realtà l'obiettivo principale di rubyrep.
  • Failover semplicistico
    Sì. In realtà rubyrep esegue la replica master-master - per eseguire il failover, non è necessaria alcuna azione. Inizia a usare l'altro database.
  • Le modifiche allo schema non interrompono la replica
    Sì.
    Per le modifiche delle chiavi non primarie, la replica non deve nemmeno arrestarsi (ma assicurarsi che lo schema sia modifiche su entrambi i lati contemporaneamente)
    Per aggiungere / rimuovere tabelle, è sufficiente riavviare il daemon di replica. Solo cambiare la colonna chiave primaria di una tabella richiede un po 'di sforzo.
  • L'aggiunta di un nuovo database al server è perfetta (ad esempio, come mysql, è possibile replicare un intero server DB, quindi un nuovo database viene creato sul master, si propaga automaticamente allo slave)
    Questo è supportato solo in modo limitato: ogni rubyrep il programma di installazione replica solo un database alla volta. (Ma è molto facile impostare la replica per più di un database.)

4

Non hai menzionato la necessità di avere uno slave di lettura caldo come requisito, quindi proporrò di utilizzare Heartbeat con memoria condivisa o DRBD. Fa solo la cosa giusta e l'amministrazione è un gioco da ragazzi. È l'equivalente Linux del clustering Microsoft SQL Server precedente. Un nodo è attivo e l'altro nodo è passivo mentre i dati sono condivisi tra i due. Non devi preoccuparti della replica basata su SQL perché è tutto gestito più in basso a livello di blocco.

Seriamente, è di gran lunga la soluzione migliore se non hai bisogno di leggere gli schiavi. La roba dell'archivio WAL era nella migliore delle ipotesi e devi reimpostare tutto se mai interrompi il processo di spedizione per un riavvio del server. slony e londiste non tagliano la senape. Se vuoi rimanere sull'albero principale e non fare pubblicità, Heartbeat è la soluzione migliore.


2

Dalle tue esigenze sembra che PITR sia il modo più semplice per risolvere il tuo problema:

Backup on-line e ripristino point-in-time (PITR)

Non hai detto che devi interrogare il server slave, quindi PITR potrebbe essere giusto.

Fa parte di PostgreSQL standard dalla versione 8.0, quindi probabilmente hai già tutto il necessario per metterlo in funzione.

Se trovi istruzioni troppo dettagliate, dai un'occhiata a WalToolgr di SkyTools che eseguirà il processo di creazione / failover su dati di comando a caldo singolo task.

Per scenari di replica più complessi, ho avuto una buona esperienza con Slony-1, ma PostgreSQL ha molte buone opzioni di replica / HA disponibili.


e quelle opzioni sono ...?
Dave Cheney,

... elencati nel post sul blog blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html a cui si fa riferimento in una delle risposte ...
dpavlin,

2

Se si desidera una replica asincrona di master / slave, considerare Londiste (parte del pacchetto skytools da Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

È facile da installare, l'aggiunta di un nuovo DB è semplice, la replica "raggiunge".

Tuttavia, il failover non è integrato. Sarà necessario modificare le stringhe di connessione dell'applicazione o offuscare la connessione DB dietro un altro livello di software.

Alcune modifiche allo schema sono facili. Altri sono più difficili. Dipende dalla tua applicazione. La prossima versione di skytools (versione 3.0) dovrebbe gestire DDL e includere funzionalità per facilitare il failover.

Ci siamo trasferiti a Londiste dopo aver trovato Slony troppo doloroso da usare.



1

Non ci sono davvero modi gratuiti / open-source per fornire ciò che stai cercando. Se vuoi qualcosa di così chiavi in ​​mano, guarda varie soluzioni di replica commerciale di terze parti.

Ora è possibile eseguire il rollup della propria replica con Postgres utilizzando la spedizione di log testina di scrittura (WAL):

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

In pratica è qui che puoi mettere un nodo secondario in modalità di recupero continuo e importare i registri delle transazioni ogni {piccolo intervallo}. La configurazione di Postgres ha "stub" per permetterti di fare certe cose quando un Postgres quando un WAL è completato e quindi no, e questo è ciò su cui si basa questa configurazione - usando quegli "stub".

Tuttavia, ciò non consente di eseguire master-master e / o repliche circolari.

In ogni caso, funziona sicuramente per erdundancy, ma non lo definirei "installazione semplice", "failover semplicistico", "senza soluzione di continuità" o qualcosa del genere.


questa risposta è duplicata del suggerimento PITR, poiché PITR utilizza WAL :-)
dpavlin,



Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.