Evitare il blocco di un proxy RDS

Il multiplexing è più efficiente quando le richieste del database non si basano su informazioni di stato provenienti da richieste precedenti. In tal caso, RDS Proxy può riutilizzare una connessione alla conclusione di ogni transazione. Esempi di tali informazioni sullo stato includono la maggior parte delle variabili e dei parametri di configurazione che puoi modificare attraverso le istruzioni SET o SELECT. Le transazioni SQL su una connessione client possono eseguire il multiplex tra le connessioni di database sottostanti per impostazione predefinita.

Le connessioni al proxy possono entrare in uno stato noto come pinning. Quando una connessione viene bloccata, ogni transazione successiva utilizza la stessa connessione al database sottostante fino al termine della sessione. Altre connessioni client, inoltre, non possono riutilizzare tale connessione al database fino al termine della sessione. La sessione termina quando viene interrotta la connessione client.

RDS Proxy collega automaticamente una connessione client a una specifica connessione DB quando rileva una modifica dello stato della sessione che non è appropriata per altre sessioni. Il pinning riduce l'efficacia del riutilizzo della connessione. Se tutte o quasi tutte le connessioni riscontrano il pinning, potresti modificare il codice dell'applicazione o il carico di lavoro per ridurre le condizioni che causano il blocco.

Ad esempio, l'applicazione modifica una variabile di sessione o un parametro di configurazione. In questo caso, le istruzioni successive possono basarsi sulla nuova variabile o sul nuovo parametro per essere effettive. Pertanto, quando RDS Proxy elabora le richieste di modifica delle variabili di sessione o delle impostazioni di configurazione, il medesimo effettua il pinning di tale sessione alla connessione DB. In questo modo, lo stato della sessione rimane attivo per tutte le transazioni successive nella stessa sessione.

Per alcuni motori di database, questa regola non si applica a tutti i parametri che puoi impostare. RDS Proxy tiene traccia di determinate istruzioni e variabili. Pertanto, RDS Proxy non blocca la sessione quando la modificate. In tal caso, RDS Proxy riutilizza la connessione solo per altre sessioni con gli stessi valori per tali impostazioni. Per gli elenchi delle istruzioni e delle variabili tracciate per Aurora MySQL, consulta Istruzioni tracciate da Server proxy per RDS per database Aurora MySQL.

Istruzioni tracciate da Server proxy per RDS per database Aurora MySQL

RDS Proxy tiene traccia delle seguenti istruzioni MySQL:

• DROP DATABASE

• DROP SCHEMA

• USE

RDS Proxy tiene traccia delle seguenti variabili MySQL:

• AUTOCOMMIT

• AUTO_INCREMENT_INCREMENT

• CHARACTER SET (or CHAR SET)

• CHARACTER_SET_CLIENT

• CHARACTER_SET_DATABASE

• CHARACTER_SET_FILESYSTEM

• CHARACTER_SET_CONNECTION

• CHARACTER_SET_RESULTS

• CHARACTER_SET_SERVER

• COLLATION_CONNECTION

• COLLATION_DATABASE

• COLLATION_SERVER

• INTERACTIVE_TIMEOUT

• NAMES

• NET_WRITE_TIMEOUT

• QUERY_CACHE_TYPE

• SESSION_TRACK_SCHEMA

• SQL_MODE

• TIME_ZONE

• TRANSACTION_ISOLATION (or TX_ISOLATION)

• TRANSACTION_READ_ONLY (or TX_READ_ONLY)

• WAIT_TIMEOUT

Nota

RDS Proxy tiene traccia delle modifiche alle TRANSACTION_READ_ONLY variabili TRANSACTION_ISOLATION and quando le imposti nell'ambito della sessione. Tuttavia, se le imposti nell'ambito della transazione successiva, il proxy RDS blocca le connessioni. Questo comportamento si applica sia che si utilizzi un'SETistruzione o un'SET TRANSACTIONistruzione per configurare questi valori.

Riduzione dell'associazione

L'ottimizzazione delle prestazioni di RDS Proxy comporta il tentativo di massimizzare il riutilizzo della connessione a livello di transazione (multiplexing) riducendo al minimo il pinning.

È possibile ridurre l'associazione effettuando le seguenti operazioni:

• Evitare richieste di database non necessarie che potrebbero causare il pinning.

• Impostare le variabili e le impostazioni di configurazione in modo coerente su tutte le connessioni. In questo modo, le sessioni successive hanno maggiori probabilità di riutilizzare le connessioni con quelle specifiche impostazioni.

  Tuttavia, per l'impostazione di PostgreSQL una variabile porterà al pinning della sessione.

• Per un database della famiglia di motori MySQL, applica un filtro di pinning della sessione al proxy. Puoi esentare determinati tipi di operazioni dal pinning della sessione se sai che tale operazione non influisce sul corretto funzionamento dell'applicazione.

• Scopri con quale frequenza si verifica il pinning monitorando la CloudWatch metrica DatabaseConnectionsCurrentlySessionPinned di Amazon. Per informazioni su questa e altri parametri CloudWatch, consulta Monitoraggio dei parametri del proxy RDS con Amazon CloudWatch.

• Se utilizzi istruzioni SET per eseguire l'inizializzazione identica per ogni connessione client, puoi farlo pur mantenendo il multiplexing a livello di transazione. In questo caso, sposta le istruzioni che impostano lo stato della sessione iniziale nella query di inizializzazione utilizzata da un proxy. Questa proprietà è una stringa contenente una o più istruzioni SQL, separate da punto e virgola.

  Ad esempio, puoi definire una query di inizializzazione per un proxy che imposta determinati parametri di configurazione. Quindi, RDS Proxy applica tali impostazioni ogni volta che imposta una nuova connessione per tale proxy. Puoi rimuovere le istruzioni SET corrispondenti dal codice dell'applicazione, in modo che non interferiscano con il multiplexing a livello di transazione.

  Per visualizzare i parametri sulla frequenza con cui si verifica il pinning in relazione a un proxy, consulta Monitoraggio dei parametri del proxy RDS con Amazon CloudWatch.

Condizioni che causano il pinning per tutte le famiglie di motori

Il proxy effettua il pinning della sessione alla connessione corrente nelle seguenti situazioni in cui il multiplexing potrebbe causare un comportamento imprevisto:

• Qualsiasi istruzione con una dimensione del testo maggiore di 16 KB fa sì che il proxy effettui il pinning della sessione.

Condizioni che causano l'associazione per Aurora MySQL

Per PostgreSQL, anche le seguenti interazioni causano il pinning:

• Le dichiarazioni di blocco esplicito delle tabelle LOCK TABLE, LOCK TABLES o FLUSH TABLES WITH READ LOCK causano il pinning della sessione da parte del proxy.

• La creazione di blocchi denominati mediante GET_LOCK fa sì che il proxy esegua il pinning della sessione.

• L'impostazione di una variabile utente o di sistema (con alcune eccezioni) associa la sessione al proxy. Se ciò limita in modo significativo il riutilizzo della connessione, è possibile configurare SET le operazioni per evitare il blocco. A tale scopo, regolate la proprietà dei filtri di blocco della sessione. Per ulteriori informazioni, consulta Creazione di un proxy per e Modifica di un RDS Proxy.

• La creazione di una tabella temporanea fa sì che il proxy effettui il pinning della sessione. In questo modo, il contenuto della tabella temporanea viene conservato per tutta la sessione indipendentemente dai limiti delle transazioni.

• La chiamata alle FOUND_ROWS funzioni ROW_COUNT and a volte causa il blocco.

  Le circostanze esatte in cui queste funzioni causano il blocco potrebbero differire tra le versioni Aurora MySQL compatibili con MySQL 5.7.

• Le istruzioni preparate fanno sì che il proxy effettui il pinning della sessione. Questa regola si applica se l'istruzione preparata utilizza il testo SQL o il protocollo binario.

• RDS Proxy non blocca le connessioni quando si utilizza SET LOCAL.

• Le chiamate di stored procedure e di funzioni archiviate non causano il pinning. RDS Proxy non rileva alcuna modifica dello stato della sessione derivante da tali chiamate. Assicurati che l'applicazione non modifichi lo stato della sessione all'interno delle routine archiviate se fai affidamento su quello stato della sessione per persistere tra le transazioni. Ad esempio, RDS Proxy non è attualmente compatibile con una stored procedure che crea una tabella temporanea che persiste in tutte le transazioni.

Se disponi di un'approfondita conoscenza del comportamento dell'applicazione, puoi scegliere di ignorare il comportamento del pinning per determinate istruzioni dell'applicazione. A tale scopo, puoi selezionare l'opzione (Filtri di pinning della sessione durante la creazione del proxy. Attualmente, è possibile disattivare l'aggiunta della sessione per l'impostazione delle variabili di sessione e delle impostazioni di configurazione.

Condizioni che causano l'associazione per Aurora PostgreSQL

Per PostgreSQL, le seguenti interazioni causano anche il pinning:

• Utilizzo dei comandiSET.

• Utilizzo diPREPARE, DISCARDDEALLOCATE, o EXECUTE comandi per gestire le istruzioni preparate.

• Creazione di sequenze, tabelle o viste temporanee.

• Dichiarazione dei cursori.

• Eliminare lo stato della sessione.

• Ascolto su un canale di notifica.

• Caricamento di un modulo di libreria comeauto_explain.

• Manipolazione di sequenze utilizzando funzioni come e. nextval setval

• Interazione con le serrature utilizzando funzioni come e. pg_advisory_lock pg_try_advisory_lock

  Nota

  RDS Proxy non prevede blocchi consultivi a livello di transazione, in particolarepg_advisory_xact_lock,, e. pg_advisory_xact_lock_shared pg_try_advisory_xact_lock pg_try_advisory_xact_lock_shared

• Impostazione di un parametro o ripristino dei valori predefiniti di un parametro. In particolare, utilizzo dei set_config comandi SET and per assegnare valori predefiniti alle variabili di sessione.

• Le chiamate di stored procedure e di funzioni archiviate non causano il pinning. RDS Proxy non rileva alcuna modifica dello stato della sessione derivante da tali chiamate. Assicurati che l'applicazione non modifichi lo stato della sessione all'interno delle routine archiviate se fai affidamento su quello stato della sessione per persistere tra le transazioni. Ad esempio, RDS Proxy non è attualmente compatibile con una stored procedure che crea una tabella temporanea che persiste in tutte le transazioni.