View a markdown version of this page

Linee guida di configurazione - Amazon Relational Database Service
Impostazioni per RDS ProxyAllineamento della configurazione di applicazioni, proxy e databaseConfigurazione del databaseConfigurazione dell’applicazione

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à.

Linee guida di configurazione

Questa sezione descrive le impostazioni disponibili in RDS Proxy e fornisce le migliori pratiche per allineare la configurazione nello stack di applicazioni. Queste sono linee guida combinate per l'utilizzo di RDS Proxy con Amazon RDS e Amazon Aurora. RDS-specific e le Aurora-specific note vengono richiamate laddove applicabile.

Salvo diversa indicazione, i termini «database» o «destinazione» si riferiscono a un cluster Aurora, un cluster Amazon RDS Multi-AZ DB o un'istanza Amazon RDS.

Impostazioni per RDS Proxy

MaxConnectionsPercent

Valore minimo Valore massimo Valore predefinito
minore di (1, MaxIdleConnectionsPercent) 100 100

Per ulteriori informazioni, consulta MaxConnectionsPercent.

Questa impostazione limita il numero di connessioni che il proxy RDS può stabilire con il database di destinazione, come percentuale del numero massimo di connessioni consentite dal database. Il proxy apre le connessioni back-end in base alle esigenze, pertanto il numero effettivo di connessioni in un dato momento potrebbe essere inferiore al massimo configurato.

Poiché l'MaxConnectionsPercentimpostazione è una percentuale del limite di connessione al database, la dimensione del pool di connessioni del proxy segue automaticamente la configurazione del database. Ciò significa che non è necessario riconfigurare i proxy ogni volta che si ridimensionano le istanze del database o si apportano modifiche alla configurazione. Significa anche che è necessario essere consapevoli degli scenari in cui le impostazioni del database potrebbero cambiare, in modo implicito o esplicito:

Le migliori pratiche:

  • L'impostazione predefinita del 100% è adatta per i database che ricevono tutto il loro traffico tramite il proxy e non necessitano di spazio per l'accesso amministrativo o per altri client.

  • Riduci questa impostazione quando il database riceve anche traffico direttamente dalle applicazioni (bypassando il proxy) e non desideri che il proxy utilizzi tutte le connessioni o quando desideri riservare un certo numero di connessioni ad altri scopi, come l'accesso diretto da parte degli amministratori del database.

  • Quando si utilizza RDS Proxy con i cluster Aurora Global Database e l'inoltro di scrittura è abilitato, riduci il valore MaxConnectionsPercent del proxy in base alla quota assegnata per l'inoltro di scrittura. Per i dettagli, consulta i parametri di configurazione per l'inoltro della scrittura in Aurora MySQL e Aurora PostgreSQL nella Amazon Aurora User Guide. Questa raccomandazione si applica a prescindere dal fatto che il proxy serva un cluster nella regione primaria o secondaria del database globale. I cluster secondari possono essere promossi al ruolo principale, quindi è buona norma mantenere le impostazioni del proxy coerenti in tutta la topologia globale. È possibile utilizzare impostazioni asimmetriche per i proxy che servono le aree primarie rispetto a quelle secondarie, ma sarà necessario modificare tali impostazioni dopo ogni failover o switchover globale.

  • Se la destinazione serve più proxy, il valore combinato di tutti questi proxy non deve superare 100 MaxConnectionsPercent in modo che il database non subisca un eccesso di sottoscrizione. Si consiglia di utilizzare un solo proxy per destinazione per semplificare la configurazione e la gestione. In particolare, non è necessario utilizzare più proxy per database per la ridondanza. Per ulteriori informazioni, consulta Utilizzo di più proxy con un unico obiettivo.

Che tu stia utilizzando l'MaxConnectionsPercentimpostazione predefinita o un valore personalizzato, mantieni almeno un margine di crescita del 30% tra il numero di connessioni consentite e il numero massimo di connessioni client previste durante i periodi di punta. Esempio:

  • Se ritieni che il proxy richieda fino al 50% del limite di connessione configurato per il database, utilizza un'MaxConnectionsPercentimpostazione di almeno1.3 * 50% = 65%.

  • Quando utilizzi l'MaxConnectionsPercentimpostazione predefinita di 100, assicurati che il limite del database stesso fornisca un margine di crescita sufficiente.

Questo margine di crescita aggiuntivo migliora l'esperienza del cliente in caso di picchi di carico di lavoro imprevisti e aiuta RDS Proxy a ridistribuire le connessioni attraverso la sua infrastruttura interna per la gestione del calore e altri scopi.

Sebbene sia possibile impostare un valore minimo pari MaxConnectionsPercent a 1, consigliamo i seguenti valori minimi in base al tipo di istanza:

  • db.t3.small: 100

  • db.t3.medium: 55

  • db.t3.large: 35

  • db.r3.large o superiore: 20

MaxIdleConnectionsPercent

Valore minimo Valore massimo Valore predefinito (SQL Server) Valore predefinito (altri motori)
(zero) MaxConnectionsPercent 5% di MaxConnectionsPercent 50% di MaxConnectionsPercent

Per ulteriori informazioni, consulta MaxIdleConnectionsPercent.

Questa impostazione limita il numero di connessioni inattive al database che RDS Proxy mantiene nel pool di connessioni, come percentuale del numero massimo di connessioni consentite dal database. Una connessione al database (back-end) è considerata inattiva quando non vi è stata alcuna attività sulla connessione per cinque minuti. Questa impostazione si applica alle connessioni tra il proxy e il database di back-end.

Tenere presente quanto segue:

  • Questa impostazione limita il numero di connessioni inattive nel pool, ma non obbliga il proxy a mantenere un determinato numero di connessioni inattive. Se l'attività del client è molto bassa, il numero effettivo di connessioni al database di back-end può essere inferiore a. MaxIdleConnectionsPercent

  • Le connessioni vengono considerate inattive quando sono disponibili per il riutilizzo nel pool di connessioni del proxy. Le connessioni bloccate non possono essere riutilizzate da altri client e pertanto non vengono considerate inattive ai fini dell'applicazione. MaxIdleConnectionsPercent Per ulteriori informazioni sul blocco, vedere. Evitare di effettuare il pinning di un Server proxy per RDS

  • Il numero di connessioni inattive segnalate dai metadati del database è in genere superiore al numero di connessioni inattive registrate dalle metriche del proxy RDS. Ciò può essere dovuto alle connessioni dirette dei client che aggirano il proxy e alle connessioni interne utilizzate dall'automazione di Amazon RDS e Aurora.

Nota

Il tempo di inattività della connessione osservato e applicato a livello proxy potrebbe essere diverso dal tempo di inattività riportato dagli strumenti di database come l'elenco dei processi MySQL o le tabelle delle statistiche delle attività in PostgreSQL. RDS Proxy esegue occasionalmente il ping delle connessioni back-end, il che reimposta i timer di inattività del database anche se la connessione rimane inattiva in termini di attività del client.

Procedure consigliate:

L'impostazione predefinita di 50 è adatta e consigliata per la maggior parte dei carichi di lavoro. La modifica dell'impostazione ha il seguente effetto:

  • Quando si aumentaMaxIdleConnectionsPercent, il database rileva un numero maggiore di connessioni inattive, il che può aumentare il consumo di risorse del database al di fuori delle ore di punta. D'altra parte, i picchi di connessione gestiti tramite il proxy presentano una latenza di prestito inferiore perché ci sono più connessioni prontamente disponibili nel pool.

  • Quando si scendeMaxIdleConnectionsPercent, il proxy chiude le connessioni inattive in modo più aggressivo, riducendo potenzialmente i conflitti e il consumo di risorse causati da tali connessioni. Tuttavia, i picchi di connessione che attraversano il proxy potrebbero richiedere tempi di prestito più lunghi. Poiché nel pool sono disponibili meno connessioni, il proxy deve dedicare più tempo all'apertura di nuove connessioni back-end durante un picco.

Il consumo di risorse da parte delle connessioni inattive potrebbe non essere un problema rilevante nei database che utilizzano tipi di istanze assegnate, ma i database Aurora che utilizzano il tipo di istanza Serverless v2 potrebbero preferire ottimizzare il consumo di risorse inattive per ridurre i costi.

IdleClientTimeout

Valore minimo Valore massimo Valore predefinito
1 minuto 8 ore 30 minuti

Per ulteriori informazioni, consulta IdleClientTimeout.

Questa impostazione determina per quanto tempo una connessione client può rimanere inattiva prima che il proxy la chiuda. Tieni presente che RDS Proxy impone una durata massima della connessione di 24 ore, indipendentemente dal fatto che la connessione sia inattiva. Ad esempio, se si configura IdleClientTimeout su 30 minuti (impostazione predefinita) e si esegue il ping del database ogni minuto, la connessione non supera mai il timeout di inattività, ma non rimane aperta a tempo indeterminato. RDS Proxy chiude la connessione dopo 24 ore anche se non è considerata inattiva.

L'IdleClientTimeoutimpostazione si applica alla connessione tra un client (applicazioni o utenti interattivi) e RDS Proxy. Per comprendere il comportamento inattivo delle connessioni back-end tra il proxy RDS e il database, vedere. MaxIdleConnectionsPercent

Procedure consigliate:

  • Il timeout di inattività deve essere sufficientemente lungo da consentire le normali pause nell'attività SQL all'interno di una connessione o transazione client. Non deve essere così lungo da consentire a un cliente di conservare risorse di cui ragionevolmente non ha più bisogno, ma che potrebbero essere necessarie ad altri client. Ciò è particolarmente importante se si osserva il blocco della connessione, perché una connessione bloccata da un client non può essere riutilizzata da altri client.

  • Affinché RDS Proxy applichi correttamente il timeout, la connessione client deve essere realmente inattiva senza inviare alcuna richiesta (nemmeno semplici controlli di integrità comeSELECT 1;) o ping di protocollo (come in MySQL). COM_PING Se osservate che le connessioni non vengono chiuse nonostante il superamento del timeout, controllate la logica di connessione dei driver dell'applicazione. Application-level È particolarmente probabile che i pool di connessione eseguano i propri controlli di vivacità interferendo con. IdleClientTimeout

ConnectionBorrowTimeout

Valore minimo Valore massimo Valore predefinito
(zero) 5 minuti 2 minuti

Per ulteriori informazioni, consulta ConnectionBorrowTimeout.

Quando un client si connette a RDS Proxy, il proxy deve prendere in prestito una connessione esistente disponibile dal pool o aprire una nuova connessione al database. Questa impostazione definisce per quanto tempo il proxy RDS attende che una connessione venga presa in prestito o aperta prima di restituire un errore.

Tenere presente quanto segue:

  • Un valore pari a zero genera errori ConnectionBorrowTimeout di timeout quando il pool di connessioni non contiene già una connessione disponibile. Ciò è vero anche se il pool ha una capacità inferiore alla capacità massima e potrebbe aprire una nuova connessione back-end.

  • Anche se MaxIdleConnectionsPercent uguale aMaxConnectionsPercent, il numero effettivo di connessioni nel pool può essere inferiore al massimo configurato. In altre parole, MaxIdleConnectionsPercent limita il numero di connessioni inattive ma non obbliga le connessioni a rimanere aperte.

È normale che un pool di connessioni funzioni al di sotto della capacità massima. In questa situazione, l'utilizzo di un'ConnectionBorrowTimeoutimpostazione pari a zero può impedire la crescita del pool perché il pool non può attendere l'apertura di una nuova connessione. Di conseguenza, è necessario utilizzare ConnectionBorrowTimeout valori diversi da zero per tutti i carichi di lavoro, a meno che non si preferisca il comportamento descritto in precedenza.

Nota

Questa impostazione si applica anche quando il database non è pronto ad accettare connessioni, ad esempio durante le operazioni di manutenzione offline e i failover. La logica per applicare il ConnectionBorrowTimeout è la stessa indipendentemente dal fatto che il database sia attivo o inattivo.

Interrogazioni di inizializzazione e filtri di blocco

RDS Proxy supporta funzionalità aggiuntive che possono ridurre il blocco della connessione e, di conseguenza, migliorare l'efficienza del multiplexing.

Una query di inizializzazione è costituita da una o più istruzioni eseguite ogni volta che il proxy imposta una nuova connessione al database back-end. Se i client utilizzano istruzioni identiche per impostare i parametri di sessione, è possibile spostare tali istruzioni nella query di inizializzazione del proxy. Questo aiuta a ridurre la probabilità di blocco e migliora anche l'efficienza: una particolare connessione al database di back-end esegue la query di inizializzazione una volta durante la configurazione, ma potrebbe essere riutilizzata in seguito da molti client. Tieni presente che l'inserimento di istruzioni SQL nella query di inizializzazione non le esclude dal traffico del client. È comunque necessario rimuovere tali istruzioni dal codice dell'applicazione in modo che non interferiscano con il multiplexing.

I filtri di blocco delle sessioni sono una proprietà di configurazione che impedisce al proxy di bloccare determinati stati della sessione. L'unica opzione di filtro attualmente disponibile indica al proxy di ignorare tutte le SET istruzioni per determinare se una sessione debba essere bloccata. EXCLUDE_VARIABLE_SETS Le SET istruzioni vengono comunque trasmesse al database e possono influire sullo stato della sessione, il che significa che questa opzione è sicura solo nelle seguenti situazioni:

  1. Le SET istruzioni non sono operative, ad esempio l'impostazione di una variabile di sistema su un valore identico a quello predefinito del server.

  2. Le SET istruzioni e le query successive fanno parte della stessa transazione e ogni transazione imposta il proprio stato in modo completamente indipendente in modo che non sia influenzata dalle variabili impostate da altre transazioni.

Nota

Il filtro EXCLUDE_VARIABLE_SETS pinning è un'impostazione «tutto o niente» e non è possibile scegliere selettivamente quali istruzioni ignorare. SET Non utilizzate questo filtro come soluzione generale per il bloccaggio, a meno che il vostro caso d'uso non rientri in una delle categorie illustrate nell'elenco precedente.

Per ottenere risultati ottimali, rimuovete le istruzioni non necessarie dal codice dell'applicazione ove possibile e utilizzate i filtri solo se le modifiche all'applicazione non sono possibili. Ciò favorisce un ambiente client-server meno rumoroso e più prevedibile anziché applicare un trattamento speciale alle istruzioni che non sono necessarie in primo luogo.

Importante

Né le query di inizializzazione né i filtri di pinning fanno sì che RDS Proxy modifichi il traffico delle query client-server. Le istruzioni che arrivano dai client vengono comunque trasmesse al database indipendentemente dalla configurazione della query di init o del filtro di pinning.

Per ulteriori informazioni, consulta:

Per le connessioni PostgreSQL, puoi anche inserire i parametri di connessione supportati nel messaggio di avvio scambiato tra il driver client e il proxy. In questo modo si evita l'invio di SET comandi separati, riducendo sia i round trip che il blocco della connessione causato da istruzioni esplicite. SET Per ulteriori informazioni, consulta Considerazioni sulla connessione a PostgreSQL.

Allineamento della configurazione di applicazioni, proxy e database

Come illustrato nella sezione precedente, RDS Proxy supporta una serie di parametri per aiutarvi ad allineare il comportamento del proxy alle esigenze dell'applicazione. Tuttavia, la scelta dei valori di configurazione corretti è un'attività che interessa tutti i livelli dello stack: l'applicazione, il proxy e il database stesso. Le impostazioni di tutti questi componenti devono essere allineate con i seguenti obiettivi in mente:

  1. Fornire il livello di prestazioni e scalabilità previsto durante le normali operazioni.

  2. Promuovi la chiarezza e la facilità di risoluzione dei problemi durante i carichi di lavoro.

  3. Aiuta lo stack a gestire eventi imprevisti (come i picchi di carico di lavoro) con un impatto minimo sull'applicazione.

Quando scegli e ottimizzi le impostazioni in un ambiente a più livelli, prova ad allineare i valori di configurazione in modo che i limiti e i timeout su un livello inferiore siano uguali o superiori ai limiti e ai timeout corrispondenti su un livello superiore. In altre parole, trattate le impostazioni di un livello come un involucro che si inserisce nel successivo involucro di configurazione più in basso nella pila.

Ad esempio, supponiamo che l'applicazione sia il livello superiore, il proxy sia il livello intermedio e il database sia il livello inferiore. Se i timeout e i limiti a livello di proxy sono inferiori ai limiti a livello di applicazione, i limiti del proxy prevalgono sui limiti dell'applicazione. L'applicazione non è in grado di esercitare le sue impostazioni e presenta comportamenti che non possono essere spiegati dalla sua configurazione.

Considerate l'impostazione del IdleClientTimeout proxy come esempio. Se i driver delle applicazioni o i pool di client applicano i propri timeout di inattività, il timeout di inattività del proxy funge da rete di sicurezza che si aggiunge alle impostazioni dell'applicazione. Ciò significa che IdleClientTimeout devono essere almeno uguali a tutti i timeout di inattività a livello di applicazione per evitare confusione:

  • Quando il timeout di inattività dell'applicazione è inferiore al timeout del proxy, ci si aspetta che l'applicazione chiuda le connessioni come configurato. Se l'applicazione non riesce a chiudere le connessioni inattive in modo tempestivo, il proxy funge da backstop.

  • Quando il timeout di inattività dell'applicazione è più lungo del timeout del proxy, l'applicazione potrebbe subire chiusure di connessione considerate premature. Ciò può creare confusione sul lato dell'applicazione.

La stessa logica si applica ad altre impostazioni come i limiti di connessione: le impostazioni di ogni livello devono rientrare nell'involucro definito dalla configurazione del livello successivo.

Per ottenere risultati ottimali, le impostazioni di configurazione dovrebbero includere una certa spaziatura tra un livello e l'altro. Ad esempio, è possibile prolungare di qualche secondo il timeout del proxy rispetto al timeout dell'applicazione per evitare errori sporadici dovuti alla deriva dell' client/server orologio o nel caso in cui il client necessiti di più tempo per chiudere correttamente la connessione.

In altre parole, allinea le impostazioni in questo modo:

client timeout < proxy timeout < database timeout

Invece di farlo:

client timeout = proxy timeout = database timeout

Ed evita questo:

client timeout > proxy timeout > database timeout

Configurazione del database

Limiti di connessioni

RDS Proxy utilizza l'MaxConnectionsPercentimpostazione per determinare la dimensione massima del relativo pool di connessioni, il che significa che la dimensione del pool di connessioni del proxy è relativa al limite di connessione del database. Quando si modifica il limite di connessione del database, segue automaticamente la dimensione del pool del proxy. Se desideri che il database riservi una parte del limite di connessione agli utenti non proxy, dovresti farlo abbassando l'MaxConnectionsPercentimpostazione nel proxy anziché aumentare il limite del database.

Il proxy RDS non elimina la necessità di una corretta configurazione dei limiti di connessione al database. Una singola connessione proxy non è intrinsecamente più leggera di una singola connessione diretta con un client, quindi non aumentate i limiti del database solo perché state utilizzando un proxy. Un proxy non riduce la quantità di lavoro che il database deve svolgere per gestire le query, ma aiuta il database a gestire lo stesso carico di lavoro utilizzando meno connessioni.

Timeout di inattività

I database possono imporre i propri timeout di inattività, ad esempio utilizzando le impostazioni and in MySQL o le wait_timeout impostazioni and interactive_timeout in PostgreSQL. transaction_timeout idle_in_transaction_session_timeout È improbabile che i valori predefiniti per tali impostazioni interferiscano con la configurazione del proxy, ma se utilizzi timeout personalizzati a livello di database, assicurati che siano lunghi almeno quanto i timeout proxy corrispondenti, altrimenti il proxy riscontra errori di connessione dovuti a timeout prematuri.

La stessa logica si applica agli ambienti di database che utilizzano i connection killer, ossia script o processi che monitorano lo stato della sessione e terminano attivamente le connessioni in base a determinati criteri. Se il tuo ambiente utilizza tali tecniche, assicurati che la logica di terminazione della connessione sia in linea con le impostazioni del proxy.

I database che gestiscono tutto il loro carico di lavoro tramite il proxy possono in genere dipendere dalla configurazione del proxy per i timeout di inattività e lasciare le impostazioni a livello di database ai valori predefiniti.

Configurazione dell’applicazione

Gestione dello stato della sessione

Molti driver di database, framework applicativi e strumenti ORM (Object-Relational Mapping) utilizzano variabili o SET istruzioni di sessione per configurare le connessioni prima di inviare il traffico delle query. L'uso delle istruzioni di inizializzazione delle connessioni e delle transazioni potrebbe non essere ovvio se si esamina solo il codice dell'applicazione e possono esserci diversi livelli di astrazione tra il database stesso e le istruzioni SQL e la logica dell'applicazione. È possibile utilizzare la funzionalità di registrazione avanzata del proxy RDS per registrare i motivi del blocco della connessione, mentre i registri delle query del database possono fornire ulteriori informazioni su tutte le istruzioni inviate tramite le connessioni al database.

Prendi in considerazione le seguenti best practice:

  1. Imposta i parametri di connessione solo quando sono diversi dai valori predefiniti del database e la sessione client deve discostarsi da tali valori predefiniti. La rimozione delle istruzioni di inizializzazione non necessarie non solo facilita il multiplexing, ma riduce anche il numero di round trip client-server per ogni nuova connessione al database.

  2. Impostare le variabili e le impostazioni di configurazione in modo coerente su tutte le connessioni.

  3. Evita la configurazione di sessione che può essere applicata anche in fase di esecuzione delle query. Ad esempio, se client diversi devono visualizzare i dati in fusi orari diversi, prendi in considerazione l'utilizzo di funzioni di conversione del fuso orario a livello di query anziché impostare il fuso orario a livello di sessione.

  4. Se possibile, sposta le istruzioni di configurazione della sessione sul livello proxy utilizzando la funzionalità di interrogazione di inizializzazione. Per ulteriori dettagli, consultare Interrogazioni di inizializzazione e filtri di blocco.

Controlli di vivacità

Se la tua applicazione utilizza il pool di connessioni o driver avanzati, cerca la configurazione relativa ai controlli di liveness, come i ping di protocollo, le istruzioni di controllo dello stato di integrità o le query keep-alive. RDS Proxy tratta tutte le richieste dei client allo stesso modo, quindi anche se una SELECT 1; query o una COM_PING richiesta non è operativa dal punto di vista dell'applicazione, impedisce al proxy di imporre i timeout dei client inattivi e di gestire le dimensioni del pool di connessioni in base a. MaxIdleConnectionsPercent

Nota

RDS Proxy impone una durata massima della connessione di 24 ore indipendentemente dall'attività sulla connessione.

Nella maggior parte dei casi, potrebbe essere opportuno disattivare i controlli di liveness sul lato client per ridurre il rumore del protocollo e aiutare RDS Proxy a gestire le connessioni inattive. Ci sono casi limite in cui potresti voler eseguire questi controlli di integrità a prescindere:

  • Volete deliberatamente evitare il timeout di determinate connessioni nel livello proxy.

  • Si desidera consentire al driver o al pool dell'applicazione di rilevare in modo proattivo quando una connessione viene interrotta dal proxy. Ad esempio, le connessioni back-end bloccate potrebbero essere chiuse a causa del riavvio del database e le connessioni client potrebbero superare la durata massima di 24 ore.

Prendi in considerazione la possibilità di disattivare i controlli di liveness sul lato dell'applicazione o eseguili solo per le connessioni specifiche che desideri evitare che si verifichino timeout.

Monitoraggio dello stato della sessione

Alcuni driver di database MySQL, come il driver MariaDB, session_track_* utilizzano variabili per consentire il tracciamento dello stato della sessione. Con questa funzionalità abilitata, ogni volta che il client apporta una modifica dello stato della sessione che il server può tracciare, il server include le informazioni sulla modifica dello stato nei suoi pacchetti di risposta. Ciò consente al driver di essere informato sullo stato della sessione dal server.

Questo modo di tracciare lo stato della sessione può essere utile quando il client interagisce direttamente con il server e implementa le proprie funzionalità di gestione delle sessioni, come la migrazione delle sessioni in ambienti multiserver. RDS Proxy implementa i propri meccanismi di tracciamento dello stato e non utilizza le informazioni abilitate dalle session_track_* variabili, tuttavia l'impostazione di tali variabili causa il blocco della sessione.

Se il driver del database imposta tali variabili, puoi cercare modi per disabilitare la funzionalità di tracciamento nel driver, passare a un driver diverso o utilizzare i filtri di blocco delle sessioni per ignorare le istruzioni, se è sicuro farlo. Per ulteriori dettagli, consultare Interrogazioni di inizializzazione e filtri di blocco.