Vraag PostgreSQL-replicatie


We slaan dit constant rond op kantoor, en de vraag blijft maar komen. Hoe ga je om met PostgreSQL-replicatie? Ik praat niet noodzakelijkerwijs over geavanceerde clusters, maar houd het eenvoudig met Master-Slave, Master-MultiSlave en Master-Master. Ik vind dat het opzetten van MySQL meestal vrij eenvoudig is. Failover is eenvoudig, zo niet perfect, vooral voor hoe eenvoudig het is om te configureren. We hebben met Slony gespeeld, maar het is een beetje te hands-on (schemawijzigingen vereisen interventie, nieuwe databases vereisen interventie, enz.). PGPool2 was best aardig, totdat een knooppunt naar beneden ging en we geen sierlijke manier konden vinden (anders dan alles naar beneden halen en het gevallen knooppunt opnieuw in te zaaien) om de replicatie weer synchroon te krijgen. In principe is dit waar ik meestal naar op zoek ben:

  • Eenvoudige installatie (ik neem genoegen met moeilijke instellingen, maar kan gemakkelijk worden uitgebreid)
  • Simplistische failover
  • Het terugbrengen van een gevallen knooppunt vereist slechts tijd (d.w.z. zoals mysql. Server gaat naar beneden, u brengt het omhoog en wacht tot replicatie inhaalt)
  • Schema-wijzigingen breken de replicatie niet
  • Het toevoegen van een nieuwe database aan de server is naadloos (dat wil zeggen als mysql, je kunt een hele DB-server repliceren, dus een nieuwe database wordt aangemaakt op de master, deze wordt automatisch doorgegeven aan de slave)

MySQL handelt de meeste hiervan redelijk goed af, maar ik heb een zekere voorliefde voor PostgreSQL. Bovendien hebben we een aantal situaties waarin dit onze enige optie is en we willen replicatie toevoegen aan de mix. Wat gebruikt u momenteel en wat vindt u van uw oplossing? Dit is geen MySQL versus PostgreSQL-bericht, dat beloof ik, want dat is niet wat ik probeer te starten. :)


45
2018-05-22 06:22


oorsprong


Ik ben geïnteresseerd in het antwoord hierop. Uitgaande van een MySQL-achtergrond zijn de replicatie-opties voor PSQL op zijn minst agrarisch. - Dave Cheney
Ja, tot nu toe heeft elke optie waarmee ik heb gespeeld belangrijke nadelen gehad. Ik hoop dat ik iets voor de hand lig, maar dat geloof ik niet - f4nt
Ik vermoed dat er niets anders is, maar ik wil graag dat iemand me ongelijk heeft - Vinko Vrsalovic
Trouwens, heb je pgsql-general@postgresql.org geprobeerd? - Vinko Vrsalovic


antwoorden:


Kort antwoord - er is nog geen oplossing voor PostgreSQL als u online readonly slaves nodig heeft.

Er zijn momenteel twee belangrijke ontwikkelingsprojecten op dit gebied die zijn opgenomen in PostgreSQL 9.0 (lente / zomer 2010), namelijk:

  • Synchrone replicatie:

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

  • Alleen hete standby-slaves lezen:

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

die in combinatie gericht zijn op het gebruiksgemak van replicatie in MySQL-stijl min de bugs / problemen die MySQL heeft plus de betrouwbaarheid die gebruikers van PostgreSQL kennen.

Dit alles werd opgestart door een manifest van het PostgreSQL Core Team in 2008:

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

De PostgreSQL-replicatieoplossingen tot op de dag van vandaag met het grootste gebruikersbestand zijn Slony-I (duurder voor schrijven, schemawijzigingen lastig maken), WAL verzending / walmgr (Slaves kunnen niet online worden gebruikt) en pgQ / londiste van Skype / Skytools ( meer tools / bouwstenen dan een voltooide oplossing).

Ik heb een paar dingen geschreven over Log Shipping, walmgr en Slony-I, zie

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 voor meer informatie.


9
2018-05-29 15:47



Synchronous Replication + Hot Standby zijn nu beschikbaar - zie wiki.postgresql.org/wiki/... voor een goede samenvatting van de beschikbare technieken - David Fraser


En om een ​​andere oplossing in de ring te gooien: rubyrep.

Om te vergelijken met uw vereisten:

  • Eenvoudige installatie
    Ja, dat is eigenlijk de primaire focus van rubyrep.
  • Simplistische failover
    Ja. Rubyrep doet in feite replicatie van master-master - om te falen is helemaal geen actie nodig. Gebruik gewoon de andere database.
  • Schema-wijzigingen breken de replicatie niet
    Ja.
    Voor niet-primaire sleutelwijzigingen hoeft replicatie niet eens te stoppen (maar zorg ervoor dat het schema aan beide zijden tegelijkertijd wordt gewijzigd)
    Om tabellen toe te voegen / te verwijderen, start u gewoon de replicatie-daemon opnieuw. Alleen het wijzigen van de kolom met primaire sleutels van een tabel kost wat moeite.
  • Het toevoegen van een nieuwe database aan de server is naadloos (dat wil zeggen als mysql, je kunt een hele DB-server repliceren, dus een nieuwe database wordt aangemaakt op de master, deze wordt automatisch doorgegeven aan de slave)
    Dit wordt slechts in beperkte mate ondersteund: elke rubyrep-setup repliceert slechts één database tegelijk. (Maar het is heel eenvoudig om replicatie in te stellen voor meer dan één database.)

5
2017-07-01 06:41





Je hebt niet gezegd dat je een warme read-slave als vereiste hebt, dus ik zal voorstellen om Heartbeat te gebruiken met gedeelde opslag of DRBD. Het doet gewoon het juiste en administratie is een eitje. Het is het Linux-equivalent van oudere Microsoft SQL Server-clustering. Eén knooppunt is actief en het andere knooppunt is passief, terwijl de gegevens tussen beide worden gedeeld. U hoeft zich geen zorgen te maken over op SQL gebaseerde replicatie, omdat dit allemaal op lager niveau wordt afgehandeld.

Serieus, het is verreweg de beste oplossing als je geen gelezen slaven nodig hebt. De WAL-archieven waren op zijn zachtst gezegd slecht en je moet alles opnieuw instellen als je het verzendproces voor een herstart van de server verstoort. slony en londiste snijden de mosterd niet. Als je in de hoofdbron wilt blijven en niet commercieel wilt gaan, is Heartbeat je beste keuze.


4
2018-05-27 18:02





Uit uw vereisten lijkt het dat PITR de gemakkelijkste manier is om uw probleem op te lossen:

Online backup en point-in-time herstel (PITR)

Je hebt niet gezegd dat je naar de slaveserver moet vragen, dus PITR kan precies goed zijn.

Het is standaard onderdeel van PostgreSQL vanaf versie 8.0, dus je hebt waarschijnlijk al alles wat je nodig hebt om het in gebruik te nemen.

Als u instructies vindt die te uitgebreid zijn, neem dan een kijkje SkyTools WalMgr wat het proces van het creëren / failover tot hot-standby data enkele opdracht taak zal maken.

Voor complexere replicatiescenario's had ik goede ervaring met Slony-1, maar PostgreSQL heeft veel goede replicatie / HA-opties beschikbaar.


2
2018-05-22 13:25



en die opties zijn ...? - Dave Cheney
... vermeld in blogpost blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html waarnaar wordt verwezen in een van de antwoorden ... - dpavlin


Als je asynchrone master / slave-replicatie wilt, overweeg dan Londiste (onderdeel van het skytools-pakket van Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Het is eenvoudig te installeren, het toevoegen van een nieuwe DB is eenvoudig, replicatie gewoon "inhalen".

Failover is echter nog niet ingebouwd. U moet de verbindingssnaren van uw toepassing wijzigen of de DB-verbinding achter een andere softwarelaag verdoezelen.

Sommige schemawijzigingen zijn eenvoudig. Anderen zijn moeilijker. Het hangt van uw toepassing af. De volgende versie van skytools (versie 3.0) zou moeten werken met DDL en faciliteiten bevatten om failover gemakkelijker te maken.

We zijn verhuisd naar Londiste nadat we Slony te pijnlijk vonden om te gebruiken.


2
2018-05-27 17:53





Zie hier een discussie, misschien kan dat helpen:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

en

Deelnemers aan Bucardo Version One, lager op de pagina gevonden:

http://www.planetpostgresql.org/


1
2018-05-22 09:09





Er zijn echt geen gratis / open-source manieren om te bieden wat je zoekt. Als u iets wilt dat turn-key is, kijkt u naar verschillende commerciële replicatieoplossingen van derden.

Nu het is mogelijk om uw eigen replicatie te sorteren met Postgres met behulp van het schrijven van een Write-Head-log (WAL):

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

Dit is eigenlijk waar u een secundair knooppunt in de continue herstelmodus kunt plaatsen en elke {kleininterval} transactielogboeken erin kunt invoegen. De Postgres-configuratie heeft "stubs" waarmee je bepaalde dingen kunt doen als een Postgres wanneer een WAL is voltooid en dus nee, en daar is die setup op gebaseerd - gebruikmakend van die "stubs."

Dit staat u echter niet toe om master-master en / of circulaire replicatie te doen.

In elk geval werkt het zeker voor erdundantie, maar ik zou het niet "eenvoudige installatie", "simplistische failover", "naadloos" of iets dergelijks noemen.


1
2018-05-27 10:10



dit antwoord komt overeen met de suggestie van PITR, aangezien PITR WAL gebruikt :-) - dpavlin


Met uitzondering van het toevoegen van een nieuwe database, kunt u Mammoth Replicator (https://projects.commandprompt.com/public/replicator). Het is open-source, eenvoudig in te stellen en ondersteunt failover. De belangrijkste beperkingen zijn een enkele database en het niet kunnen repliceren van DDL-wijzigingen, beide staan ​​in de TODO-lijst.


1
2018-05-29 18:18