Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Failover rapido con Amazon Aurora PostgreSQL

Di seguito, vengono fornite informazioni su come garantire che il failover si verifichi il più rapidamente possibile. Per ripristinare rapidamente dopo il failover, è possibile utilizzare la gestione della cache del cluster per il cluster di database Aurora PostgreSQL. Per ulteriori informazioni, consulta Ripristino rapido dopo il failover con Cluster Cache Management per Aurora PostgreSQL.

Alcuni dei passaggi da eseguire affinché il failover venga eseguito rapidamente includono i seguenti:

Questi sono descritti in modo dettagliato di seguito.

Impostazione dei parametri di keepalive TCP

Quando si imposta una connessione TCP, ad essa viene associato un set di timer. Quando il timer keepalive raggiunge lo zero, un pacchetto di esplorazione keepalive viene inviato all’endpoint di connessione. Se la sonda riceve una risposta, si può presumere che la connessione sia ancora attiva e in esecuzione.

Attivare i parametri keepalive TCP e impostarli in modo aggressivo garantisce che se il client non è in grado di connettersi al database, le eventuali connessioni attive vengono chiuse rapidamente. L'applicazione può quindi connettersi a un nuovo endpoint.

I seguenti parametri keepalive TCP devono essere impostati:

Queste impostazioni dovrebbero notificare l'applicazione entro cinque secondi quando il database smette di rispondere. Se i pacchetti keepalive vengono spesso eliminati all'interno della rete dell'applicazione, è possibile impostare un valore tcp_keepalive_probes più elevato. Questo consente di avere più buffer in reti meno affidabili, sebbene aumenti il tempo necessario per rilevare un errore effettivo.

Configurare l'applicazione per il Failover rapido

Di seguito, è disponibile una discussione su diverse modifiche di configurazione per Aurora PostgreSQL che è possibile apportare per un failover rapido. Per ulteriori informazioni sulla configurazione e la configurazione del driver JDBC PostgreSQL, vedere la documentazione PostgreSQL JDBC Driver.

Ridurre i timeout della cache DNS

Quando l'applicazione prova a stabilire una connessione dopo un failover, il nuovo scrittore Aurora PostgreSQL sarà un lettore precedente Per individuarlo, utilizzare l'endpoint di sola lettura Aurora prima della completa propagazione degli aggiornamenti DNS. Impostare Time to Live (TTL) java DNS su un valore basso, ad esempio meno di 30 secondi, consente di effettuare il ciclo tra i nodi del lettore nei successivi tentativi di connessione.

// 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");

Impostare una stringa di connessione Aurora PostgreSQL per un Failover rapido

Per usare il failover rapido di Aurora PostgreSQL, accertarsi che la stringa di connessione dell'applicazione contenga un elenco di host anziché un singolo host. Di seguito è riportata una stringa di connessione di esempio che può essere utilizzata per connettersi a un cluster Aurora PostgreSQL: In questo esempio, gli host sono in grassetto.

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

Per una migliore disponibilità e per evitare una dipendenza dall'API RDS, è opportuno mantenere un file con cui eseguire la connessione. Questo file contiene una stringa host che viene letta dall'applicazione quando si stabilisce una connessione al database. Questa stringa host contiene tutti gli endpoint Aurora disponibili per il cluster. Per altre informazioni sugli endpoint Aurora, consultare Connessioni endpoint Amazon Aurora.

Ad esempio, potrebbe essere necessario archiviare gli endpoint in un file locale come mostrato di seguito.

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

L'applicazione legge da questo file per compilare la sezione host della stringa di connessione JDBC. Rinominare il cluster DB fa sì che questi endpoint siano modificati. Assicurati che l'applicazione gestisca questo evento nel caso in cui si verifichi.

Un'altra opzione è usare un elenco di nodi di istanze database, come illustrato di seguito.

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

Il vantaggio di questo approccio è che il driver di connessione PostgreSQL JDBC esegue un ciclo di tutti i nodi in questo elenco per individuare una connessione valida. Al contrario, quando si usano gli endpoint Aurora, vengono provati solo due nodi per ogni tentativo di connessione. Tuttavia, l'utilizzo dei nodi di istanza database presenta uno svantaggio. Se si aggiungono o si rimuovono nodi dal cluster e l'elenco degli endpoint di istanza diventa obsoleto, il driver di connessione potrebbe non trovare mai l'host corretto cui connettersi.

Per garantire che l'applicazione non rimanga in attesa troppo a lungo prima di connettersi a un host, imposta i seguenti parametri in modo aggressivo.

In base al livello di aggressività desiderato per l'applicazione, puoi modificare altri parametri dell'applicazione per accelerare il processo di connessione:

Altre opzioni per ottenere la stringa host

È possibile ottenere la stringa host da diverse fonti, compresa la funzione aurora_replica_status e usando l'API di Amazon RDS.

In molti casi, occorre determinare chi è lo scrittore del cluster o trovare altri nodi di lettura nel cluster. A questo scopo, l'applicazione può connettersi a qualsiasi istanza database nel cluster database ed eseguire la query della funzione aurora_replica_status. Questa funzione può essere utilizzata per ridurre il tempo necessario per trovare un host cui connettersi. Tuttavia, in alcuni scenari di errore di rete, la aurora_replica_status funzione potrebbe mostrare informazioni o essere incomplete. out-of-date

Un buon modo per assicurarsi che l'applicazione possa individuare un nodo cui connettersi è provare a connettersi all'endpoint di scrittura del cluster e quindi all'endpoint di lettura del cluster, fino a quando non è possibile stabilire una connessione leggibile. Questi endpoint non cambiano a meno che il cluster database non venga rinominato. Quindi, in genere possono essere lasciati come membri statici dell'applicazione o archiviati in un file di risorsa che viene letto dall'applicazione.

Una volta stabilita una connessione usando uno di questi endpoint, è possibile ottenere informazioni sul resto del cluster. A questo scopo, richiama la funzione aurora_replica_status. Ad esempio, il comando seguente recupera informazioni con aurora_replica_status.

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)

Ad esempio, la sezione host della stringa di connessione potrebbe iniziare con entrambi gli endpoint del cluster di scrittura e di lettura, come mostrato di seguito.

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

In questo scenario, l'applicazione prova a stabilire una connessione a qualsiasi tipo di nodo, primario o secondario. Una volta connessa, una buona prassi è quella di esaminare innanzitutto lo stato di lettura-scrittura del nodo. A questo scopo, occorre eseguire la query del risultato del comando SHOW transaction_read_only.

Se il valore restituito della query è OFF, allora la connessione al nodo primario è andata a buon fine. Tuttavia, si supponga che il valore restituito sia ON e che l'applicazione richieda una connessione di lettura/scrittura. In questo caso, si può richiamare la funzione aurora_replica_status per determinare il server_id che ha session_id='MASTER_SESSION_ID'. Questa funzione fornisce il nome del nodo primario. Ciò è possibile il endpointPostfix descritto di seguito.

È importante sapere quando si esegue una connessione a una replica con dati obsoleti. Quando ciò accade, la aurora_replica_status funzione potrebbe mostrare out-of-date informazioni. Una soglia di obsolescenza può essere impostata a livello di applicazione. Per la verifica, osservare la differenza tra l'ora del server e il valore last_update_timestamp. In generale, l'applicazione dovrebbe evitare di alternarsi tra due host a causa delle informazioni in conflitto restituite dalla funzione aurora_replica_status. L'applicazione dovrebbe provare prima tutti gli host conosciuti anziché seguire i dati restituiti da aurora_replica_status.

Elencare istanze utilizzando l'operazione API DescribeDBClusters, esempio in Java

L'elenco delle istanze può essere ricavato in maniera programmatica utilizzando l'AWS SDK for Java, in particolare l'operazione API DescribeDBClusters.

Di seguito è riportato un piccolo esempio di come eseguire questa operazione in Java 8:

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(","));

Qui, pgJDBCEndpointStr contiene un elenco formattato di endpoint, come mostrato di seguito.

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

La variabile endpointPostfix può essere una costante impostata dall'applicazione. Oppure, può essere ottenuta dall’applicazione eseguendo la query dell’operazione API DescribeDBInstances per una singola istanza del cluster. Questo valore rimane costante all'interno di un Regione AWS e per un singolo cliente. Pertanto, salva una chiamata API per mantenere semplicemente questa costante in un file di risorsa letto dall'applicazione. Nell'esempio precedente, è impostato sul valore seguente.

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

Ai fini della disponibilità, una buona norma è quella di usare per impostazione predefinita gli endpoint Aurora del cluster database se l'API non risponde o impiega troppo tempo a rispondere. Viene garantito l'aggiornamento degli endpoint nel tempo necessario per aggiornare il record DNS. L'aggiornamento del record DNS con un endpoint richiede in genere meno di 30 secondi. L’endpoint può essere memorizzato in un file di risorse utilizzato dall'applicazione.

Verifica del Failover

In tutti i casi è necessario disporre di un cluster di database contenente due o più istanze database.

Dal lato server, alcune operazioni API possono causare un'interruzione che può essere usata per testare la risposta delle applicazioni:

Dal lato applicazione o client, se si usa Linux, è possibile testare in che modo l'applicazione risponde a improvvise eliminazioni di pacchetti. Ciò può essere fatto a seconda che porta, host o se i pacchetti keepalive TCP vengono inviati o ricevuti utilizzando il comando iptables.

Esempio di failover rapido in Java

Il seguente esempio di codice mostra come un'applicazione potrebbe configurare un gestore di driver di Aurora PostgreSQL.

L'applicazione richiama la funzione getConnection quando è richiesta una connessione. Una chiamata a getConnection può non riuscire a trovare un host valido. Un esempio è quando non viene trovato alcuno scrittore ma il parametro targetServerType è impostato su primary. In questo caso, l'applicazione chiamante deve semplicemente riprovare a richiamare la funzione.

Per evitare di spingere il comportamento dei tentativi continui nell'applicazione, puoi impacchettare questo tentativo di chiamata in un pool di connessioni. Con la maggior parte dei pool di connessioni, puoi specificare una stringa di connessione JDBC. Pertanto l'applicazione può richiamare getJdbcConnectionString e passarla al pool di connessioni. Ciò significa che con Aurora PostgreSQL si può utilizzare un failover più rapido.

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(","));
   }
}