Amazon Aurora als zeer goed beschikbare gegevensbron gebruiken in Connext: Yenlo’s WSO2 Cloud-oplossing
In Connext, de WSO2 Cloudoplossing van Yenlo, wordt de Amazon Aurora service gebruikt voor als gegevensbron van de WSO2 producten. Amazon Aurora biedt een database met eindpunten die een hoge beschikbaarheid hebben. Out of the box zitten er twee specifieke eindpunten bij voor toegang tot de database: een clustereindpunt waarmee lees-/schrijftoegang verkregen wordt en een alleen-lezen eindpunt.
Dit houdt in dat je geen failover in je applicatie hoeft te configureren, omdat het clustereindpunt dit automatisch voor je oplost met de schrijftoegang op de database.
Om de databasetoegang te configureren in de WSO2-producten wordt de JDBC mysql driver samen met connection pooling gebruikt. De connection pool zal ervoor zorgen dat als de applicatie een database een verbinding nodig heeft, deze beschikbaar en werkend is.
<datasource>
<name>WSO2_USERSTORE_DB</name>
<jndiConfig>
<name>jdbc/WSO2UM_DB</name>
</jndiConfig>
<definition type="RDBMS">
<configuration>
<url>jdbc:mysql://rds-cluster.endpoint:3306/database?autoReconnect=true</url>
<username>mysqluser</username>
<password>mysqlpassword</password>
<driverClassName>com.mysql.jdbc.Driver</driverClassName>
<maxActive>30</maxActive>
<maxWait>60000</maxWait>
<testOnBorrow>true</testOnBorrow>
<validationQuery>SELECT 1</validationQuery>
<validationInterval>30000</validationInterval>
<defaultAutoCommit>false</defaultAutoCommit>
</configuration>
</definition>
</datasource>
De bovenstaande configuratie is een voorbeeld voor een JDBC userstore in een WSO2-product. Het dient puur als ter voorbeeld en kan daarom niet één-op-één gebruikt worden voor productiesystemen, omdat het onder andere slechts een tekstueel wachtwoord heeft.
Wat we hier geconfigureerd zien, is dat de connection pool een controle uitvoert voordat hij de service zijn gang laat gaan, door om de testOnBorrow instelling te vragen. Wanneer het de verbinding test, zal het de validationQuery uitvoeren en die hoort standaard “SELECT 1” te zijn en zal werken alleen als de verbinding tot stand komt.
Failover
Als Amazon Aurora geforceerd wordt om een failover uit te voeren bij het falen van een node, dan zal het een reader node promoveren tot master node en zal het de read_only instelling verwijderen. De eerdere master node wordt vervolgens opnieuw opgestart in read_only modus en als dat lukt zal die opnieuw beschikbaar zijn, maar dan is deze node niet meer te gebruiken om schrijfoperaties mee uit te voeren en kan er dus alleen leestoegang mee verkregen worden.
Als de connection pool niet bewust is van deze onderliggende oplossing van Amazon Aurora, zal er geen melding van een failover ontvangen worden. Op het moment dat de failover dus plaatsvindt en de node opnieuw gestart wordt in de read_only modus, zal de connection pool een verbinding krijgen met de read node en het valideren als een werkende verbinding. De validatie wordt correct uitgevoerd, maar op het moment dat de applicatie deze verbinding probeert te gebruiken zal het onvermijdelijk tegen database errors aanlopen en beweren dat database in read_only modus staat.
De connection pool zal niet in staat zijn om deze verbindingen te herstellen en dus zal het product opnieuw opgestart moeten worden om de dingen recht te zetten.
Oplossingen
Het gebruik van de maxAge parameter
Het is mogelijk om een maximale levensduur voor een verbinding in de connection pool in te stellen. Hierdoor worden verbindingen die ouder zijn dan de ingestelde levensduur uit de pool gegooid als ze door de applicatie vrijgegeven worden. Zo kun je verzekeren dat de applicatie de Amazon Aurora failover herkent wanneer de (nu defecte) verbindingen in de pool verlopen zijn.
Het gebruik van enhanced validationQuery
Amazon Aurora geeft zelf een specifieke parameterwaarde in een query om aan te geven dat een node read_only is, namelijk de “innodb_read_only”. In andere failoveroplossingen zou deze parameter “read_only” genoemd kunnen worden. Een tweede oplossing, om het probleem met failovers op te lossen, is het instellen van een validerende query die zal falen als deze een read_only host tegenkomt. Door van de bovenstaande eigenschap gebruik te maken, kan een case statement beoordeeld worden als ‘exception’ als het op een read_only host stuit en zal de connection pool de verbinding als defect beschouwen en deze verwijderen.
Eén manier om dit te bereiken is door de query meer dan 1 rij terug laten geven, omdat dit niet verwacht wordt door de validationQuery. Door bijvoorbeeld een ‘select from’ query te gebruiken op één van de default MySQL tabellen, waarvan bekend is dat die meer dan 1 regel bevat, krijg je precies dat voor elkaar.
Select case when @@read_only + @@innodb_read_only = 0 then 1 else (select table_name from information_schema.tables) end as `1`
Het gebruik van de MariaDB JDBC driver
Een laatste oplossing die toegepast kan worden is de MariaDB JDBC driver, indien dat mogelijk binnen de specifieke projectvoorwaarden. Deze driver ondersteund Amazon Aurora en is in staat om de topologie van de Database cluster te herkennen. Bovendien heeft het een ingebouwde failover ondersteuning.
Voor meer informatie kun je dit deze blog over de MariaDB JDBC driver op Amazon erop nalezen.
Zou je meer willen weten over wat een WSO2 Cloud jou kan brengen? Neem een kijkje naar onze Managed WSO2 Cloud solution called Connext, de flexibelste en betaalbaarste cloudoplossing voor WSO2 API-management, de WSO2 Enterprise Service Bus en de WSO2 Identity and Access Management. Ze maken allemaal gebruik van de Amazon Aurora services om bij een kant-en-klare installatie al ruime beschikbaarheid en schaalbaarheid te bieden.
