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

Aurora I miei SQL livelli di isolamento

Scopri come le istanze DB in un cluster Aurora SQL My implementano la proprietà di isolamento del database. Questo argomento spiega in che modo il comportamento SQL predefinito di Aurora My bilancia tra coerenza rigorosa e prestazioni elevate. Puoi utilizzare queste informazioni per decidere quando modificare le impostazioni predefinite in base alle caratteristiche del tuo carico di lavoro.

Livelli di isolamento disponibili per le istanze di scrittura

È possibile utilizzare i livelli di isolamento REPEATABLE READREAD COMMITTED,READ UNCOMMITTED, e SERIALIZABLE sull'istanza principale di un cluster Aurora My SQL DB. Questi livelli di isolamento funzionano allo stesso modo in Aurora My SQL e in RDS for My. SQL

REPEATABLEREADlivello di isolamento per le istanze Reader

Per impostazione predefinita, le istanze Aurora My SQL DB configurate come repliche Aurora di sola lettura utilizzano sempre il livello di isolamento. REPEATABLE READ Queste istanze database ignorano qualsiasi istruzione SET TRANSACTION ISOLATION LEVEL e continuano a usare il livello di isolamento REPEATABLE READ.

Non è possibile impostare il livello di isolamento per le istanze database di lettura utilizzando parametri DB o parametri del cluster database.

READCOMMITTEDlivello di isolamento per le istanze Reader

Se l'applicazione include un carico di lavoro ad alta intensità di scrittura nell'istanza primaria e query a esecuzione prolungata nelle repliche di Aurora, è possibile che si verifichi un notevole ritardo di eliminazione. Un ritardo di eliminazione si verifica quando la garbage collection interna è bloccata da query a esecuzione prolungata. Il sintomo è un valore elevato per history list length nell'output del comando SHOW ENGINE INNODB STATUS. È possibile monitorare questo valore utilizzando la RollbackSegmentHistoryListLength metrica in. CloudWatch Un notevole ritardo dell'eliminazione può ridurre l'efficacia degli indici secondari, diminuire le prestazioni complessive delle query e usare inutilmente lo spazio di archiviazione.

Se si verificano tali problemi, è possibile impostare un'impostazione di configurazione a livello di SQL sessione di Aurora My per utilizzare il READ COMMITTED livello di aurora_read_replica_read_committed isolamento sulle repliche Aurora. L'applicazione di questa impostazione può aiutare a ridurre i rallentamenti e lo spazio usato inutilmente che possono derivare dall'esecuzione di query a esecuzione prolungata contemporaneamente alle transazioni che modificano le tabelle.

Ti consigliamo di assicurarti di comprendere lo specifico SQL comportamento di READ COMMITTED isolamento di Aurora My prima di utilizzare questa impostazione. Il READ COMMITTED comportamento di Aurora Replica è conforme allo standard. ANSI SQL Tuttavia, l'isolamento è meno rigoroso del tipico SQL READ COMMITTED comportamento Mio che potreste conoscere. Pertanto, è possibile visualizzare risultati di query diversi READ COMMITTED in una replica di Aurora My SQL read rispetto a quelli visualizzati per la stessa query READ COMMITTED nell'istanza SQL principale di Aurora My o in for My. RDS SQL Potresti utilizzare l'impostazione aurora_read_replica_read_committed per questi casi d'uso, come un report completo che esegue la scansione di un database molto grande. Potresti invece evitarla per brevi query con piccoli set di risultati, dove la precisione e la ripetibilità sono importanti.

Il livello di isolamento READ COMMITTED non è disponibile per le sessioni all'interno di un cluster secondario in un Aurora Global Database che utilizzano la funzionalità di inoltro di scrittura. Per informazioni sull'inoltro di scrittura, consulta Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora.

Utilizzo per i lettori READ COMMITTED

Per usare il livello di isolamento READ COMMITTED per le repliche di Aurora, configura l'impostazione aurora_read_replica_read_committed su ON. Usa questa impostazione a livello di sessione mentre è connessa a una replica di Aurora specifica. A tale scopo, esegui i seguenti SQL comandi.

set session aurora_read_replica_read_committed = ON;
set session transaction isolation level read committed;

Puoi usare temporaneamente questa impostazione di configurazione per eseguire query interattive una tantum. Potresti anche voler eseguire un'applicazione per la creazione di report o l'analisi dei dati che beneficia del livello di isolamento READ COMMITTED, lasciando invariata l'impostazione predefinita per altre applicazioni.

Quando l'impostazione aurora_read_replica_read_committed è attivata, usa il comando SET TRANSACTION ISOLATION LEVEL per specificare il livello di isolamento per le transazioni appropriate.

set transaction isolation level read committed;

Differenze di READ COMMITTED comportamento sulle repliche Aurora

L'impostazione aurora_read_replica_read_committed rende il livello di isolamento READ COMMITTED disponibile per una replica di Aurora con un comportamento coerente che viene ottimizzato per le transazioni a esecuzione prolungata. Il livello di isolamento READ COMMITTED nelle repliche di Aurora ha un isolamento meno restrittivo di quello nelle istanze primarie di Aurora. Per questo motivo, abilita l'impostazione solo in repliche di Aurora in cui sai che le query possono accettare la possibilità di determinati tipi di risultati incoerenti.

Le tue query possono riscontrare alcuni tipi di anomalie di lettura quando l'impostazione aurora_read_replica_read_committed è attivata. Due tipi di anomalie sono particolarmente importanti per comprendere e gestire il codice dell'applicazione. Una lettura non ripetibile si verifica quando viene eseguita un'altra transazione durante l'esecuzione della query. Una query a esecuzione prolungata può visualizzare dati diversi all'inizio della query rispetto a quelli visualizzati alla fine. Una lettura fantasma si verifica quando altre transazioni causano la riorganizzazione delle righe esistenti mentre la query è in esecuzione e una o più righe vengono lette due volte dalla query.

Le query potrebbero presentare conteggi di riga incoerenti a seguito delle letture fantasma. Le tue query potrebbero anche restituire risultati incompleti o incoerenti a causa delle letture non ripetibili. Ad esempio, si supponga che un'operazione di join si riferisca a tabelle che vengono modificate contemporaneamente da SQL istruzioni come o. INSERT DELETE In questo caso, la query di join potrebbe leggere una riga da una tabella ma non la riga corrispondente da un'altra tabella.

Lo ANSI SQL standard consente entrambi questi comportamenti per il READ COMMITTED livello di isolamento. Tuttavia, questi comportamenti sono diversi dalla tipica SQL implementazione My di. READ COMMITTED Pertanto, prima di abilitare l'aurora_read_replica_read_committedimpostazione, controllate il SQL codice esistente per verificare se funziona come previsto nel modello di consistenza più flessibile.

Il conteggio delle righe e altri risultati potrebbero non essere propriamente coerenti nel livello di isolamento READ COMMITTED mentre questa impostazione è abilitata. Pertanto, in genere abiliti l'impostazione solo durante l'esecuzione di query analitiche che aggregano grandi quantità di dati e non richiedono la precisione assoluta. Se non hai questo tipo di query a esecuzione prolungata insieme a un carico di lavoro ad alta intensità di scrittura, probabilmente non è necessaria l'impostazione aurora_read_replica_read_committed. Senza la combinazione di query a esecuzione prolungata e carico di lavoro ad alta intensità di scrittura, è improbabile che si verifichino problemi con la lunghezza dell'elenco della cronologia.