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

L'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. È possibile utilizzare l'inoltro locale di scrittura quando le applicazioni richiedono read-after-write coerenza, ovvero la capacità di leggere l'ultima scrittura in una transazione.

Le repliche di lettura ricevono aggiornamenti in modo asincrono dall'istanza di scrittura. Senza inoltro di scrittura, è necessario effettuare transazioni di lettura che richiedono read-after-write coerenza sull'istanza Writer DB. 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.

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.

Nella AWS Management Console scheda Configurazione della pagina dei dettagli del cluster, viene visualizzato lo stato Enabled for Local read replica write forwarding.

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

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. Inoltre, le funzioni e le procedure definite dall'utente non sono supportate. 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 Livelli di isolamento di Aurora MySQL.

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 .

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)