La produzione di replica PostgreSQL è pronta?

Come si confronta la replica nativa PostgreSQL con MySQL?

So che la replica asincrona è stata supportata più a lungo della sincronizzazione, che è recente. Il sincrono è affidabile per essere utilizzato in progetti reali?

La produzione è pronta?

Sì, è pronto per la produzione e ampiamente utilizzato. I follower di Heroku si basano, ad esempio, sulla replica asincrona integrata di PostgreSQL, così come lo sono gli stand AWS RDS e le repliche di lettura. La replica in streaming viene utilizzata quasi universalmente con PostgreSQL.

L'installazione della replica non è esattamente adorabile, ma strumenti come repmgr aiutano in qualche modo con questo, e stanno migliorando lentamente con ogni versione principale. La capacità di pg_basebackup di acquisire una copia del sistema utilizzando la replica in streaming (e farlo da un altro standby) è di grande aiuto.

In generale, una funzione semplicemente non verrà rilasciata in PostgreSQL fino a quando non sarà pronta per la produzione. I bug si verificano, come in qualsiasi software, ma in genere vengono corretti poco dopo essere stati identificati. Le nuove funzionalità davvero importanti a volte presentano bug e problemi rilevati dopo la versione .0, ma in tal caso risolverli è una priorità elevata; i bug non vengono lasciati in giro.

Non sono a conoscenza di seri problemi con la replica in streaming - sincronizzazione o asincronizzazione - né ho visto alcun report per un bel po '. Erano meno stabili del solito standard di Pg nelle versioni .0 delle versioni principali in cui erano state introdotte, ma entrambe maturarono rapidamente e furono completamente pronte per la produzione.

(Aggiornamento: c'era un bug specifico nella nuova versione 9.3 precedente alla 9.3.4 che in alcuni casi causava problemi di replica; gli utenti di 9.3 dovrebbero aggiornare immediatamente a 9.3.4. Le versioni precedenti non sono interessate.)

L'unica avvertenza che voglio menzionare è un dettaglio minore con replica sincrona: se esegui il commit sul master, annulla la query dopo il commit mentre attende la conferma della replica, viene trattata come commit sul master anche prima che venga replicata. Si ottiene lo stesso effetto riavviando il master in attesa della risposta della replica. In pratica questa è un'irrilevanza, ma riguarda l'unico problema a cui riesco a pensare.

Confronta con MySQL?

La replica nativa di Pg è molto diversa da quella di MySQL.

MySQL utilizza la replica logica in cui invia le modifiche logiche apportate ai dati della tabella, alla struttura della tabella, ecc. E la replica applica tali modifiche.

La replica di PostgreSQL è di livello inferiore (in 9.5 e sotto; le versioni future potrebbero anche aggiungere una replica logica). Invia i blocchi che sono stati modificati nelle tabelle. È più semplice, più facile da ottenere e impone un carico inferiore sul server di replica, ma consuma più larghezza di banda di rete e richiede più spazio di archiviazione sul master per contenere le modifiche non ancora replicate. È meglio configurato per utilizzare la replica di streaming con fallback di archiviazione WAL, rendendo la configurazione più complessa di quella di MySQL. Replica le modifiche di basso livello come l'attività VACUUM, non solo le modifiche di tupla, mantenendo lo stato su disco della replica uguale a quello del master. Non è in grado di replicare solo un database; l'intero sistema deve essere replicato, il che può essere frustrante se si dispone di un database grande, elevato e poco importante e di un database piccolo, economico e vitale.

Tutto sommato, dipende da cosa vuoi farci.

Considero la replica di PostgreSQL decisamente migliore per le repliche utilizzate per il backup, l'alta disponibilità e il ripristino di emergenza. In particolare, se combinato con il recupero temporizzato (PITR) .

D'altra parte, non è buono per le repliche dei report di sola lettura perché la necessità di ritardare l'applicazione dei dati replicati durante l'esecuzione di transazioni lunghe significa che è necessario lasciar annullare le query in esecuzione molto lunghe o rimanere notevolmente indietro rispetto al master, consumando più spazio su disco sul master e costringendolo a lavorare di più per tenere il passo.

Sono in corso lavori per abilitare la replica logica in PostgreSQL , dove vengono replicate le modifiche logiche alla struttura della tabella, al contenuto della tabella, ecc., Anziché al loro stato su disco. La progettazione e il supporto del catalogo Pg per tutto ciò che è definito dall'utente rende questo compito piuttosto complesso. Alcune delle basi sono state messe in atto per 9.4, ma è improbabile che la replica logica completa sia utilizzabile prima della 9.6 o successive.