Replicatie en logische decodering beschrijven

Voltooid

Met de parameter wal_level kunt u definiëren hoeveel informatie naar het logboek moet worden geschreven. Er zijn twee opties: LOGISCH of REPLICA. REPLICA is de standaardinstelling. Deze parameter wordt ingesteld wanneer de server wordt gestart.

Hoge beschikbaarheid

Hoge beschikbaarheid is een Azure Database for PostgreSQL-service, die een stand-byserver biedt die gereed is om over te nemen als er een fout op uw liveserver is. Hoge beschikbaarheid in flexibele Azure Database for PostgreSQL-server maakt gebruik van replicatie om de stand-byserver automatisch bij te werken met gegevenswijzigingen.

Wanneer u hoge beschikbaarheid configureert voor flexibele Azure Database for PostgreSQL-server, wordt de primaire server in één beschikbaarheidszone geplaatst en wordt er een stand-byserver gemaakt in een andere beschikbaarheidszone. Gegevens worden gerepliceerd van de primaire server naar de stand-byserver met postgreSQL-streamingreplicatie in de synchrone modus.

Elke beschikbaarheidszone bestaat uit een of meer datacenters. Beschikbaarheidszones hebben hun eigen voedingen, koelsystemen, netwerkinfrastructuur, enzovoort, waardoor ze onafhankelijk van elkaar zijn. Drie kopieën van gegevensbestanden en WAL-bestanden (Write-Ahead Log) worden opgeslagen in lokaal redundante opslag binnen elke beschikbaarheidszone, waardoor fysieke isolatie tussen primaire en stand-byservers wordt geboden. Als de ene beschikbaarheidszone mislukt, werken de andere twee waarschijnlijk verder. Beschikbaarheidszones binnen een regio zijn verbonden met snelle fibre networks met een retourlatentie van minder dan 2 milliseconden.

Notitie

Niet alle regio's hebben beschikbaarheidszones.

Met hoge beschikbaarheid worden gegevens gedupliceerd telkens wanneer de database wordt gebruikt, wat een up-to-date kopie van het origineel biedt. Als er een crash is, kan de replica worden gebruikt in plaats van het origineel. Replicatie heeft een primaire server en een stand-byserver . De primaire server verzendt WAL-logboekbestanden naar de stand-byserver , die de WAL-logboekbestanden ontvangt.

De stand-byserver rapporteert terug aan de primaire server met informatie zoals het laatste write-ahead-logboek dat is geschreven, en de laatste positie die naar de schijf is leeggemaakt, enzovoort. Als u de minimale frequentie wilt definiëren voor de WAL-ontvanger om een rapport terug te sturen, stelt u de parameter wal_receiver_status_interval in. De parameter max_replication_slots definieert het maximum aantal replicatiesites dat door de server kan worden ondersteund. Wanneer wal_level is ingesteld op REPLICA, moet max_replication_slots ten minste één zijn, maar het toegestane waardebereik ligt tussen 0 en 262.143.

Met de parameter max_wal_senders wordt het maximum aantal WAL-afzenderprocessen ingesteld.

De primaire en stand-byservers worden bewaakt en de juiste acties worden ondernomen om problemen op te lossen, waaronder het activeren van een failover naar de stand-byserver. Hier volgt een overzicht van de zone-redundante statussen voor hoge beschikbaarheid:

• Initialiseren : tijdens het maken van een nieuwe stand-byserver.
• Repliceren : gegevensreplicatie heeft een stabiele status en is in orde.
• In orde : de stand-by wordt bijgewerkt door de primaire.
• Failover: de primaire databaseserver is bezig met failover naar de stand-by.
• Stand-by verwijderen : tijdens het verwijderen van de stand-byserver.
• Niet ingeschakeld : zone-redundante hoge beschikbaarheid is niet ingeschakeld.

U kunt hoge beschikbaarheid toevoegen voor een bestaande databaseserver. Als u hoge beschikbaarheid op een liveserver inschakelt of uitschakelt, voert u de bewerking uit wanneer er weinig activiteit is.

Vanuit de Azure-portal:

1. Navigeer naar uw Azure Database for PostgreSQL-server.
2. Selecteer uw huidige configuratie in de sectie Overzicht. De sectie Compute + Storage wordt weergegeven.
3. Schakel onder Hoge beschikbaarheid het selectievakje Hoge beschikbaarheid (zone-redundant) in om hoge beschikbaarheid in te schakelen. Hoge beschikbaarheid wordt niet ondersteund voor burstable-laag.

Het is belangrijk om te weten dat hoge beschikbaarheid een optie voor herstel na noodgevallen is. U kunt de stand-byserver niet gebruiken voor andere doeleinden, zoals het toestaan van toegang tot alleen-lezen databases. U kunt echter replicatie tussen twee Azure Database for PostgreSQL-servers configureren met behulp van een uitgevers- en abonneemodel. Deze configuratie onderhoudt twee servers met gegevens die ertussen worden gerepliceerd. Vervolgens hebt u volledige toegang tot de abonneeserver en kunt u de databases voor elk doel gebruiken. U oefent deze configuratie in de oefening aan het einde van deze module.

Logische decodering

Logische decodering maakt ook gebruik van gegevens die naar het write-ahead-logboek worden verzonden. Zoals de naam al aangeeft, worden de vermeldingen in het schrijflogboek gedecodeert om ze begrijpelijk te maken. Alle wijzigingen INSERT, UPDATE en DELETE zijn beschikbaar voor logische decodering.

Logische decodering kan worden gebruikt voor controle, analyse of een andere reden waarom u wilt weten wat er is gewijzigd en wanneer deze is gewijzigd.

Met logische decodering worden wijzigingen uit alle tabellen in de database geëxtraheerd. Het verschilt van replicatie omdat deze wijzigingen niet naar een andere PostgreSQL-instantie kunnen worden verzonden. In plaats daarvan biedt een PostgreSQL-extensie een uitvoerinvoegtoepassing om de wijzigingen te streamen.

Met logische decodering kan de inhoud van het write-ahead-logboek worden gedecodeerd in een eenvoudig te begrijpen indeling, die kan worden geïnterpreteerd zonder kennis van de databasestructuur. Azure Database for PostgreSQL ondersteunt logische decodering met behulp van de wal2json-extensie , die is geïnstalleerd op Azure Database for Postgres-servers.

Andere extensies kunnen worden gebruikt, zoals de pglogical-extensie, waarmee logische streamingreplicatie mogelijk is.

Als u logische decodering wilt gebruiken, stelt u in Serverparameters het volgende in:

• wal_level naar LOGISCH
• max_replication_slots = 10
• max_wal_senders = 10

De server moet opnieuw worden opgestart nadat deze wijzigingen zijn aangebracht.

De pglogical-extensie gebruiken vanuit Azure Portal:

1. Navigeer naar uw Azure Database for PostgreSQL-server.
2. Selecteer Serverparameters en zoek naar shared_preload_libraries. Selecteer pglogical in de vervolgkeuzelijst.
3. Zoek naar azure.extensions. Selecteer pglogical in de vervolgkeuzelijst.
4. Als u de wijzigingen wilt toepassen, start u de server opnieuw op.

U moet de beheerdersgebruikersmachtigingen ook verlenen voor replicatie:

ALTER ROLE <adminname> WITH REPLICATION;

Raadpleeg de documentatie over pglogical extension online voor meer informatie.

Met logische decodering worden gegevenswijzigingen uitgevoerd als een stroom die een logische replicatiesite wordt genoemd.

1. Elke site heeft één uitvoerinvoegtoepassing die u kunt definiëren.
2. Elke site biedt wijzigingen van slechts één database, maar een database kan meerdere sites hebben.
3. Elke gegevenswijziging wordt normaal gesproken eenmaal per site verzonden.
4. Als PostgreSQL opnieuw wordt opgestart, kan een site wijzigingen die de client moet verwerken, opnieuw verzenden.
5. Sleuven moeten worden bewaakt. Niet-verwerkte sleuven houden alle WAL-bestanden voor die niet-verwerkte wijzigingen vast. Deze situatie kan leiden tot een volledige opslag- of transactie-id-wraparound.