Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Schnelles Failover mit Amazon Aurora PostgreSQL

Im Folgenden erfahren Sie, wie Sie sicherstellen können, dass ein Failover so schnell wie möglich erfolgt. Zur schnellen Wiederherstellung nach dem Failover können Sie die Cluster-Cache-Verwaltung für Ihren Aurora-PostgreSQL-DB-Cluster verwenden. Weitere Informationen finden Sie unter Schnelle Wiederherstellung nach Failover mit der Cluster-Cacheverwaltung für Aurora PostgreSQL.

Zu den Schritten, die Sie ausführen können, um ein schnelles Failover durchzuführen, gehören die folgenden:

Diese werden im Folgenden ausführlicher erläutert.

Einstellen von TCP-Keepalive-Parametern

Wenn Sie eine TCP-Verbindung einrichten, wird ein Satz von Timern mit der Verbindung verknüpft. Wenn der Keepalive-Timer den Wert null erreicht, wird ein Keepalive-Prüfpaket an den Endpunkt der Verknüpfung gesendet. Wenn das Prüfpaket eine Antwort erhält, können Sie davon ausgehen, dass die Verbindung nach wie vor aktiv ist.

Indem Sie TCP-Keepalive-Parameter aktivieren und auf strikte Werte festlegen, können Sie sicherstellen, dass im Falle, dass der Client keine Verbindung zur Datenbank herstellen kann, alle aktiven Verbindungen schnell beendet werden. Die Anwendung kann dann eine Verbindung zu einem neuen Endpunkt herstellen.

Die folgenden TCP-Keepalive-Parameter müssen festgelegt werden:

Mit diesen Einstellungen sollte die Anwendung innerhalb von fünf Sekunden benachrichtigt werden, wenn die Datenbank nicht mehr antwortet. Falls die Keepalive-Pakete innerhalb des Anwendungsnetzwerks häufig verworfen werden, können Sie einen höheren tcp_keepalive_probes-Wert angegeben. Dies ermöglicht mehr Puffer in weniger zuverlässigen Netzwerken, erhöht jedoch die Zeit, die benötigt wird, um einen tatsächlichen Ausfall zu erkennen.

Konfigurieren Ihrer Anwendung für schnelles Failover

Im Folgenden finden Sie eine Beschreibung verschiedener Konfigurationsänderungen für Aurora PostgreSQL, die Sie für ein schnelles Failover vornehmen können. Weitere Informationen zur Einrichtung und Konfiguration des PostgreSQL-JDBC-Treibers finden Sie in der Dokumentation zum PostgreSQL-JDBC-Treiber.

Reduzieren von DNS-Cache-Timeouts

Wenn Ihre Anwendung versucht, eine Verbindung nach einem Failover aufzubauen, wird der neue Aurora-PostgreSQL-Writer ein früherer Reader sein. Sie können ihn finden, indem Sie den schreibgeschützten Aurora-Endpunkt verwenden, bevor DNS-Updates vollständig verbreitet wurden. Den Java DNS-TTL–(time to live)-Wert niedrig festzulegen, z. B. unter 30 Sekunden, sorgt dafür, dass bei späteren Verbindungsversuchen die Reader-Knoten durchlaufen werden können.

// Sets internal TTL to match the Aurora RO Endpoint TTL
java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
// If the lookup fails, default to something like small to retry
java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");

Einstellen einer Aurora PostgreSQL-Verbindungszeichenfolge für ein schnelles Failover

Für die Verwendung eines schnellen Failover in Aurora PostgreSQL stellen Sie sicher, dass die Verbindungszeichenfolge Ihrer Anwendung eine Liste mit Hosts statt einen einzelnen Host enthält. Im Folgenden eine beispielhafte Verbindungszeichenfolge, die Sie verwenden können, um sich mit einem Aurora-PostgreSQL-Cluster zu verbinden. In diesem Beispiel sind die Hosts fett dargestellt.

jdbc:postgresql://myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432
/postgres?user=<primaryuser>&password=<primarypw>&loginTimeout=2
&connectTimeout=2&cancelSignalTimeout=2&socketTimeout=60
&tcpKeepAlive=true&targetServerType=primary

Für die bestmögliche Verfügbarkeit und um eine Abhängigkeit von der RDS-API zu vermeiden, empfehlen wir, eine Datei zu pflegen, mit der Sie eine Verbindung herstellen können. Diese Datei enthält eine Hostzeichenfolge, aus der die Anwendung Daten lesen kann, wenn Sie eine Verbindung zur Datenbank herstellen. Die Hostzeichenfolge enthält alle für das Cluster verfügbaren Aurora-Endpunkte. Weitere Informationen zu Aurora-Endpunkten finden Sie unter Amazon Aurora Aurora-Endpunktverbindungen.

Beispielsweise können Sie Ihre Endpunkte wie folgt in einer lokalen Datei speichern.

myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432

Ihre Anwendung liest aus dieser Datei. um den Hostdatenabschnitt der JDBC-Verbindungzeichenfolge mit Daten füllen. Das Umbenennen des DB-Clusters bewirkt eine Änderung dieser Endpunkte. Stellen Sie sicher, dass Ihre Anwendung dieses Ereignis behandelt, falls es auftritt.

Eine weitere Option ist die Verwendung einer Liste mit DB-Instance-Knoten wie folgt.

my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node3.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node4.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432

Der Vorteil dieses Ansatzes besteht darin, dass der PostgreSQL-JDBC-Verbindungstreiber alle Knoten dieser Liste in einer Schleife durchläuft, um eine gültige Verbindung zu finden. Im Gegensatz dazu werden bei Verwendung der Aurora-Endpunkte bei jedem Verbindungsversuch nur zwei Knoten ausprobiert. Die Verwendung von DB-Instance-Knoten hat jedoch einen Nachteil. Wenn Sie Knoten zum Cluster hinzufügen oder daraus entfernen und dadurch die Liste der Instance-Endpunkte nicht mehr aktuell ist, findet der Verbindungstreiber möglicherweise keinen geeigneten Host mehr für einen Verbindungsaufbau.

Um sicherzustellen, dass die Anwendung mit dem Verbindungsaufbau zu einem Host nicht zu lange wartet, legen Sie für die folgenden Parameter strikte Werte fest:

Sie können weitere Anwendungsparameter ändern, um den Verbindungsvorgang zu beschleunigen, anhängig davon, wie strikt die Anwendung sein soll:

Weitere Optionen zum Abrufen der Hostzeichenfolge

Sie können die Hostzeichenfolge aus mehreren Quellen erhalten, einschließlich der aurora_replica_status-Funktion und durch Verwenden der Amazon RDS-API.

In vielen Fällen müssen Sie bestimmen, wer Schreiber im Cluster ist oder um weitere Leseknoten im Cluster zu finden. Dazu kann sich Ihre Anwendung mit einer beliebigen DB-Instance im DB-Cluster verbinden und die aurora_replica_status-Funktion abfragen. Sie können diese Funktion verwenden, um die Dauer für das Auffinden eines Host für eine Verbindung zu reduzieren. In bestimmten Netzwerkausfallszenarien zeigt out-of-date die aurora_replica_status Funktion jedoch möglicherweise Informationen an oder ist unvollständig.

Eine gute Möglichkeit, um sicherzustellen, dass Ihre Anwendung einen Knoten findet, zu dem eine Verbindung hergestellt werden kann, besteht darin, zu versuchen, eine Verbindung zum Cluster-Schreiber-Endpunkt und dann zum Cluster-Reader-Endpunkt herzustellen. Sie tun dies, bis Sie eine lesbare Verbindung herstellen können. Diese Endpunkte ändern sich nur, wenn Sie Ihren DB-Cluster umbenennen. Sie können diese daher normalerweise als statische Elemente Ihrer Anwendung beibehalten oder in einer Ressourcendatei speichern, aus der Ihre Anwendung liest.

Nachdem Sie eine Verbindung zu einem dieser Endpunkte hergestellt haben, können Sie Informationen über den Rest des Clusters erhalten. Dazu rufen Sie die aurora_replica_status-Funktion auf. Der folgende Befehl ruft z. B. Informationen mit aurora_replica_status ab.

postgres=> SELECT server_id, session_id, highest_lsn_rcvd, cur_replay_latency_in_usec, now(), last_update_timestamp
FROM aurora_replica_status();

server_id | session_id | highest_lsn_rcvd | cur_replay_latency_in_usec | now | last_update_timestamp
-----------+--------------------------------------+------------------+----------------------------+-------------------------------+------------------------
mynode-1 | 3e3c5044-02e2-11e7-b70d-95172646d6ca | 594221001 | 201421 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-2 | 1efdd188-02e4-11e7-becd-f12d7c88a28a | 594221001 | 201350 | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
mynode-3 | MASTER_SESSION_ID | | | 2017-03-07 19:50:24.695322+00 | 2017-03-07 19:50:23+00
(3 rows)

Beispielsweise könnte der Host-Abschnitt Ihrer Verbindungszeichenfolge sowohl mit den Schreiber- als auch den Reader-Cluster-Endpunkten, wie im Folgenden dargestellt, beginnen.

myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432,
myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432

In diesem Szenario versucht die Anwendung, eine Verbindung zu einem beliebigen Knotentyp (primärer oder sekundärer) herzustellen. Wenn Ihre Anwendung verbunden ist, empfiehlt es sich, zuerst den Lese-/Schreibstatus des Knotens zu untersuchen. Fragen Sie dazu das Ergebnis des Befehls SHOW transaction_read_only ab.

Gibt die Abfrage den Wert OFF zurück, haben Sie erfolgreich eine Verbindung zum primären Knoten hergestellt. Angenommen, der Rückgabewert ist jedoch ON und Ihre Anwendung benötigt eine Lese-/Schreibverbindung. In diesem Fall können Sie die aurora_replica_status-Funktion aufrufen, um festzustellen, ob server_id session_id='MASTER_SESSION_ID' enthält. Diese Funktion gibt Ihnen den Namen des primären Knotens zurück. Sie können dies mit dem endpointPostfix verwenden, das wie folgt beschrieben ist.

Stellen Sie sicher, dass Sie wissen, wenn Sie eine Verbindung zu einem Replica herstellen, das veraltete Daten enthält. In diesem Fall zeigt die aurora_replica_status Funktion möglicherweise out-of-date Informationen an. Sie können einen Schwellenwert für Alterung auf Anwendungsebene festlegen. Um dies zu überprüfen, können Sie den Unterschied zwischen der Serverzeit und dem last_update_timestamp-Wert betrachten. Im Allgemeinen sollte Ihre Anwendung es vermeiden, aufgrund widersprüchlicher Informationen, die von der Funktion aurora_replica_status zurückgegeben werden, zwischen zwei Hosts hin- und herzuschalten. Ihre Anwendung sollte zuerst alle bekannten Hosts ausprobieren, anstatt den von aurora_replica_status zurückgegebenen Daten zu folgen.

Java-Beispiel zum Auflisten von Instances, die den Vorgang DescribeDBClusters-API verwenden

Sie können programmgesteuert mit AWS SDK for Java nach der Instance-Liste suchen, genauer gesagt, mit dem Vorgang DescribeDBClusters-API.

Hier ist ein kleines Beispiel, wie Sie dies in Java 8 durchführen können.

AmazonRDS client = AmazonRDSClientBuilder.defaultClient();
DescribeDBClustersRequest request = new DescribeDBClustersRequest()
   .withDBClusterIdentifier(clusterName);
DescribeDBClustersResult result = 
rdsClient.describeDBClusters(request);

DBCluster singleClusterResult = result.getDBClusters().get(0);

String pgJDBCEndpointStr = 
singleClusterResult.getDBClusterMembers().stream()
   .sorted(Comparator.comparing(DBClusterMember::getIsClusterWriter)
   .reversed()) // This puts the writer at the front of the list
   .map(m -> m.getDBInstanceIdentifier() + endpointPostfix + ":" + singleClusterResult.getPort()))
   .collect(Collectors.joining(","));

Hier enthält pgJDBCEndpointStr eine formatierte Liste mit Endpunkten, wie im Folgenden.

my-node1.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432,
my-node2.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com:5432

Die Variable endpointPostfix kann eine Konstante sein, die Ihre Anwendung festlegt. Oder Ihre Anwendung kann es erhalten, indem sie den DescribeDBInstances-API-Vorgang für eine einzelne Instance in Ihrem Cluster abfragt. Dieser Wert bleibt innerhalb eines AWS-Region und für einen einzelnen Kunden konstant. Es wird also ein API-Aufruf gespeichert, um diese Konstante in einer Ressourcendatei zu speichern, aus der Ihre Anwendung liest. Im vorherigen Beispiel ist es auf den folgenden festgelegt.

.cksc6xlmwcyw.us-east-1-beta.rds.amazonaws.com

Eine gute Methode zur Gewährleistung der Verfügbarkeit ist die standardmäßige Nutzung der Aurora-Endpunkte Ihres DB-Clusters für den Fall, dass die API nicht oder zu langsam reagiert. Diese Endpunkte sind garantiert auf dem aktuellen Stand – im Zeitraum, der für das Update eines DNS-Datensatzes benötigt wird. Das Aktualisieren des DNS-Eintrags mit einem Endpunkt dauert in der Regel weniger als 30 Sekunden. Sie können den Endpunkt in einer Ressourcendatei speichern, die von Ihrer Anwendung verwendet wird.

Testen eines Failovers

In allen Fällen müssen Sie einen DB-Cluster mit zwei oder mehr DB-Instances haben.

Serverseitig können bestimmte API-Vorgänge einen Ausfall verursachen, anhand dessen Sie testen können, wie Ihre Anwendungen reagieren:

Wenn Sie Linux verwenden, können Sie auf Anwendungs- oder Clientseite testen, wie die Anwendung auf plötzliche Paketverluste reagiert. Sie können dies basierend darauf tun, ob Port, Host oder ob TCP-Keepalive-Pakete gesendet oder empfangen werden, indem Sie den Befehl „iptables“ verwenden.

Beispiel für schnelles Java-Failover

Der folgende Beispiel-Code zeigt, wie eine Anwendung einen Aurora-PostgreSQL-Treibermanager einrichten kann.

Die Anwendung ruft die getConnection-Funktion auf, wenn eine Verbindung hergestellt werden soll. Ein Anruf bei getConnection kann möglicherweise keinen gültigen Host finden. Ein Beispiel ist, wenn kein Schreiber gefunden wird, aber der targetServerType-Parameter auf primary festgelegt ist. In diesem Fall sollte die aufrufende Anwendung einfach erneut versuchen, die Funktion aufzurufen.

Um zu vermeiden, dass das Wiederholungsverhalten auf die Anwendung geschoben wird, können Sie diesen Wiederholungsaufruf in einen Verbindungspooler verpacken. Bei den meisten Verbindungspoolern können Sie eine JDBC-Verbindungszeichenfolge angeben. Ihre Anwendung ewerbung kann sich also bei getJdbcConnectionString einwählen und das an den Verbindungspooler weitergeben. Dadurch können Sie ein schnelleres Failover mit Aurora PostgreSQL verwenden.

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.sql.Statement;
import java.util.ArrayList;
import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

import org.joda.time.Duration;

public class FastFailoverDriverManager {
   private static Duration LOGIN_TIMEOUT = Duration.standardSeconds(2);
   private static Duration CONNECT_TIMEOUT = Duration.standardSeconds(2);
   private static Duration CANCEL_SIGNAL_TIMEOUT = Duration.standardSeconds(1);
   private static Duration DEFAULT_SOCKET_TIMEOUT = Duration.standardSeconds(5);

   public FastFailoverDriverManager() {
       try {
            Class.forName("org.postgresql.Driver");
       } catch (ClassNotFoundException e) {
            e.printStackTrace();
       }

       /*
         * RO endpoint has a TTL of 1s, we should honor that here. Setting this aggressively makes sure that when
         * the PG JDBC driver creates a new connection, it will resolve a new different RO endpoint on subsequent attempts
         * (assuming there is > 1 read node in your cluster)
         */
        java.security.Security.setProperty("networkaddress.cache.ttl" , "1");
       // If the lookup fails, default to something like small to retry
       java.security.Security.setProperty("networkaddress.cache.negative.ttl" , "3");
   }

   public Connection getConnection(String targetServerType) throws SQLException {
       return getConnection(targetServerType, DEFAULT_SOCKET_TIMEOUT);
   }

   public Connection getConnection(String targetServerType, Duration queryTimeout) throws SQLException {
        Connection conn = DriverManager.getConnection(getJdbcConnectionString(targetServerType, queryTimeout));

       /*
         * A good practice is to set socket and statement timeout to be the same thing since both 
         * the client AND server will stop the query at the same time, leaving no running queries 
         * on the backend
         */
        Statement st = conn.createStatement();
        st.execute("set statement_timeout to " + queryTimeout.getMillis());
        st.close();

       return conn;
   }

   private static String urlFormat = "jdbc:postgresql://%s"
           + "/postgres"
           + "?user=%s"
           + "&password=%s"
           + "&loginTimeout=%d"
           + "&connectTimeout=%d"
           + "&cancelSignalTimeout=%d"
           + "&socketTimeout=%d"
           + "&targetServerType=%s"
           + "&tcpKeepAlive=true"
           + "&ssl=true"
           + "&loadBalanceHosts=true";
   public String getJdbcConnectionString(String targetServerType, Duration queryTimeout) {
       return String.format(urlFormat, 
                getFormattedEndpointList(getLocalEndpointList()),
                CredentialManager.getUsername(),
                CredentialManager.getPassword(),
                LOGIN_TIMEOUT.getStandardSeconds(),
                CONNECT_TIMEOUT.getStandardSeconds(),
                CANCEL_SIGNAL_TIMEOUT.getStandardSeconds(),
                queryTimeout.getStandardSeconds(),
                targetServerType
       );
   }

   private List<String> getLocalEndpointList() {
       /*
         * As mentioned in the best practices doc, a good idea is to read a local resource file and parse the cluster endpoints. 
         * For illustration purposes, the endpoint list is hardcoded here
         */
        List<String> newEndpointList = new ArrayList<>();
        newEndpointList.add("myauroracluster.cluster-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432");
        newEndpointList.add("myauroracluster.cluster-ro-c9bfei4hjlrd.us-east-1-beta.rds.amazonaws.com:5432");

       return newEndpointList;
   }

   private static String getFormattedEndpointList(List<String> endpoints) {
       return IntStream.range(0, endpoints.size())
               .mapToObj(i -> endpoints.get(i).toString())
               .collect(Collectors.joining(","));
   }
}