Amazon SOA-C02: Databases en Caching — Studiegids

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Onderdeel van de AWS SysOps Administrator Associate SOA-C02 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Database parameter groups, schalen en monitoring

Parameter groups beheren engine-specifieke instellingen (bijv. max_connections, innodb_buffer_pool_size). RDS gebruikt DB parameter groups voor instances en DB cluster parameter groups voor Aurora. Wijzigingen in sommige parameters vereisen een herstart (apply pending-reboot), andere worden onmiddellijk toegepast.

Beheerpatronen:

Parameter group aanmaken en wijzigen: aws rds create-db-parameter-group –db-parameter-group-name pg1 –db-parameter-group-family mysql8.0 –description “custom”; vervolgens aws rds modify-db-parameter-group –db-parameter-group-name pg1 –parameters “ParameterName=max_connections,ParameterValue=500,ApplyMethod=immediate”
Instance class schalen: aws rds modify-db-instance –db-instance-identifier mydb –db-instance-class db.r5.large –apply-immediately (of tijdens een onderhoudsvenster om een herstart te vermijden).
Storage autoscaling: inschakelen voor ondersteunde engine types; Aurora schaalt storage automatisch.

Monitoring- en schalingssignalen:

Gebruik CloudWatch (FreeableMemory, CPUUtilization, DatabaseConnections, WriteLatency, ReadLatency, DiskQueueDepth) en Performance Insights voor trage SQL en ’top waits'.
Schakel Enhanced Monitoring in en stel de granulariteit in (bijv. 1s voor troubleshooting).
Gebruik RDS Proxy om connection pooling te beheren en ‘connection storms’ te verminderen voor serverless of zeer concurrente applicaties.

Backup/restore-procedures en migratieoverwegingen

Backups en restores moeten expliciet en getest worden. Geautomatiseerde backups bieden PITR binnen de retentieperiode; handmatige snapshots worden bewaard totdat ze worden verwijderd en kunnen worden gekopieerd naar andere regio’s en naar andere KMS-sleutels. Wees expliciet over de regio en timestamp bij het restoren.

Veelvoorkomende restore-commando’s:

Herstellen naar een specifiek tijdstip (RDS): aws rds restore-db-instance-to-point-in-time –source-db-instance-identifier mydb –target-db-instance-identifier mydb-restore –use-latest-restorable-time / of specificeer –restore-time
Snapshot herstellen (cross-region): kopieer eerst de db-snapshot naar de doelregio en herstel dan.

Migratieoverwegingen:

AWS DMS voor migraties met minimale downtime (heterogeen/homogeen). DMS ondersteunt doorlopende replicatie; zorg voor correcte instellingen van de bron-engine (binlog ingeschakeld voor MySQL).
Logische migratie (mysqldump, pg_dump) voor eenvoudige exports; fysiek herstel van een snapshot voor grote datasets.
Valideer tekensets, verschillen in parameter groups en KMS-sleutels voor versleutelde snapshots.

Veelvoorkomende valkuilen en beslissingscriteria

Backups herstellen naar de verkeerde regio of het verkeerde tijdstip: verifieer altijd –region en –restore-time vóór het herstellen; gebruik een gekopieerde snapshot in de doelregio en test restores in een staging-omgeving.
Aannemen dat read replicas hoge beschikbaarheid bieden: onthoud dat replica’s asynchroon zijn; gebruik Multi-AZ of Aurora voor schrijf-HA en synchrone replicatie.
Cache-invalidatie over het hoofd zien: ontwerp TTL’s, versiesleutels of event-driven invalidatie; vermijd het uitsluitend vertrouwen op korte TTL’s voor correctheid.
Geautomatiseerde backups of retentie niet correct inschakelen: stel backup-retention-period >0 in en valideer PITR met test-restores; zorg ervoor dat KMS-sleutels beschikbaar zijn in de doelregio voor het kopiëren van snapshots.
Parameter groups wijzigen zonder herstart: controleer de ApplyMethod; plan herstarts in onderhoudsvensters voor parameters die een herstart vereisen om onverwachte downtime te voorkomen.
Schalen zonder verbindingsbeheer: het verhogen van de instance class zonder RDS Proxy of connection pooling lost ‘connection storms’ mogelijk niet op; implementeer pooling om veel kortstondige verbindingen te beheren.

Praktijkprobleem: Use-Case Scenario

Acme Retail heeft een MySQL RDS primary met veel leesverkeer en af en toe pieken door analyses; ze ervaren replica lag tijdens de nachtelijke ETL en zien hoge ‘connection churn’ die CPU-pieken veroorzaakt.

Schakel een extra read replica-groep in voor analyses, geïsoleerd van de applicatie-readers, en plaats deze in een andere AZ of regio voor DR.
Configureer replica-monitoring (ReplicaLag metric) en voeg autoscaling-logica toe om readers toe te voegen wanneer de lag of ReadLatency drempelwaarden overschrijdt.
Implementeer RDS Proxy voor de applicatie om verbindingen te multiplexen en ‘connection churn’ te verminderen; stem max_connections in de parameter group hierop af.
Verplaats analyse-jobs naar de analytics-replica en pas cache-aside caching toe via ElastiCache Redis met geschikte TTL’s om herhaalde query’s te verminderen.
Test failover- en restore-procedures: voer een PITR-restore uit op een staging-instance en valideer de stappen voor replica-promotie.

Deze aanpak scheidt de lees-workloads, vermindert de verbindingsdruk op de primary en gebruikt caching om het leesvolume van de DB te verlagen. Het volgt de best practices van AWS door het combineren van leesschaling, connection pooling en geteste backup/restore-processen om de beschikbaarheid en operationele veerkracht te behouden.

← Compute en Auto Scaling · Alle domeinen · Serverless en Applicatie-integratie →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →