PostgreSQL-gegevens repliceren naar externe sites

In een drukke databaseomgeving met grotere databases is de noodzaak van realtime gegevensreplicatie een veelvoorkomend verschijnsel. Voor toepassingen moeten de productiegegevens vaak in realtime worden gerepliceerd naar externe locaties voor analyses en andere kritieke bedrijfsactiviteiten.

DBA's moeten er ook voor zorgen dat de gegevens continu worden gerepliceerd naar de externe sites om aan verschillende vereisten te voldoen. Deze vereisten zijn echter niet altijd om de hele database te repliceren; het kan ook nodig zijn om slechts een subset van de gegevens te repliceren (zoals een tabel of een reeks tabellen of gegevens uit meerdere tabellen met behulp van een SQL voor analyse, rapportage enz.)

In deze blog zullen we ons concentreren op het in realtime repliceren van tabellen naar externe databases.

Wat is replicatie op tabelniveau?

Replicatie op tabelniveau is het mechanisme voor het repliceren van de gegevens van een specifieke tabel of reeks tabellen van de ene database (bron) naar een andere database (doel) die op afstand wordt gehost in een gedistribueerde omgeving. Replicatie op tabelniveau zorgt ervoor dat tabelgegevens continu worden gedistribueerd en consistent blijven over gerepliceerde (doel)sites.

Waarom replicatie op tabelniveau gebruiken?

Replicatie op tabelniveau is een essentiële behoefte in grotere, complexe, sterk gedistribueerde omgevingen. In mijn ervaring was het altijd nodig om een ​​set tabellen te repliceren van een productiedatabase naar een datawarehousing voor rapportagedoeleinden. De gegevens moeten continu worden gerepliceerd om ervoor te zorgen dat rapporten de nieuwste gegevens krijgen. In kritieke omgevingen kan veroudering van de gegevens niet worden getolereerd, dus de gegevenswijzigingen die tijdens de productie plaatsvinden, moeten onmiddellijk naar de doelsite worden gerepliceerd. Dit kan een echte uitdaging zijn voor DBA's die verschillende factoren moeten voorspellen om een ​​efficiënte en soepele tabelreplicatie te garanderen.

Laten we eens kijken naar enkele vereisten die replicatie op tabelniveau oplost:

• De rapporten kunnen worden uitgevoerd in een database in een andere omgeving dan productie, zoals datawarehousing
• Een gedistribueerde databaseomgeving met gedistribueerde applicaties die gegevens van meerdere sites halen. In het geval van gedistribueerde web- of mobiele applicaties, moet de kopie van dezelfde gegevens op meerdere locaties beschikbaar zijn om aan verschillende applicatiebehoeften te voldoen waarvoor replicatie op tabelniveau een goede oplossing zou kunnen zijn
• Payroll-applicaties die de gegevens van verschillende databases in verschillende geografisch verspreide datacenters of cloudinstanties nodig hebben om beschikbaar te zijn in een gecentraliseerde database

Verschillende factoren die van invloed zijn op replicatie op tabelniveau - waar u op moet letten

Zoals we hierboven vermeldden, moeten DBA's rekening houden met een verscheidenheid aan realtime componenten en factoren om een ​​effectief replicatiesysteem op tafelniveau te ontwerpen en te implementeren.

Tabelstructuur

Het type gegevenstabel dat geschikt is, heeft een grote invloed op de replicatieprestaties. Als de tabel plaats biedt aan een BYTEA-kolom met grotere binaire gegevens, kunnen de replicatieprestaties tegenvallen. De impact van replicatie op netwerk, CPU en schijf moet zorgvuldig worden beoordeeld.

Gegevensgrootte

Als de te migreren tabel te groot is, zou de initiële gegevensmigratie resources en tijd kosten. DBA's moeten ervoor zorgen dat de productiedatabase niet wordt beïnvloed.

Infrastructuurbronnen

De infrastructuur moet over voldoende middelen beschikken om ervoor te zorgen dat een betrouwbaar en stabiel presterend replicatiesysteem kan worden gebouwd. Met welke infrastructuurcomponenten moet rekening worden gehouden?

CPU's

Gegevensreplicatie is sterk afhankelijk van CPU's. Bij het repliceren vanuit productie mogen CPU's niet uitgeput raken, wat de productieprestaties kan beïnvloeden.

Netwerk

Het is van cruciaal belang voor de replicatieprestaties. Netwerklatentie tussen bron- en doeldatabase(s) moet worden beoordeeld door middel van stresstests om ervoor te zorgen dat er voldoende bandbreedte is om de replicatie sneller te laten verlopen. Hetzelfde netwerk kan ook worden gebruikt door andere processen of toepassingen. Dus capaciteitsplanning moet hier worden gedaan.

Geheugen

Er moet voldoende geheugen beschikbaar zijn om ervoor te zorgen dat er voldoende gegevens in de cache worden opgeslagen voor snellere replicatie.

Brontabelupdates

Als de gegevenswijzigingen in de brontabel zwaar zijn, moet het replicatiesysteem de wijzigingen zo snel mogelijk kunnen synchroniseren met de externe site(s). Replicatie zal uiteindelijk een groot aantal synchronisatieverzoeken naar de doeldatabase sturen, wat veel resources kan kosten.

Type infrastructuur (datacenters of cloud) kan ook van invloed zijn op de replicatieprestaties en kan uitdagingen opleveren. Het implementeren van monitoring kan ook een uitdaging zijn. Als er een vertraging is en bepaalde gegevens ontbreken in de doeldatabase, kan het moeilijk te controleren zijn en kan het niet synchroon zijn

Tabelreplicatie implementeren

Replicatie op tabelniveau in PostgreSQL kan worden geïmplementeerd met behulp van een verscheidenheid aan externe tools (commercieel of open-source) die op de markt beschikbaar zijn of door gebruik te maken van op maat gemaakte gegevensstromen.

Laten we eens kijken naar enkele van deze tools, hun kenmerken en mogelijkheden...

Slony

Slony is een van de meest populaire tools die wordt gebruikt om specifieke individuele tabellen in realtime asynchroon te repliceren van de ene PostgreSQL-database naar de andere. Dit is een op Perl gebaseerde tool die op triggers gebaseerde replicatie uitvoert van gegevenswijzigingen van een tabel (of een reeks tabellen) van een database op de ene site naar de andere. Het is redelijk betrouwbaar en heeft een jarenlange ontwikkelingsgeschiedenis. Hoewel het zeer betrouwbaar is, omdat het een op triggers gebaseerd hulpmiddel is, kan het complex worden om de replicatie-instellingen te beheren.

Laten we eens kijken naar enkele mogelijkheden van Slony...

Voordelen van het gebruik van Slony

• Ondersteunt master naar slave of meerdere slaves replicatiemethodologie die de horizontale leesschaalbaarheid helpt verbeteren. Met andere woorden, slaven zijn niet beschrijfbaar
• Het configureren van meerdere slaves op een enkele master is mogelijk en ondersteunt ook de trapsgewijze replicatiemethodologie
• Ondersteunt omschakelings- en failover-mechanismen
• Een groot aantal tabellen kan parallel in groepen worden gerepliceerd
• We kunnen repliceren tussen verschillende hoofdversies van PostgreSQL-instanties, wat Slony een geweldige optie maakt voor database-upgrades
• Eenvoudig te installeren

Nadelen van het gebruik van Slony

• Ondersteunt geen DDL-replicatie
• Bepaalde schemawijzigingen kunnen de replicatie verbreken
• Replicatiegebeurtenissen worden vastgelegd in de database in Slony-specifieke logtabellen die een onderhoudsoverhead kunnen veroorzaken.
• Als een groot aantal tabellen met grote datasets moet worden gerepliceerd, kunnen prestaties en onderhoud serieuze uitdagingen opleveren
• Omdat het een op triggers gebaseerde replicatie is, kunnen de prestaties worden beïnvloed

Bucardo

Bucardo is een ander open-source perl-gebaseerd replicatiesysteem voor PostgreSQL dat asynchrone replicatie van specifieke tabelgegevens tussen twee of meer PostgreSQL-instanties ondersteunt. Wat Bucardo anders maakt dan Slony, is dat het ook multi-master replicatie ondersteunt.

Laten we eens kijken naar verschillende soorten replicatiemechanismen die bucardo helpt implementeren...

• Replicatie met meerdere masters:tabellen kunnen in beide richtingen worden gerepliceerd tussen twee of meer PostgreSQL-instanties en de transactiegegevens worden bidirectioneel gesynchroniseerd
• Master-slave:de gegevens uit tabellen in master worden asynchroon naar slave gerepliceerd en slave is beschikbaar voor leesbewerkingen
• Volledige kopieermodus (Master-slave):Bucardo -/repliceer de volledige gegevens van de master naar de slave-node door alle gegevens van de slave te verwijderen

Voordelen van het gebruik van Bucardo

• Eenvoudig te installeren
• Ondersteunt multi-master, master-slave en volledige kopieerreplicatiemodi
• Het kan worden gebruikt om databases te upgraden
• Replicatie is mogelijk tussen verschillende PostgreSQL-versies

Nadelen van het gebruik van Bucardo

• Omdat het een op triggers gebaseerde replicatie is, kunnen de prestaties een uitdaging zijn
• De schemawijzigingen zoals DDL's kunnen de replicatie verbreken
• Het repliceren van een groot aantal tabellen kan leiden tot overhead voor onderhoud
• De infrastructuurbronnen moeten worden geoptimaliseerd voor goed presterende replicatie, anders kan de consistentie niet worden bereikt.

Logische PostgreSQL-replicatie

Logische replicatie is een revolutionaire ingebouwde functie van PostgreSQL die helpt bij het repliceren van individuele tabellen via WAL-records. Omdat het een op WAL gebaseerde replicatie is (vergelijkbaar met Streaming Replicatie), valt pg logisch op in vergelijking met andere tabelreplicatietools. Het repliceren van gegevens via WAL-records is altijd de meest betrouwbare en performante manier om gegevens op het netwerk te repliceren. Bijna alle tools op de markt bieden replicatie op basis van triggers, behalve logische replicatie.

Voordelen van het gebruik van logische postgreSQL-replicatie

• De beste optie als u een enkele tabel of een reeks tabellen wilt repliceren
• Het is een goede optie als het nodig is om specifieke tabellen van verschillende databases naar één enkele database te migreren (zoals datawarehousing of rapportagedatabases) voor rapportage- of analytische doeleinden
• Geen gedoe met triggers

Nadelen van het gebruik van logische postgreSQL-replicatie

• Onjuist beheer van WAL-bestanden / WAL-archiefbestanden kan een uitdaging vormen voor logische replicatie
• We kunnen geen tabellen repliceren zonder primaire of unieke sleutels
• DDL's en TRUNCATE worden niet gerepliceerd
• Replicatievertraging kan toenemen als de WAL's worden verwijderd. Dit betekent dat de replicatie en het WAL-beheer elkaar moeten aanvullen om ervoor te zorgen dat de replicatie niet kapot gaat
• Grote objecten kunnen niet worden gerepliceerd

Hier zijn nog enkele bronnen om u te helpen de logische postgresql-replicatie en de verschillen tussen deze en streamingreplicatie beter te begrijpen.

Buitenlandse gegevenswrappers

Hoewel Foreign Data Wrappers de gegevens niet echt repliceren, wilde ik deze functie van PostgreSQL benadrukken, omdat het DBA's kan helpen iets te bereiken dat lijkt op replicatie zonder de gegevens daadwerkelijk te repliceren. Dit betekent dat de gegevens niet van bron naar doel worden gerepliceerd en dat de gegevens toegankelijk zijn voor toepassingen uit de doeldatabase. De doeldatabase heeft alleen een tabelstructuur met een koppeling met host- en databasedetails van de brontabel en wanneer de toepassing de doeltabel opvraagt, worden de gegevens van de brondatabase naar de doeldatabase overgebracht, vergelijkbaar met databasekoppelingen. Als FDW's kunnen helpen, kunt u de overhead van het repliceren van de gegevens via het netwerk volledig vermijden. Vaak komen we in een situatie terecht waarin rapporten kunnen worden uitgevoerd op een externe doeldatabase zonder dat de gegevens fysiek aanwezig hoeven te zijn.

FDW's zijn een goede optie in de volgende situaties -

• Als je kleine en statische tabellen in de brondatabase hebt, is het niet echt de moeite waard om de gegevens te repliceren
• Kan echt nuttig zijn, als je echt grote tabellen in de brondatabase hebt en je geaggregeerde zoekopdrachten uitvoert op de doeldatabase.

Voordelen van het gebruik van buitenlandse datawrappers

• Het repliceren van gegevens kan volledig worden vermeden, wat tijd en middelen kan besparen
• Eenvoudig te implementeren
• Overgenomen gegevens zijn altijd de nieuwste
• Geen onderhoud boven het hoofd

Nadelen van het gebruik van buitenlandse gegevenswrappers

• Structurele wijzigingen in de brontabel kunnen van invloed zijn op de toepassingsfunctionaliteit op de doeldatabase
• Ze zijn sterk afhankelijk van het netwerk en kunnen aanzienlijke netwerkoverhead hebben, afhankelijk van het type rapporten dat wordt uitgevoerd
• Er wordt prestatieoverhead verwacht wanneer de query's een aantal keren worden uitgevoerd, aangezien elke keer dat de query wordt uitgevoerd, de gegevens vanuit de brondatabase over het netwerk moeten worden gehaald en ook prestatieoverhead op de brondatabase kunnen veroorzaken
• Elke belasting van de bron kan de prestaties van applicaties op de doeldatabase beïnvloeden

Conclusie

• Het repliceren van tabellen kan verschillende belangrijke zakelijke doelen dienen
• Kan gedistribueerde parallelle query's in gedistribueerde omgevingen ondersteunen
• Synchroon implementeren is bijna onmogelijk
• Infrastructuur moet adequaat worden uitgerust, wat kosten met zich meebrengt
• Een geweldige optie om een ​​geïntegreerde gecentraliseerde database te bouwen voor rapportage- en analytische doeleinden