Einsatz von Amazon Aurora als Datenquelle mit hoher Verfügbarkeit in Connext: Yenlo’s WSO2 Cloud Solution
In der WSO2 Cloud Solution Connext von Yenlo nutzen wir den Amazon Aurora Service für die Datenquellen, die von den WSO2-Produkten benutzt werden. Amazon Aurora bietet eine Datenbank mit Hochverfügbarkeits-Endpunkten. Es bietet standardmäßig 2 benannte Endpunkte für den Zugriff auf die Datenbank, einen Cluster-Endpunkt mit Lese-/Schreibzugriff und einen Nur-Lese-Endpunkt.
Dies bedeutet, dass Sie kein Failover in Ihrer Anwendung konfigurieren müssen, da Sie den Cluster-Endpunkt verwenden können, der automatisch immer auf die Datenbankinstanz mit Schreibzugriff verweist.
Um den Datenbankzugriff innerhalb der WSO2-Produkte zu konfigurieren, wird der JDBC mysql-Treiber zusammen mit Connection Pooling eingesetzt. Der Connection Pool stellt sicher, dass die Datenbankverbindung verfügbar und funktionsfähig ist, wenn die Anwendung eine Verbindung benötigt.
<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>
Die oben dargestellte Konfiguration dient als Beispiel für einen JDBC-Benutzerspeicher in einem WSO2-Produkt, es dient rein als Beispiel und sollte nicht direkt auf Produktionssystemen verwendet werden, da es beispielsweise ein Klartextpasswort ist.
Wir sehen hier, dass es so konfiguriert ist, dass der Verbindungspool die Verbindung prüft, ehe er sie an den Dienst übergibt, der sie anfordert, und zwar mit der Einstellung testOnBorrow. Wenn die Verbindung getestet wird, wird die validationQuery ausgeführt, die der Best Practice „SELECT 1“ folgt und nur funktioniert, wenn die Verbindung aktiv ist.
Failover
Wenn Amazon Aurora gezwungen ist, ein Failover durchzuführen, sobald ein Node ausfällt, wird ein Reader Node zum Master Node befördert und die read_only-Einstellung entfernt. Der frühere Master-Node wird im read_only-Modus neu gestartet. Ist dies erfolgreich, ist er zwar wieder betriebsbereit, aber nicht mehr für Schreibvorgänge nutzbar und fungiert als Node für Lesezugriffe.
Da der Connection Pool die zugrunde liegende Amazon Aurora-Lösung nicht kennt, wird er über ein Failover nicht benachrichtigt. Wenn das Failover also schnell passiert und der Node erfolgreich im read_only-Modus neu gestartet wird, hat der Connection Pool Verbindungen zu einem Lese-Node, die er als Arbeitsverbindungen validiert. Die Überprüfung wird korrekt ausgeführt, aber wenn die Anwendung versucht, diese Anschlüsse zu verwenden, wird sie offensichtlich auf Datenbankfehler stoßen, die behaupten, dass sich die Datenbank im read_only-Modus befindet.
Der Verbindungs-Pool ist nicht in der Lage, diese Verbindungen wiederherzustellen, sodass das Produkt neu gestartet werden muss, um diese wiederherzustellen.
Lösungen
Verwendung des Parameters maxAge
Es besteht die Möglichkeit, ein Maximalalter für eine Verbindung im Verbindungspool festzulegen. Damit werden Verbindungen, die älter als die Einstellung sind, aus dem Pool entfernt, sobald sie von der Anwendung freigegeben werden. Dies stellt sicher, dass sich die Anwendung von einem Amazon Aurora-Failover erholt, wenn die fehlerhaften Verbindungen im Pool eine Zeitüberschreitung aufweisen.
Verwendung einer erweiterten validationQuery
Amazon Aurora bietet einen spezifischen Parameter, der in einer Abfrage gelesen werden kann, um anzugeben, dass ein Node read_only ist, nämlich „innodb_read_only“. In anderen Failover-Lösungen könnte dieser Parameter „read_only“ heißen. Eine weitere Lösung für das Failover-Problem besteht darin, eine Validierungsabfrage zu setzen, die scheitert, wenn sie auf einem read_only-Host ausgeführt wird. Durch Verwendung der oben genannten Eigenschaften in einer Case-Anweisung, die bei Ausführung auf einem read_only-Host zu einer Exception ausgewertet wird, kennzeichnet der Connection Pool die Verbindung als fehlerhaft und verwirft sie.
Ein Weg, dies zu tun, ist, die Abfrage mehr als eine Zeile zurückgeben zu lassen, die von der validationQuery nicht erwartet wird. Zum Beispiel mit einer select from-Abfrage auf eine der Standard-MySQL-Tabellen, von denen bekannt ist, dass sie mehr als eine Zeile enthalten, wird genau das erreicht.
Wählen Sie den Fall wenn @@read_only + @@innodb_read_only = 0 dann 1 sonst (table_name von information_schema.tables wählen) enden als `1`
Den MariaDB-JDBC-Treiber verwenden
Eine letzte Lösung, die verwendet werden kann, ist die Verwendung des MariaDB JDBC-Treibers, wenn dies unter Projektbedingungen möglich ist. Dieser Treiber unterstützt Amazon Aurora und ist in der Lage, die Topologie des Datenbank-Clusters zu erkennen. Er verfügt auch über eine eingebaute Failover-Unterstützung.
Weitere Informationen finden Sie in diesem Blog über den MariaDB JDBC-Treiber auf Amazon.
Sie möchten mehr über unser WSO2 Cloud-Angebot erfahren? Schauen Sie sich unsere 24/7 Managed WSO2 Cloud Solution namens Connext an, die flexibelste und günstigste Cloud-Lösung für WSO2 API Management, WSO2 Enterprise Service Bus und WSO2 Identity and Access Management. Alle nutzen die Amazon Aurora Services, um Hochverfügbarkeit und Skalierbarkeit out-of-the-box zu gewährleisten.
