Ich habe schon einmal einen Artikel wie diesen geschrieben.

** Fehlerunterstützung bei Verwendung des Verbindungspools zum Herstellen einer Verbindung zum Amazon Aurora-Cluster **

Zu diesem Zeitpunkt habe ich DBCP2 für den Verbindungspool verwendet, da ich von der lokalen Tomcat 8 + MySQL 5.5-Umgebung auf den Tomcat 8 + Aurora-Cluster (MySQL-kompatibel) unter AWS EC2 migriert habe, aber es gab verschiedene Probleme und die Anpassung war schwierig.

Dieses Mal werde ich dies durch HikariCP (2.7.6) ersetzen und sehen, wie es sich ändert.

Probleme mit der Apache DBCP2-Verbindung

Kurz gesagt, es ist ** "nur langsam" **. Insbesondere "ist der Prozess des Erwerbs (Ausleihens) einer Verbindung aus dem Pool langsam".

aus diesem Grund,

Aurora benötigt lange Zeit, um die Verbindung während des Failovers wiederherzustellen
Um nach dem Failover wieder eine Verbindung zur Writer-Instanz herstellen zu können, müssen Einstellungen im Zusammenhang mit der Entfernung abnormaler Verbindungen vorgenommen werden. Dies wird jedoch zu einem Betriebsaufwand und verlangsamt den gesamten Prozess weiter.
Unter hoher Last bleibt der Prozess hängen, wenn die Anzahl der Verbindungen im Pool erhöht werden muss (z. B. wenn langsames SQL die Verbindung im Pool für längere Zeit belegt), und die Verbindung Die Anzahl erhöht sich nicht

Es ist leicht, in eine solche Situation zu geraten.

Was ist Hikari CP?

Es ist ein schneller, einfacher und äußerst zuverlässiger Verbindungspool.

HikariCP. It's faster.
brettwooldridge/HikariCP（GitHub）

Die Einführungsseite zeigt beispielhaft, wie Sie in Maven einbetten.

Die angezeigte Version ist möglicherweise veraltet. Überprüfen Sie daher bitte README.md auf GitHub.

Ich denke, dass viele Leute es in Kombination mit Hibernate verwenden, daher werde ich die ausführliche Erklärung weglassen.

Aus DBCP2 ersetzt und getestet

Verwenden Sie in einer bestimmten Webanwendung (die unter Tomcat 8 ausgeführt wird) JNDI DataSource Factory und versuchen Sie, sie in ein treiberbasiertes Format zu integrieren.

Vor dem Austausch (DBCP2)

`DBCP2-Verbindung`


<Context reloadable="true" crossContext="true">
        <Resource
                name="jdbc/[Name des Verbindungspools]"
                auth="Container"
                type="javax.sql.DataSource"
                driverClassName="com.mysql.jdbc.Driver"
                factory="org.apache.commons.dbcp.BasicDataSourceFactory"
                url="jdbc:mysql://[Cluster-Endpunkt]/[DB Name]?useUnicode=true&amp;characterEncoding=utf8&amp;connectTimeout=10000&amp;socketTimeout=180000&amp;alwaysSendSetIsolation=false&amp;cacheServerConfiguration=true&amp;elideSetAutoCommits=true&amp;useLocalSessionState=true"
                username="[Verbundener Benutzername]"
                password="[Verbindungskennwort]"
                maxTotal="300"
                maxIdle="150"
                minIdle="10"
                initialSize="10"
                testOnBorrow="true"
                validationQuery="select concheck.validation()"
                validationQueryTimeout="10"
                timeBetweenEvictionRunsMillis="60000"
                maxWait="10000" />
</Context>

Nach dem Austausch (HikariCP)

`Hikari CP-Verbindung`


<Context reloadable="true" crossContext="true">
        <Resource
                name="jdbc/[Name des Verbindungspools]"
                auth="Container"
                type="javax.sql.DataSource"
                driverClassName="com.mysql.jdbc.Driver"
                factory="com.zaxxer.hikari.HikariJNDIFactory"
                jdbcUrl="jdbc:mysql://[Cluster-Endpunkt]/[DB Name]?useUnicode=true&amp;characterEncoding=utf8&amp;connectTimeout=10000&amp;socketTimeout=180000&amp;alwaysSendSetIsolation=false&amp;cacheServerConfiguration=true&amp;elideSetAutoCommits=true&amp;useLocalSessionState=true"
                dataSource.implicitCachingEnabled="true"
                dataSource.user="[Verbundener Benutzername]"
                dataSource.password="[Verbindungskennwort]"
                minimumIdle="10"
                maximumPoolSize="300"
                connectionTimeout="10000"
                idleTimeout="180000"
                maxLifetime="180000"
                connectionInitSql="select concheck.validation()"
                validationTimeout="9800" />
</Context>

Für Bestätigungsanfragen zur Failover-Unterstützung (siehe Artikel oben für Details) wird ** connectionTestQuery ** nicht empfohlen * Es ist in * connectionInitSql ** geschrieben. Selbst wenn Sie es hier schreiben, wird die Verbindung geschlossen und die Verbindung wiederhergestellt, wenn ein Fehler zurückgegeben wird (= Sie haben im Lese- / Schreibmodus eine Verbindung zur Reader-Instanz hergestellt).

Vergleich

JMeter hat 45 Minuten lang 3.000 Anfragen (750 Threads) pro Minute an eine Webanwendung gesendet. Dann habe ich aus mehreren Bildschirmanforderungen in der Webanwendung drei Arten von Rohverarbeitungszeiten (bei unabhängiger Ausführung) extrahiert: kurz / mittel / lang.

Das Gerät ist Millisekunden. Beachten Sie, dass die Datenmenge von Thread zu Benutzer stark variiert, sodass die Verarbeitungszeit von SQL auf dem "langen" Bildschirm auch im ursprünglichen Zustand ** (bis zu 8,5 Sekunden) variiert. Andere Bedingungen sind wie folgt.
4 Webserver (EC2 r4.large / Amazon Linux 2017/09 Version / 2 für jeden AZ / Tomcat 8.0.47)
Aurora hat db.r4.2xlarge als Hauptdatenbank, 2 Cluster / 1 pro Cluster Writer / Reader / Ver.1.16
Die Ergebnisse werden von JMeter (2 JMeter-Clients) aggregiert.

** DBCP2-Ergebnisse **

Anfrage (Bildschirm)	Durchschnittswert	Median	90%Wert	最小Wert	最大Wert
Kurzzeitbearbeitungsbildschirm	60	49	78	24	22,832
Mittlerer Bildschirm	234	177	332	86	21,607
Langzeitverarbeitungsbildschirm	728	171	1,827	45	24,557

** Hikari CP Ergebnisse **

Anfrage (Bildschirm)	Durchschnittswert	Median	90%Wert	最小Wert	最大Wert
Kurzzeitbearbeitungsbildschirm	46	45	57	22	347
Mittlerer Bildschirm	172	158	242	83	3,087
Langzeitverarbeitungsbildschirm	676	146	1,703	41	9,524

Hikari CP ist insgesamt schnell, aber ** bemerkenswert ist das Maximum **.

Im Fall von DBCP2 liegen alle kurz / mittel / lang im Bereich von 20 Sekunden. Dies liegt nicht daran, dass die Verarbeitung des DB-Servers (Aurora) beim parallelen SQL-Fluss langsam wurde, sondern es gab eine Wartezeit (die durch die Verarbeitung anderer Threads beeinflusst wird), um eine Verbindung aus dem Pool zu erhalten (auszuleihen). Zeigt an, dass Sie dies tun.

Wenn im Fall von HikariCP die Anzahl der Anforderungen ungefähr auf dieser Ebene liegt, wird eine Antwort im Bereich von ** "einfache SQL-Verarbeitungszeit + α" ** zurückgegeben.

Failover-Vorgang

Wenn bei DBCP2 die Betriebslast einer Anwendung hoch wird, besteht die Tendenz, dass die Wiederverbindung nach dem Failover sofort blockiert wird. Als ich ein Failover mit HikariCP unter der oben genannten Last ausführte, war es in einem Zustand, in dem die Wiederverbindung in kurzer Zeit durchgeführt wurde, wie in der folgenden Abbildung gezeigt.

Zusammenfassung

Der Unterschied ist bei geringer Last nicht so spürbar, aber bei einem System mit einer bestimmten Last ändert sich die Leistung stark je nach Verbindungspool, was auch die Kapazität der Anzahl der Verbindungen (skalierbarer Bereich) und die Stabilität des Failover-Betriebs erhöht. Es stellt sich heraus, dass sich viel ändern wird.

Insbesondere bei der Migration von einer lokalen in eine AWS-Umgebung oder einer Migration nur von DB zu Aurora wird die Kommunikationsverzögerung (Latenz) von Webserver und Client, die SQL ausgibt, groß. ** "Was war das Problem mit DBCP2 zuvor? Ich hatte keine, aber sobald ich migriert bin, hat sich die Anzahl der Verbindungen nicht gut skaliert und ist verstopft. “** und andere Ereignisse treten häufig auf. Daher denke ich, dass es notwendig ist, bei der Migration sorgfältig zu überprüfen.

** Amazon Aurora-Artikel auf Qiita veröffentlicht **

Verwenden Sie Hikari CP, um die Verbindung zum Amazon Aurora-Cluster zu bündeln