Instructie annuleren vanwege conflict met herstel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Dit artikel helpt u bij het oplossen van een probleem dat optreedt tijdens het uitvoeren van query's op leesreplica.

Symptomen

1. Wanneer u probeert een query uit te voeren op een leesreplica, wordt de query onverwacht beëindigd.
2. Foutberichten zoals 'Instructie annuleren vanwege conflict met herstel' worden weergegeven in de logboeken of in de query-uitvoer.
3. Er is mogelijk een merkbare vertraging of vertraging in de replicatie van de primaire naar de leesreplica.

In de opgegeven schermopname is aan de linkerkant het primaire exemplaar van de flexibele Azure Database for PostgreSQL-server en aan de rechterkant de leesreplica.

• Replicaconsole lezen (rechterkant van de bovenstaande schermopname)
  • We kunnen een lange SELECT instructie bekijken die wordt uitgevoerd. Een essentieel aspect dat u moet weten over SQL, is de consistente weergave van de gegevens. Wanneer een SQL-instructie wordt uitgevoerd, wordt de weergave van de gegevens in feite geblokkeerd. Tijdens de uitvoering ziet de SQL-instructie altijd een consistente momentopname van de gegevens, zelfs als er gelijktijdig wijzigingen optreden.
• Primaire console (linkerzijde van de bovenstaande schermopname)
  • Er is een UPDATE bewerking uitgevoerd. Hoewel een UPDATE zelfstandig niet noodzakelijkerwijs het gedrag van de leesreplica verstoort, doet de volgende bewerking dat wel. Na de update wordt een VACUUM bewerking (in dit geval handmatig geactiveerd voor demonstratiedoeleinden, maar het is belangrijk dat een autovacuumproces ook automatisch kan worden gestart) wordt uitgevoerd.
  • De VACUUMrol van deze functie is om ruimte vrij te maken door oude versies van rijen te verwijderen. Gezien het feit dat de leesreplica een lange SELECT instructie uitvoert, heeft deze momenteel toegang tot een aantal van deze rijen die VACUUM zijn bedoeld voor verwijdering.
  • Deze wijzigingen die zijn geïnitieerd door de VACUUM bewerking, waaronder het verwijderen van rijen, worden aangemeld bij het Write-Ahead-logboek (WAL). Omdat leesreplica's van flexibele Azure Database for PostgreSQL-servers gebruikmaken van systeemeigen fysieke PostgreSQL-replicatie, worden deze wijzigingen later naar de leesreplica verzonden.
  • Hier ligt de crux van het probleem: de VACUUM bewerking, niet bekend met de doorlopende SELECT instructie op de leesreplica, verwijdert rijen die de leesreplica nog steeds nodig heeft. Dit scenario resulteert in een replicatieconflict.

De nasleep van dit scenario is dat de leesreplica een replicatieconflict ondervindt vanwege de rijen die door de VACUUM bewerking zijn verwijderd. Standaard probeert de leesreplica dit conflict voor een duur van 30 seconden op te lossen, omdat de standaardwaarde max_standby_streaming_delay is ingesteld op 30 seconden. Als het conflict na deze duur onopgeloste blijft, wordt de query op de leesreplica geannuleerd.

Oorzaak

De hoofdoorzaak van dit probleem is dat de leesreplica in Azure Database for PostgreSQL flexibele server een continu herstelsysteem is. Dit betekent dat terwijl de replica de primaire replica inhaalt, het in wezen een status van constant herstel heeft. Als een query op een leesreplica probeert een rij te lezen die tegelijkertijd wordt bijgewerkt door het herstelproces (omdat de primaire server een wijziging heeft aangebracht), kan de query door Azure Database for PostgreSQL flexibele server worden geannuleerd, zodat het herstel zonder onderbreking kan worden voortgezet.

Oplossing

1. Aanpassen max_standby_streaming_delay: Verhoog de max_standby_streaming_delay parameter op de leesreplica. Door de waarde van de instelling te verhogen, kan de replica meer tijd hebben om conflicten op te lossen voordat wordt besloten een query te annuleren. Dit kan echter ook de vertraging van de replicatie verhogen, dus het is een compromis. Deze parameter is dynamisch, wat betekent dat wijzigingen van kracht worden zonder dat een server opnieuw hoeft te worden opgestart.
2. Query's bewaken en optimaliseren: controleer de typen en frequenties van query's die worden uitgevoerd op de leesreplica. Langlopende of complexe query's zijn mogelijk gevoeliger voor conflicten. Het optimaliseren of plannen van ze kan helpen.
3. Off-Peak Query Execution: Overweeg zware of langlopende query's uit te voeren tijdens daluren om de kans op een conflict te verminderen.
4. Inschakelen hot_standby_feedback: Overweeg de instelling hot_standby_feedback voor on de leesreplica. Wanneer deze functie is ingeschakeld, wordt de primaire server geïnformeerd over de query's die momenteel door de replica worden uitgevoerd. Hiermee voorkomt u dat de primaire rijen die nog nodig zijn voor de replica, verwijderen, waardoor de kans op een replicatieconflict wordt verminderd. Deze parameter is dynamisch, wat betekent dat wijzigingen van kracht worden zonder dat een server opnieuw hoeft te worden opgestart.

Let op

Het inschakelen hot_standby_feedback kan leiden tot de volgende mogelijke problemen:

• Deze instelling kan enkele noodzakelijke opschoningsbewerkingen op de primaire manier voorkomen, wat mogelijk leidt tot tabelbloat (verhoogd schijfruimtegebruik vanwege niet-lege oude rijversies).
• Regelmatige bewaking van de schijfruimte en tabelgrootten van de primaire server is essentieel. Meer informatie over bewaking voor flexibele Azure Database for PostgreSQL-server vindt u hier.
• Wees voorbereid om potentiële tabelbloat handmatig te beheren als deze problematisch wordt. Overweeg om automatischevacuumafstemming in te schakelen in azure Database for PostgreSQL flexibele server om dit probleem te verhelpen.

5. Aanpassen max_standby_archive_delay: De max_standby_archive_delay serverparameter geeft de maximale vertraging op die de server toestaat bij het lezen van gearchiveerde WAL gegevens. Als de replica van het flexibele serverexemplaren van Azure Database for PostgreSQL ooit overschakelt van de streamingmodus naar bestandsgebaseerde logboekverzending (hoewel zeldzaam), kan het aanpassen van deze waarde helpen bij het oplossen van het annuleringsprobleem van de query.