Aanbevolen procedures voor het bouwen van een toepassing met één server in Azure Database for PostgreSQL

VAN TOEPASSING OP: Azure Database for PostgreSQL - enkele server

Belangrijk

Azure Database for PostgreSQL - Enkele server bevindt zich op het buitengebruikstellingspad. We raden u ten zeerste aan om een upgrade uit te voeren naar Azure Database for PostgreSQL - Flexible Server. Zie Wat gebeurt er met Azure Database for PostgreSQL Enkele server voor meer informatie over migreren naar Azure Database for PostgreSQL - Flexible Server.

Hier volgen enkele aanbevolen procedures om u te helpen bij het bouwen van een toepassing die gereed is voor de cloud met behulp van Azure Database for PostgreSQL. Deze aanbevolen procedures kunnen de ontwikkeltijd voor uw app verminderen.

Configuratie van toepassings- en databasebronnen

De toepassing en database in dezelfde regio behouden

Zorg ervoor dat al uw afhankelijkheden zich in dezelfde regio bevinden bij het implementeren van uw toepassing in Azure. Het spreiden van exemplaren tussen regio's of beschikbaarheidszones zorgt voor netwerklatentie, wat van invloed kan zijn op de algehele prestaties van uw toepassing.

Uw PostgreSQL-server veilig houden

Configureer uw PostgreSQL-server zodanig dat deze veilig is en niet openbaar toegankelijk is. Gebruik een van deze opties om uw server te beveiligen:

• Firewall-regels
• Virtuele netwerken
• Azure Private Link

Voor beveiliging moet u altijd verbinding maken met uw PostgreSQL-server via SSL en uw PostgreSQL-server en uw toepassing configureren om TLS 1.2 te gebruiken. Zie SSL /TLS configureren.

Omgevingsvariabelen gebruiken voor verbindingsgegevens

Sla uw databasereferenties niet op in uw toepassingscode. Afhankelijk van de front-endtoepassing volgt u de richtlijnen voor het instellen van omgevingsvariabelen. Zie voor het gebruik van App Service hoe u app-instellingen en voor De Azure Kubernetes-service configureert, hoe u Kubernetes-geheimen gebruikt.

Prestaties en tolerantie

Hier volgen enkele hulpprogramma's en procedures die u kunt gebruiken om prestatieproblemen met uw toepassing op te sporen.

Verbinding maken ion Pooling gebruiken

Bij groepsgewijze verbindingen wordt een vaste set verbindingen tot stand gebracht tijdens het opstarten en onderhouden. Dit vermindert ook de geheugenfragmentatie op de server die wordt veroorzaakt door de dynamische nieuwe verbindingen die tot stand zijn gebracht op de databaseserver. De groepsgewijze verbinding kan aan de toepassingszijde worden geconfigureerd als het app-framework of het databasestuurprogramma dit ondersteunt. Als dat niet wordt ondersteund, is de andere aanbevolen optie om een proxyverbindingspoolerservice te gebruiken, zoals PgBouncer of Pgpool die buiten de toepassing wordt uitgevoerd en verbinding maakt met de databaseserver. PgBouncer en Pgpool zijn communityhulpprogramma's die werken met Azure Database for PostgreSQL.

Logica voor opnieuw proberen om tijdelijke fouten te verwerken

Uw toepassing kan tijdelijke fouten ondervinden waarbij verbindingen met de database af en toe verloren gaan. In dergelijke situaties is de server actief na een tot twee nieuwe pogingen in 5 tot 10 seconden. Een goede gewoonte is om vijf seconden te wachten voordat u het opnieuw probeert. Volg vervolgens elke nieuwe poging door de wachttijd geleidelijk te verhogen, tot 60 seconden. Beperk het maximum aantal nieuwe pogingen op welk punt de bewerking is mislukt door uw toepassing, zodat u deze vervolgens verder kunt onderzoeken. Zie Verbindingsproblemen oplossen voor meer informatie.

Leesreplicatie inschakelen om failovers te beperken

U kunt data-in-replicatie gebruiken voor failoverscenario's. Wanneer u leesreplica's gebruikt, vindt er geen geautomatiseerde failover plaats tussen bron- en replicaservers. U ziet een vertraging tussen de bron en de replica omdat de replicatie asynchroon is. Netwerkvertraging kan worden beïnvloed door veel factoren, zoals de grootte van de workload die wordt uitgevoerd op de bronserver en de latentie tussen datacenters. In de meeste gevallen varieert de replicavertraging van een paar seconden tot een paar minuten.

Database-implementatie

CI/CD-implementatiepijplijn configureren

Af en toe moet u wijzigingen in uw database implementeren. In dergelijke gevallen kunt u continue integratie (CI) gebruiken via GitHub Actions voor uw PostgreSQL-server om de database bij te werken door er een aangepast script voor uit te voeren.

Handmatig database-implementatieproces definiëren

Volg deze stappen tijdens handmatige database-implementatie om downtime te minimaliseren of het risico op mislukte implementatie te verminderen:

• Maak een kopie van een productiedatabase op een nieuwe database met behulp van pg_dump.
• Werk de nieuwe database bij met uw nieuwe schemawijzigingen of updates die nodig zijn voor uw database.
• Plaats de productiedatabase in de status Alleen-lezen. Schrijfbewerkingen in de productiedatabase moeten pas worden uitgevoerd nadat de implementatie is voltooid.
• Test uw toepassing met de zojuist bijgewerkte database uit stap 1.
• Implementeer uw toepassingswijzigingen en zorg ervoor dat de toepassing nu gebruikmaakt van de nieuwe database met de meest recente updates.
• Behoud de oude productiedatabase zodat u de wijzigingen kunt terugdraaien. U kunt vervolgens evalueren of u de oude productiedatabase verwijdert of indien nodig exporteert in Azure Storage.

Notitie

Als de toepassing lijkt op een e-commerce-app en u deze niet in de status Alleen-lezen kunt plaatsen, implementeert u de wijzigingen rechtstreeks in de productiedatabase nadat u een back-up hebt gemaakt. Deze wijzigingen moeten zich voordoen tijdens daluren met weinig verkeer naar de app om de impact te minimaliseren, omdat sommige gebruikers mogelijk mislukte aanvragen ondervinden. Zorg ervoor dat uw toepassingscode ook mislukte aanvragen verwerkt.

Databaseschema en query's

Hier volgen enkele tips om rekening mee te houden wanneer u uw databaseschema en uw query's bouwt.

BIGINT of UUID gebruiken voor primaire sleutels

Bij het bouwen van aangepaste toepassingen of sommige frameworks gebruiken INT ze misschien in plaats van BIGINT voor primaire sleutels. Wanneer u gebruikt INT, loopt u het risico dat de waarde in uw database de opslagcapaciteit van INT het gegevenstype kan overschrijden. Als u deze wijziging aanbrengt in een bestaande productietoepassing, kan dit tijdrovend zijn met meer ontwikkelingstijd. Een andere optie is om UUID te gebruiken voor primaire sleutels. Deze id gebruikt bijvoorbeeld a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11een automatisch gegenereerde 128-bits tekenreeks. Meer informatie over PostgreSQL-gegevenstypen.

Indexen gebruiken

Er zijn veel soorten indexen in Postgres die op verschillende manieren kunnen worden gebruikt. Door een index te gebruiken, kunnen specifieke rijen veel sneller worden gevonden en opgehaald dan zonder index. Maar indexen voegen ook overhead toe aan de databaseserver, dus vermijd te veel indexen.

Autovacuum gebruiken

U kunt uw server optimaliseren met autovacuum op een Azure Database for PostgreSQL-server. PostgreSQL staat meer gelijktijdigheid van databases toe, maar met elke update resulteert in invoegen en verwijderen. Voor verwijderen zijn de records zacht gemarkeerd die later worden verwijderd. PostgreSQL voert een vacuümtaak uit om deze taken uit te voeren. Als u niet van tijd tot tijd vacuümt, kunnen de dode tuples die zich opstapelen leiden tot:

• Gegevensbloat, zoals grotere databases en tabellen.
• Grotere suboptimale indexen.
• Verhoogde I/O.

Meer informatie over het optimaliseren met autovacuum.

Gebruik pg_stats_statements

Pg_stat_statements is een PostgreSQL-extensie die standaard is ingeschakeld in Azure Database for PostgreSQL. De extensie biedt een methode voor het bijhouden van uitvoeringsstatistieken voor alle SQL-instructies die door een server worden uitgevoerd. Zie hoe u pg_statement gebruikt.

Query Store gebruiken

De functie Query Store in Azure Database for PostgreSQL biedt een methode voor het bijhouden van querystatistieken. We raden deze functie aan als alternatief voor het gebruik van pg_stats_statements.

Bulkinvoegingen optimaliseren en tijdelijke gegevens gebruiken

Als u workloadbewerkingen hebt waarbij tijdelijke gegevens zijn betrokken of grote gegevenssets bulksgewijs worden ingevoegd, kunt u overwegen niet-vastgelegde tabellen te gebruiken. Het biedt standaard atomiciteit en duurzaamheid. Atomiciteit, consistentie, isolatie en duurzaamheid vormen de ACID-eigenschappen. Zie hoe u bulkinvoegingen optimaliseert.