Database

Concept

Bij Skryv wordt de MySQL-gebaseerde relationele database in de eerste plaats gebruikt door twee kerncomponenten: de Skryv backend en de Camunda process engine.

Skryv backend: configuratie, metadata, formulieren, communicaties, mijlpalen en alle andere dossier-gerelateerde informatie.
Camunda engine: procesgerelateerde state, timers en auditinformatie.

De database vormt daardoor een gedeelde, kritieke laag onder het platform. Wijzigingen aan het schema, de engineversie of de infrastructuur hebben dus rechtstreeks impact op zowel de uitvoering van processen als op de applicatielogica.

Via applicatie eigenschappen (omgevingsvariabelen) leggen we onder meer vast met welke database‑cluster de applicatie verbindt, welke engine‑versie en instance‑types gebruikt worden en hoe we tijdelijk maintenance‑modus of blue/green‑opstellingen activeren.

In principe kan je om het even welke databaseoplossing gebruiken zolang deze draait op MySQL 8.0-compatibele technologie. In deze documentatie gaan we uit van Amazon RDS Aurora.

Uitrollen en testen van databasemigraties

Bij het uitrollen van databasemigraties zonder of met minimale downtime staat één principe centraal: de applicatie en de database moeten tijdelijk compatibel zijn met zowel de oude als de nieuwe structuur. Een migratie is daardoor geen éénmalige “knip”, maar een reeks kleine, gecontroleerde stappen die je veilig kan uitvoeren en testen.

Een veelgebruikt patroon hierbij is het blue/green deployment‑model zoals onder meer ondersteund door Amazon Aurora Blue/Green Deployments.

In dat model start je vanuit de productieomgeving (“blue”).
Deze kopieer je naar een aparte, gesynchroniseerde stagingomgeving (“green”). In deze green‑omgeving voer je database‑updates en configuratiewijzigingen uit (bijvoorbeeld engine‑upgrades of schema‑aanpassingen), zonder impact op de live omgeving.
Zodra de nieuwe versie getest en stabiel is, wordt de green‑omgeving gepromoveerd tot de nieuwe productieomgeving.
De oude versie wordt uiteindelijk verwijderd.

De eigenlijke omschakeling blijft daardoor beperkt tot een zeer korte downtime (typisch minder dan een minuut), terwijl de bulk van het werk en de risico’s vooraf in een veilige omgeving zijn opgevangen.

Typische bouwstenen van zo’n aanpak zijn:

Voorbereidende migraties: je introduceert nieuwe kolommen, tabellen of indexen op een manier die de huidige applicatie niet breekt. De applicatie wordt stapsgewijs aangepast zodat ze met zowel de oude als de nieuwe structuur kan werken.
Geleidelijke omschakeling: de applicatie begint de nieuwe structuur te gebruiken, meestal eerst in de staging/green‑omgeving, waar je ook performantie‑ en regressietesten uitvoert op een productie‑nabije dataset.
Promotie en opruiming: na succesvolle testen wordt de green‑omgeving (of de nieuwe databaseversie) gepromoveerd tot productie en worden oude velden, tabellen en tijdelijke constructies opgeruimd. Dit gebeurt vaak in een latere, aparte migratiestap.
Rollback‑scenario’s: door het gebruik van een afzonderlijke staging/green‑omgeving en incrementele schemawijzigingen is er steeds een duidelijk pad terug naar de vorige situatie, bijvoorbeeld door het verkeer terug naar de oude (blue) omgeving te routeren.

Door migraties op te delen in kleine, omkeerbare stappen en ze eerst uit te voeren in een gesynchroniseerde staging‑ of green‑omgeving, wordt het mogelijk om databasemigraties uit te rollen met een zeer beperkte of zelfs nagenoeg afwezige downtime, ook in omgevingen met hoge beschikbaarheidseisen.

Migratie naar MySQL 8

Enkel van toepassing voor Skryv applicaties die nog op een MySQL 5.7 engine draaien.

Een migratie naar MySQL 8 start met een korte, gecontroleerde onderbreking van de applicatie. Eerst wordt de maintenance‑pagina geactiveerd en wordt de applicatie uitgezet door de app_desired_count op 0 te zetten. In deze toestand wordt een snapshot van de bestaande MySQL 5.7‑Aurora‑cluster genomen. Op basis van dat snapshot wordt via het aurora_database‑module een nieuwe, provisioned Aurora‑cluster aangemaakt met de laatste MySQL 5.7‑engine (migrate_to_provisioned_latest_mysql = true). Deze nieuwe cluster bestaat uit een writer‑ en een reader‑instance en vormt de basis voor de latere upgrade naar MySQL 8.

Vervolgens wordt de applicatie opnieuw opgestart (door app_desired_count terug te verhogen) en wordt de maintenance‑pagina uitgezet zodra de omgeving als gezond wordt beschouwd. Vanaf dan blijft de database in sync via replicatie terwijl een Aurora Blue/Green‑deployment wordt opgezet richting MySQL 8. In de green‑omgeving worden de wijzigingen gecontroleerd met een databaseclient en worden rooktesten uitgevoerd op de applicatie. Als alles er goed uitziet, wordt de blue/green‑deployment goedgekeurd, wat een korte onderbreking kan veroorzaken tijdens de fail‑over naar de MySQL 8‑database.

Na een succesvolle omschakeling kan de oude MySQL 5.7‑cluster definitief verwijderd worden. In Terraform wordt migrate_to_provisioned_latest_mysql weer uitgezet en enable_serverless_v2 geactiveerd, zodat de nieuwe Aurora‑cluster wordt omgezet naar serverless v2 (met uiteindelijk enkel een writer‑instance). Tijdens deze laatste stap wordt de maintenance‑pagina opnieuw tijdelijk geactiveerd. Mocht de omgeving na de upgrade toch onstabiel blijken, dan voorziet het proces in een duidelijk back‑outscenario: de maintenance‑queue opnieuw activeren, alle Terraform‑wijzigingen terugdraaien en een nieuwe database aanmaken op basis van het oorspronkelijke snapshot, waardoor de volledige omgeving terugkeert naar de toestand van vóór de migratie.

Eigenschappen

Eigenschap	Beschrijving
`spring.datasource.url` Voorbeeld: `jdbc:mysql://localhost/skryv`	Datasource url bevat volgende info: Protocol (bijv. `jdbc`) Driver (bijv. `mysql`) Host-naam of IP-adres van de MySQL-database (bijv. `localhost` of de hostname van je RDS/Aurora-instance) Optioneel poortnummer (bijv. `3306`) Naam database (bijv. `skryv`)
`spring.datasource.username` Voorbeeld: `root`	Gebruikersnaam, kan je rechtstreeks invullen, maar voor zeker voor acceptatie- of productieomgevingen komt hier een verwijzing (`valueFrom`) naar de AWS Secrets Manager.
`spring.datasource.password` Voorbeeld: `skryvdoc`	Paswoord, kan je rechtstreeks invullen, maar voor zeker voor acceptatie- of productieomgevingen komt hier een verwijzing (`valueFrom`) naar de AWS Secrets Manager.
`spring.jpa.hibernate.ddl-auto` Typische waarde: `none` of `validate`	Bepaalt hoe Hibernate met het databasemodel omgaat bij opstart. `none`: Hibernate voert geen schema‑wijzigingen uit; het schema wordt beheerd via migraties (aanbevolen voor test/acceptatie/productie). `validate`: Hibernate controleert of het bestaande schema overeenkomt met de entiteiten, maar wijzigt niets. Waarden als `update`, `create` of `create-drop` worden enkel aangeraden voor lokale ontwikkeling, niet voor omgevingen met echte data. Indien niet ingevuld: default per omgeving.
`spring.jpa.properties.hibernate.cache.use_second_level_cache` Waarde: boolean.	Indien `true`, dan schakel je een tweede cache level in, wat de reactietijden binnen de applicatie kan verbeteren.
`spring.jpa.show-sql` Waarde: boolean.	Indien `true`, logt Hibernate alle uitgevoerde SQL‑statements. Handig tijdens lokale ontwikkeling of debugging, maar in productie meestal uitgeschakeld omwille van performantie en logvolume.
`spring.jpa.hibernate.naming.physical-strategy`	Bepaalt hoe Java‑entiteit‑ en veldnamen worden vertaald naar tabel‑ en kolomnamen in de database (bijv. camelCase → snake_case). In de meeste Skryv‑implementaties wordt de Spring‑default gebruikt (waarde leeg laten). Enkel aanpassen als je een specifieke naamgevingsconventie of legacy‑schema moet ondersteunen.

Externe documentatie

Klik hier voor de officiële Amazon Aurora documentatie.
Meer info over Amazon Aurora Blue/Green deployments best practices.
Klik hier voor de officiële Oracle documentatie MySQL 8.0.