Utilizzo dell'inoltro di scrittura locale in un cluster database Amazon Aurora MySQL

Inoltro di scrittura locale (all'interno del cluster) consente alle applicazioni di eseguire transazioni di lettura/scrittura direttamente su una replica di Aurora. Queste transazioni vengono quindi inoltrate all'istanza database di scrittura in attesa che venga eseguito il commit. Puoi utilizzare l'inoltro di scrittura locale quando le applicazioni richiedono la coerenza lettura dopo scrittura, che è la capacità di leggere l'ultima scrittura in una transazione.

Le repliche di lettura ricevono aggiornamenti in modo asincrono dall'istanza di scrittura. Senza l'inoltro di scrittura, è necessario eseguire la transazione delle eventuali letture che richiedono la coerenza lettura dopo scrittura sull'istanza database di scrittura. Oppure è necessario sviluppare una logica dell'applicazione personalizzata complessa per sfruttare più repliche di lettura per la scalabilità. Le applicazioni devono suddividere completamente tutto il traffico in lettura e in scrittura, mantenendo due gruppi di connessioni al database per inviare il traffico all'endpoint corretto. Questi costi di sviluppo complicano la progettazione dell'applicazione quando le query fanno parte di una singola sessione logica, o transazione, all'interno dell'applicazione. Inoltre, poiché il ritardo di replica può variare tra le repliche di lettura, è difficile ottenere una coerenza di lettura globale tra tutte le istanze nel database.

L'inoltro di scrittura evita la necessità di suddividere tali transazioni o inviarle esclusivamente all'istanza di scrittura, semplificando lo sviluppo dell'applicazione. Questa nuova funzionalità consente di ottenere facilmente il dimensionamento della lettura per carichi di lavoro che devono leggere l'ultima scrittura in una transazione e non sono sensibili alla latenza di scrittura.

L'inoltro di scrittura locale è diverso dall'inoltro di scrittura globale, che inoltra le scritture da un cluster database secondario al cluster database primario in un database globale Aurora. Puoi utilizzare l'inoltro di scrittura locale in un cluster database che fa parte di un database globale Aurora. Per ulteriori informazioni, consulta Utilizzo dell'inoltro di scrittura in un database globale Amazon Aurora.

L'inoltro di scrittura locale richiede Aurora MySQL versione 3.04 o successive.

Abilitazione dell'inoltro di scrittura locale

Per impostazione predefinita, l'inoltro di scrittura locale non è abilitato per i cluster database Aurora MySQL. Abilitare l'inoltro di scrittura locale a livello di cluster, non a livello di istanza.

aws rds create-db-cluster \
  --db-cluster-identifier write-forwarding-test-cluster \
  --enable-local-write-forwarding \
  --engine aurora-mysql \
  --engine-version 8.0.mysql_aurora.3.04.0 \
  --master-username myuser \
  --master-user-password mypassword \
  --backup-retention 1

Abilitazione dell'inoltro di scrittura per le sessioni di database

Il parametro aurora_replica_read_consistency è un parametro database e un parametro del cluster database che abilita l'inoltro di scrittura. È possibile specificare EVENTUAL, SESSION o GLOBAL per il livello di coerenza di lettura. Per ulteriori informazioni sui livelli di coerenza, consulta Coerenza di lettura per l'inoltro di scrittura.

A questo parametro si applicano le seguenti regole:

Verifica se l'inoltro di scrittura è abilitato un cluster database

Per determinare se è possibile utilizzare l'inoltro di scrittura in un cluster database, verifica che l'attributo LocalWriteForwardingStatus del cluster sia impostato su enabled.

In AWS Management Console, nella scheda Configurazione della pagina dei dettagli del cluster, viene visualizzato lo stato Abilitato per Inoltro di scrittura locale di replica di lettura.

Per visualizzare lo stato dell'impostazione di inoltro di scrittura per tutti i cluster, esegui il comando AWS CLI seguente.

aws rds describe-db-clusters \
--query '*[].{DBClusterIdentifier:DBClusterIdentifier,LocalWriteForwardingStatus:LocalWriteForwardingStatus}'

[
    {
        "LocalWriteForwardingStatus": "enabled",
        "DBClusterIdentifier": "write-forwarding-test-cluster-1"
    },
    {
        "LocalWriteForwardingStatus": "disabled",
        "DBClusterIdentifier": "write-forwarding-test-cluster-2"
    },
    {
        "LocalWriteForwardingStatus": "requested",
        "DBClusterIdentifier": "test-global-cluster-2"
    },
    {
        "LocalWriteForwardingStatus": "null",
        "DBClusterIdentifier": "aurora-mysql-v2-cluster"
    }
]

Un cluster database può avere i seguenti valori per LocalWriteForwardingStatus:

Compatibilità delle applicazioni e di SQL con l'inoltro di scrittura

È possibile utilizzare i seguenti tipi di istruzioni SQL con l'inoltro di scrittura:

Alcune istruzioni non sono consentite o possono produrre risultati non aggiornati quando vengono utilizzate in un cluster database con inoltro di scrittura. Pertanto, l'impostazione EnableLocalWriteForwarding è disabilitata per impostazione predefinita per i cluster database. Prima di abilitarla, verificare che il codice dell'applicazione non sia interessato da nessuna di queste restrizioni.

Le seguenti restrizioni si applicano alle istruzioni SQL utilizzate con l'inoltro di scrittura. In alcuni casi, è possibile utilizzare le istruzioni su cluster database con inoltro di scrittura abilitato. Questo approccio funziona se l'inoltro di scrittura non è abilitato all'interno della sessione dal parametro di configurazione aurora_replica_read_consistency. Se si prova a utilizzare un'istruzione quando non è consentita a causa dell'inoltro di scrittura, verrà visualizzato un messaggio di errore simile al seguente:

ERROR 1235 (42000): This version of MySQL doesn't yet support 'operation with write forwarding'.

Livelli di isolamento per l'inoltro di scrittura

Nelle sessioni che utilizzano l'inoltro di scrittura, è possibile utilizzare solo il livello di isolamento REPEATABLE READ. Sebbene sia possibile utilizzare il livello di isolamento READ COMMITTED anche con repliche di Aurora, questa operazione non funziona con l'inoltro di scrittura. Per informazioni sui livelli di isolamento REPEATABLE READ e READ COMMITTED, consulta Aurora I miei SQL livelli di isolamento.

Coerenza di lettura per l'inoltro di scrittura

È possibile controllare il grado di coerenza di lettura in un cluster database. Il livello di coerenza di lettura determina il tempo di attesa di un cluster database prima di ogni operazione di lettura per garantire che alcune o tutte le modifiche vengano replicate dall'istanza di scrittura. È possibile regolare il livello di coerenza di lettura per garantire che tutte le operazioni di scrittura inoltrate dalla sessione siano visibili nel cluster database prima di qualsiasi query successiva. Inoltre, è possibile utilizzare questa impostazione per garantire che le query sul cluster database visualizzino sempre gli aggiornamenti più recenti dall'istanza di scrittura. Questa impostazione si applica anche alle query inviate da altre sessioni o da altri cluster. Per specificare questo tipo di comportamento per l'applicazione, scegli un valore per il parametro database aurora_replica_read_consistency o il parametro cluster database.

All'aumentare del livello di coerenza, l'applicazione rimane più tempo in attesa della propagazione delle modifiche tra le istanze database. È possibile scegliere il giusto equilibrio tra tempi di risposta rapidi e garanzia che le modifiche apportate in altre istanze database siano completamente disponibili prima dell'esecuzione delle query.

È possibile specificare i valori seguenti per il parametro aurora_replica_read_consistency:

Per informazioni su tutti i parametri di configurazione coinvolti nell'inoltro di scrittura, consulta Parametri di configurazione per l'inoltro di scrittura.

mysql> set aurora_replica_read_consistency = 'session';

Esempi di utilizzo dell'inoltro di scrittura

Negli esempi seguenti vengono illustrati gli effetti del parametro aurora_replica_read_consistency sull'esecuzione delle istruzioni INSERT seguite dalle istruzioni SELECT. I risultati possono variare, a seconda del valore di aurora_replica_read_consistency e della tempistica delle istruzioni.

Per ottenere una maggiore coerenza, è possibile attendere brevemente prima di rilasciare l’istruzione SELECT. Oppure Aurora può attendere automaticamente il completamento della replica dei risultati prima di procedere con SELECT.

Per informazioni sull'impostazione dei parametri database, consulta .

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)

mysql> insert into t1 values (6); select count(*) from t1;
+----------+
| count(*) |
+----------+
|        5 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        6 |
+----------+
1 row in set (0.01 sec)

mysql> insert into t1 values (6); select count(*) from t1; select count(*) from t1;
Query OK, 1 row affected (0.08 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.37 sec)
+----------+
| count(*) |
+----------+
|        7 |
+----------+
1 row in set (0.00 sec)

mysql> insert into t1 values (6); select sleep(2); select count(*) from t1;
Query OK, 1 row affected (0.07 sec)
+----------+
| sleep(2) |
+----------+
|        0 |
+----------+
1 row in set (2.01 sec)
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.00 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.75 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.37 sec)

mysql> select count(*) from t1;
+----------+
| count(*) |
+----------+
|        8 |
+----------+
1 row in set (0.66 sec)

Esecuzione di istruzioni a più parti con inoltro scrittura

Un'istruzione DML può essere costituita da più parti, ad esempio un'istruzione INSERT ... SELECT o un'istruzione DELETE ... WHERE. In questo caso, l'intera istruzione viene inoltrata all'istanza database di scrittura ed eseguita lì.

Transazioni con inoltro di scrittura

Se la modalità di accesso alle transazioni è impostata su sola lettura, l'inoltro di scrittura non viene utilizzato. È possibile specificare la modalità di accesso per la transazione utilizzando l'istruzione SET TRANSACTION o START TRANSACTION. È anche possibile specificare la modalità di accesso alle transazioni modificando il valore della variabile di sessione transaction_read_only. È possibile modificare questo valore di sessione solo quando si è connessi a un cluster database in cui l'inoltro di scrittura è abilitato.

Se una transazione di lunga durata non emette alcuna dichiarazione per un periodo di tempo considerevole, potrebbe superare il periodo di timeout inattivo. Questo periodo ha un valore predefinito di un minuto. È possibile impostare il parametro aurora_fwd_writer_idle_timeout per aumentarlo fino a un giorno. Una transazione che supera il timeout di inattività viene annullata dall'istanza di scrittura. L'istruzione successiva inviata riceve un errore di timeout. Quindi Aurora esegue il rollback della transazione.

Questo tipo di errore può verificarsi in altri casi in cui l'inoltro di scrittura non diventa disponibile. Ad esempio, Aurora annulla le eventuali transazioni che utilizzano l'inoltro di scrittura se si riavvia il cluster database o si disabilita l'inoltro di scrittura.

Quando un'istanza di scrittura in un cluster che utilizza l'inoltro di scrittura locale viene riavviata, le eventuali transazioni e query attive, inoltrate sulle istanze di lettura che utilizzano l'inoltro di scrittura locale vengono chiuse automaticamente. Dopo che l'istanza di scrittura sarà nuovamente disponibile, è possibile riprovare a eseguire queste transazioni.

Parametri di configurazione per l'inoltro di scrittura

I gruppi di parametri database Aurora contengono impostazioni per la funzionalità di inoltro di scrittura. I dettagli su questi parametri sono riepilogati nella tabella seguente, con note di utilizzo dopo la tabella.

Per controllare le richieste di scrittura in entrata, usare queste impostazioni:

Per ulteriori informazioni su aurora_replica_read_consistency, consulta Coerenza di lettura per l'inoltro di scrittura.

Per ulteriori informazioni sui gruppi di parametri database, consulta .

Parametri di Amazon CloudWatch e variabili di stato di Aurora MySQL per l'inoltro di scrittura

I parametri Amazon CloudWatch e le variabili di stato Aurora MySQL seguenti si applicano quando si utilizza l'inoltro di scrittura su uno o più cluster database. Questi parametri e variabili di stato vengono tutti misurati sull'istanza database di scrittura.

I seguenti parametri CloudWatch e le variabili di stato Aurora MySQL vengono misurati su ciascuna istanza database di lettura in un cluster database con l'inoltro di scrittura abilitato.

Identificazione delle transazioni e delle query inoltrate

È possibile usare la tabella information_schema.aurora_forwarding_processlist per identificare le transazioni e le query inoltrate. Per ulteriori informazioni su questa tabella, consultare information_schema.aurora_forwarding_processlist.

L'esempio seguente mostra tutte le connessioni inoltrate su un'istanza database di scrittura.

mysql> select * from information_schema.AURORA_FORWARDING_PROCESSLIST where IS_FORWARDED=1 order by REPLICA_SESSION_ID;

+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
| ID  | USER     | HOST               | DB       | COMMAND | TIME | STATE        | INFO                                       | IS_FORWARDED | REPLICA_SESSION_ID | REPLICA_INSTANCE_IDENTIFIER     | REPLICA_CLUSTER_NAME | REPLICA_REGION |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+---------------------------------------+
| 648 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest58 SET k=k+1 WHERE id=4802579 |            1 |                637 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
| 650 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest54 SET k=k+1 WHERE id=2503953 |            1 |                639 | my-db-cluster-instance-2        | my-db-cluster        | us-west-2      |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+

Nell'istanza database di lettura di inoltro, è possibile visualizzare i thread associati a queste connessioni database di scrittura eseguendoSHOW PROCESSLIST. Il valori REPLICA_SESSION_ID sull'istanza di scrittura, 637 e 639, sono identici ai valoriId sull'istanza di lettura.

mysql> select @@aurora_server_id;

+---------------------------------+
| @@aurora_server_id              |
+---------------------------------+
| my-db-cluster-instance-2        |
+---------------------------------+
1 row in set (0.00 sec)

mysql> show processlist;

+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| Id  | User     | Host               | db       | Command | Time | State        | Info                                        |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
| 637 | myuser   | IP_address:port1   | sysbench | Query   |    0 | async commit | UPDATE sbtest12 SET k=k+1 WHERE id=4802579  |
| 639 | myuser   | IP_address:port2   | sysbench | Query   |    0 | async commit | UPDATE sbtest61 SET k=k+1 WHERE id=2503953  |
+-----+----------+--------------------+----------+---------+------+--------------+---------------------------------------------+
12 rows in set (0.00 sec)