Evitare di effettuare il pinning di un Server proxy per RDS - Amazon Aurora
Istruzioni tracciate da Server proxy per RDS per database Aurora MySQLRiduzione dell'associazioneCondizioni che causano il pinning per tutte le famiglie di motoriCondizioni che causano l'associazione per Aurora MySQLCondizioni che causano l'associazione per Aurora PostgreSQL

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

Evitare di effettuare il pinning di un Server proxy per 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, Server proxy per RDS non applica il pinning alla sessione quando si effettuano queste modifiche. 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

Di seguito sono riportate le istruzioni MySQL di cui Server proxy per RDS tiene traccia:

  • DROP DATABASE

  • DROP SCHEMA

  • USE

Di seguito sono riportate le variabili MySQL di cui Server proxy per RDS tiene traccia:

  • 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

Server proxy per RDS tiene traccia delle modifiche alle variabili TRANSACTION_ISOLATION e TRANSACTION_READ_ONLY quando le imposti nell’ambito della sessione. Tuttavia, se le imposti nell’ambito della transazione successiva, Proxy RDS blocca le connessioni. Questo comportamento si applica sia che si utilizzi un’istruzione SET o un’istruzione SET TRANSACTION 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.

  • Vedi la frequenza con cui si verifica l'associazione monitorando la metrica Amazon CloudWatch DatabaseConnectionsCurrentlySessionPinned. Per informazioni su questa e altri parametri CloudWatch, consulta Monitoraggio dei parametri RDS Proxy 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 RDS Proxy 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 una variabile di sistema (con alcune eccezioni) effettua il pinning al proxy. Se ciò limita in modo significativo il riutilizzo della connessione, è possibile configurare le operazioni SET per evitare il pinning. A tale scopo, regolate la proprietà dei filtri di blocco della sessione. Per ulteriori informazioni, consulta Creazione di un proxy per Amazon Aurora 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.

  • Le chiamate delle funzioni ROW_COUNT e FOUND_ROWS talvolta causano il pinning.

    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 cambi lo stato della sessione all’interno delle routine memorizzate se si fa affidamento su tale stato di sessione per persistere tra le transazioni. Ad esempio, Server proxy per RDS non è attualmente compatibile con una stored procedure crea una tabella temporanea che persiste tra 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:

  • L’utilizzo dei comandi SET.

  • Utilizzo dei comandi PREPARE, DISCARD, DEALLOCATE o EXECUTE per gestire le istruzioni preparate.

  • Creazione di sequenze temporanee, tabelle o viste.

  • Dichiarazione dei cursori.

  • Eliminazione dello stato della sessione.

  • Ascolto su un canale di notifica.

  • Caricamento di un modulo di libreria come auto_explain.

  • Manipolazione delle sequenze usando funzioni come nextval e setval.

  • Interazione con i blocchi utilizzando funzioni come pg_advisory_lock e pg_try_advisory_lock.

    Nota

    Server proxy per RDS non prevede blocchi di consulenza a livello di transazione, in particolare pg_advisory_xact_lock, pg_advisory_xact_lock_shared, pg_try_advisory_xact_lock e pg_try_advisory_xact_lock_shared.

  • Impostazione di un parametro o reimpostazione di un parametro sul valore predefinito. In particolare, utilizzo dei comandi SET e set_config 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 cambi lo stato della sessione all’interno delle routine memorizzate se si fa affidamento su tale stato di sessione per persistere tra le transazioni. Ad esempio, Server proxy per RDS non è attualmente compatibile con una stored procedure crea una tabella temporanea che persiste tra tutte le transazioni.

  • Eliminazione dello stato della sessione. Se si utilizzano librerie di connection pooling con una query DISCARD ALL configurata come query di ripristino, Server proxy per RDS blocca la connessione client al momento del rilascio. Ciò riduce l’efficienza del multiplexing del proxy e potrebbe portare a risultati imprevisti perché il comando DISCARD ALL può interferire con la gestione dello stato della sessione.