# Using local write forwarding in an Amazon Aurora MySQL DB cluster
<a name="aurora-mysql-write-forwarding"></a>

*Local (in-cluster) write forwarding* allows your applications to issue read/write transactions directly on an Aurora Replica. These transactions are then forwarded to the writer DB instance to be committed. You can use local write forwarding when your applications require *read-after-write consistency*, which is the ability to read the latest write in a transaction.

Read replicas receive updates asynchronously from the writer. Without write forwarding, you have to transact any reads that require read-after-write consistency on the writer DB instance. Or you have to develop complex custom application logic to take advantage of multiple read replicas for scalability. Your applications must fully split all read and write traffic, maintaining two sets of database connections to send the traffic to the correct endpoint. This development overhead complicates application design when the queries are part of a single logical session, or transaction, within the application. Moreover, because replication lag can differ among read replicas, it's difficult to achieve global read consistency across all instances in the database.

Write forwarding avoids the need to split those transactions or send them exclusively to the writer, which simplifies application development. This new capability makes it easy to achieve read scale for workloads that need to read the latest write in a transaction and aren't sensitive to write latency.

Local write forwarding is different from global write forwarding, which forwards writes from a secondary DB cluster to the primary DB cluster in an Aurora global database. You can use local write forwarding in a DB cluster that is part of an Aurora global database. For more information, see [Using write forwarding in an Amazon Aurora global database](aurora-global-database-write-forwarding.md).

Local write forwarding requires Aurora MySQL version 3.04 or higher.

**Topics**
+ [Enabling local write forwarding](aurora-mysql-write-forwarding-enabling.md)
+ [Checking if a DB cluster has write forwarding enabled](#aurora-mysql-write-forwarding-describing)
+ [Application and SQL compatibility with write forwarding](#aurora-mysql-write-forwarding-compatibility)
+ [Isolation levels for write forwarding](#aurora-mysql-write-forwarding-isolation)
+ [Read consistency for write forwarding](aurora-mysql-write-forwarding-consistency.md)
+ [Running multipart statements with write forwarding](#aurora-mysql-write-forwarding-multipart)
+ [Transactions with write forwarding](#aurora-mysql-write-forwarding-txns)
+ [Configuration parameters for write forwarding](#aurora-mysql-write-forwarding-params)
+ [Amazon CloudWatch metrics and Aurora MySQL status variables for write forwarding](aurora-mysql-write-forwarding-cloudwatch.md)
+ [Identifying forwarded transactions and queries](#aurora-write-forwarding-processlist)

# Enabling local write forwarding
<a name="aurora-mysql-write-forwarding-enabling"></a>

By default, local write forwarding isn't enabled for Aurora MySQL DB clusters. You enable local write forwarding at the cluster level, not at the instance level.

**Important**  
You can also enable local write forwarding for cross-Region read replicas that use binary logging, but write operations aren't forwarded to the source AWS Region. They're forwarded to the writer DB instance of the binlog read replica cluster.  
Use this method only if you have a use case for writing to the binlog read replica in the secondary AWS Region. Otherwise, you might end up with a "split-brain" scenario where replicated datasets are inconsistent with each other.   
We recommend that you use global write forwarding with global databases, rather than local write forwarding on cross-Region read replicas, unless absolutely necessary. For more information, see [Using write forwarding in an Amazon Aurora global database](aurora-global-database-write-forwarding.md).

## Console
<a name="aurora-mysql-write-forwarding-enabling.CON"></a>

Using the AWS Management Console, select the **Turn on local write forwarding** check box under **Read replica write forwarding** when you create or modify a DB cluster.

## AWS CLI
<a name="aurora-mysql-write-forwarding-enabling.CLI"></a>

To enable write forwarding with the AWS CLI, use the `--enable-local-write-forwarding` option. This option works when you create a new DB cluster using the `create-db-cluster` command. It also works when you modify an existing DB cluster using the `modify-db-cluster` command. You can disable write forwarding by using the `--no-enable-local-write-forwarding` option with these same CLI commands.

The following example creates an Aurora MySQL DB cluster with write forwarding enabled.

```
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
```

You then create writer and reader DB instances so that you can use write forwarding. For more information, see [Creating an Amazon Aurora DB cluster](Aurora.CreateInstance.md).

## RDS API
<a name="aurora-mysql-write-forwarding-enabling.API"></a>

To enable write forwarding using the Amazon RDS API, set the `EnableLocalWriteForwarding` parameter to `true`. This parameter works when you create a new DB cluster using the `CreateDBCluster` operation. It also works when you modify an existing DB cluster using the `ModifyDBCluster` operation. You can disable write forwarding by setting the `EnableLocalWriteForwarding` parameter to `false`.

## Enabling write forwarding for database sessions
<a name="aurora-mysql-write-forwarding-enabling-session"></a>

The `aurora_replica_read_consistency` parameter is a DB parameter and DB cluster parameter that enables write forwarding. You can specify `EVENTUAL`, `SESSION`, or `GLOBAL` for the read consistency level. To learn more about consistency levels, see [Read consistency for write forwarding](aurora-mysql-write-forwarding-consistency.md). 

The following rules apply to this parameter:
+ The default value is '' (null).
+ Write forwarding is available only if you set `aurora_replica_read_consistency` to `EVENTUAL`, `SESSION`, or `GLOBAL`. This parameter is relevant only in reader instances of DB clusters that have write forwarding enabled.
+ You can't set this parameter (when empty) or unset it (when already set) inside a multistatement transaction. You can change it from one valid value to another valid value during such a transaction, but we don't recommend this action.

## Checking if a DB cluster has write forwarding enabled
<a name="aurora-mysql-write-forwarding-describing"></a>

To determine that you can use write forwarding in a DB cluster, confirm that the cluster has the attribute `LocalWriteForwardingStatus` set to `enabled`.

In the AWS Management Console, on the **Configuration** tab of the details page for the cluster, you see the status **Enabled** for **Local read replica write forwarding**.

To see the status of the write forwarding setting for all of your clusters, run the following AWS CLI command.

**Example**  

```
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"
    }
]
```

A DB cluster can have the following values for `LocalWriteForwardingStatus`:
+ `disabled` – Write forwarding is disabled.
+ `disabling` – Write forwarding is in the process of being disabled.
+ `enabled` – Write forwarding is enabled.
+ `enabling` – Write forwarding is in the process of being enabled.
+ `null` – Write forwarding isn't available for this DB cluster.
+ `requested` – Write forwarding has been requested, but is not yet active.

## Application and SQL compatibility with write forwarding
<a name="aurora-mysql-write-forwarding-compatibility"></a>

You can use the following kinds of SQL statements with write forwarding:
+ Data manipulation language (DML) statements, such as `INSERT`, `DELETE`, and `UPDATE`. There are some restrictions on the properties of these statements that you can use with write forwarding, as described following.
+ `SELECT ... LOCK IN SHARE MODE` and `SELECT FOR UPDATE` statements.
+ `PREPARE` and `EXECUTE` statements.

Certain statements aren't allowed or can produce stale results when you use them in a DB cluster with write forwarding. In addition, user defined functions and user defined procedures aren't supported. Thus, the `EnableLocalWriteForwarding` setting is disabled by default for DB clusters. Before enabling it, check to make sure that your application code isn't affected by any of these restrictions.

The following restrictions apply to the SQL statements you use with write forwarding. In some cases, you can use the statements on DB clusters with write forwarding enabled. This approach works if write forwarding isn't enabled within the session by the `aurora_replica_read_consistency` configuration parameter. If you try to use a statement when it's not allowed because of write forwarding, then you will see an error message similar to the following:

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

**Data definition language (DDL)**  
Connect to the writer DB instance to run DDL statements. You can't run them from reader DB instances.

**Updating a permanent table using data from a temporary table**  
You can use temporary tables on DB clusters with write forwarding enabled. However, you can't use a DML statement to modify a permanent table if the statement refers to a temporary table. For example, you can't use an `INSERT ... SELECT` statement that takes the data from a temporary table.

**XA transactions**  
You can't use the following statements on a DB cluster when write forwarding is enabled within the session. You can use these statements on DB clusters that don't have write forwarding enabled, or within sessions where the `aurora_replica_read_consistency` setting is empty. Before enabling write forwarding within a session, check if your code uses these statements.  

```
XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER [CONVERT XID]
```

**LOAD statements for permanent tables**  
You can't use the following statements on a DB cluster with write forwarding enabled.  

```
LOAD DATA INFILE 'data.txt' INTO TABLE t1;
LOAD XML LOCAL INFILE 'test.xml' INTO TABLE t1;
```

**Plugin statements**  
You can't use the following statements on a DB cluster with write forwarding enabled.  

```
INSTALL PLUGIN example SONAME 'ha_example.so';
UNINSTALL PLUGIN example;
```

**SAVEPOINT statements**  
You can't use the following statements on a DB cluster when write forwarding is enabled within the session. You can use these statements on DB clusters that don't have write forwarding enabled, or within sessions where the `aurora_replica_read_consistency` setting is blank. Check if your code uses these statements before enabling write forwarding within a session.  

```
SAVEPOINT t1_save;
ROLLBACK TO SAVEPOINT t1_save;
RELEASE SAVEPOINT t1_save;
```

## Isolation levels for write forwarding
<a name="aurora-mysql-write-forwarding-isolation"></a>

In sessions that use write forwarding, you can only use the `REPEATABLE READ` isolation level. Although you can also use the `READ COMMITTED` isolation level with Aurora Replicas, that isolation level doesn't work with write forwarding. For information about the `REPEATABLE READ` and `READ COMMITTED` isolation levels, see [Aurora MySQL isolation levels](AuroraMySQL.Reference.IsolationLevels.md).

# Read consistency for write forwarding
<a name="aurora-mysql-write-forwarding-consistency"></a>

You can control the degree of read consistency on a DB cluster. The read consistency level determines how long the DB cluster waits before each read operation to ensure that some or all changes are replicated from the writer. You can adjust the read consistency level to make sure that all forwarded write operations from your session are visible in the DB cluster before any subsequent queries. You can also use this setting to make sure that queries on the DB cluster always see the most current updates from the writer. This setting also applies to queries submitted by other sessions or other clusters. To specify this type of behavior for your application, choose a value for the `aurora_replica_read_consistency` DB parameter or DB cluster parameter.

**Important**  
Always set the `aurora_replica_read_consistency` DB parameter or DB cluster parameter when you want to forward writes. If you don't, then Aurora doesn't forward writes. This parameter has an empty value by default, so choose a specific value when you use this parameter. The `aurora_replica_read_consistency` parameter only affects DB clusters or instances that have write forwarding enabled.

As you increase the consistency level, your application spends more time waiting for changes to be propagated between DB instances. You can choose the balance between fast response time and making sure that changes made in other DB instances are fully available before your queries run.

You can specify the following values for the `aurora_replica_read_consistency` parameter:
+ `EVENTUAL` – Results of write operations in the same session aren't visible until the write operation is performed on the writer DB instance. The query doesn't wait for the updated results to be available. Thus it might retrieve the older data or the updated data, depending on the timing of the statements and the amount of replication lag. This is the same consistency as for Aurora MySQL DB clusters that don't use write forwarding.
+ `SESSION` – All queries that use write forwarding see the results of all changes made in that session. The changes are visible regardless of whether the transaction is committed. If necessary, the query waits for the results of forwarded write operations to be replicated.
+ `GLOBAL` – A session sees all committed changes across all sessions and instances in the DB cluster. Each query might wait for a period that varies depending on the amount of session lag. The query proceeds when the DB cluster is up-to-date with all committed data from the writer, as of the time that the query began.

For information about the configuration parameters involved in write forwarding, see [Configuration parameters for write forwarding](aurora-mysql-write-forwarding.md#aurora-mysql-write-forwarding-params).

**Note**  
You can also use `aurora_replica_read_consistency` as a session variable, for example:  

```
mysql> set aurora_replica_read_consistency = 'session';
```

## Examples of using write forwarding
<a name="aurora-mysql-write-forwarding-examples"></a>

The following examples show the effects of the `aurora_replica_read_consistency` parameter on running `INSERT` statements followed by `SELECT` statements. The results can differ, depending on the value of `aurora_replica_read_consistency` and the timing of the statements.

To achieve higher consistency, you might wait briefly before issuing the `SELECT` statement. Or Aurora can automatically wait until the results finish replicating before proceeding with `SELECT`.

For information on setting DB parameters, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).

**Example with `aurora_replica_read_consistency` set to `EVENTUAL`**  
Running an `INSERT` statement, immediately followed by a `SELECT` statement, returns a value for `COUNT(*)` with the number of rows before the new row is inserted. Running the `SELECT` again a short time later returns the updated row count. The `SELECT` statements don't wait.  

```
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)
```

**Example with `aurora_replica_read_consistency` set to `SESSION`**  
A `SELECT` statement immediately after an `INSERT` waits until the changes from the `INSERT` statement are visible. Subsequent `SELECT` statements don't wait.  

```
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)
```
With the read consistency setting still set to `SESSION`, introducing a brief wait after performing an `INSERT` statement makes the updated row count available by the time the next `SELECT` statement runs.  

```
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)
```

**Example with `aurora_replica_read_consistency` set to `GLOBAL`**  
Each `SELECT` statement waits for all data changes, as of the start time of the statement, to be visible before performing the query. The wait time for each `SELECT` statement varies, depending on the amount of replication lag.  

```
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)
```

## Running multipart statements with write forwarding
<a name="aurora-mysql-write-forwarding-multipart"></a>

A DML statement might consist of multiple parts, such as an `INSERT ... SELECT` statement or a `DELETE ... WHERE` statement. In this case, the entire statement is forwarded to the writer DB instance and run there.

## Transactions with write forwarding
<a name="aurora-mysql-write-forwarding-txns"></a>

If the transaction access mode is set to read only, write forwarding isn't used. You can specify the access mode for the transaction by using the `SET TRANSACTION` statement or the `START TRANSACTION` statement. You can also specify the transaction access mode by changing the value of the [transaction\$1read\$1only](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_transaction_read_only) session variable. You can change this session value only while you're connected to a DB cluster that has write forwarding enabled.

If a long-running transaction doesn't issue any statement for a substantial period of time, it might exceed the idle timeout period. This period has a default of one minute. You can set the `aurora_fwd_writer_idle_timeout` parameter to increase it up to one day. A transaction that exceeds the idle timeout is canceled by the writer instance. The next subsequent statement you submit receives a timeout error. Then Aurora rolls back the transaction.

This type of error can occur in other cases when write forwarding becomes unavailable. For example, Aurora cancels any transactions that use write forwarding if you restart the DB cluster or if you disable write forwarding.

When a writer instance in a cluster using local write forwarding is restarted, any active, forwarded transactions and queries on reader instances using local write forwarding are automatically closed. After the writer instance is available again, you can retry these transactions.

## Configuration parameters for write forwarding
<a name="aurora-mysql-write-forwarding-params"></a>

The Aurora DB parameter groups include settings for the write forwarding feature. Details about these parameters are summarized in the following table, with usage notes after the table.


| Parameter | Scope | Type | Default value | Valid values | 
| --- | --- | --- | --- | --- | 
| aurora\$1fwd\$1writer\$1idle\$1timeout | Cluster | Unsigned integer | 60 | 1–86,400 | 
| aurora\$1fwd\$1writer\$1max\$1connections\$1pct | Cluster | Unsigned long integer | 10 | 0–90 | 
| aurora\$1replica\$1read\$1consistency | Cluster or instance | Enum | '' (null) | EVENTUAL, SESSION, GLOBAL | 

To control incoming write requests, use these settings:
+ `aurora_fwd_writer_idle_timeout` – The number of seconds the writer DB instance waits for activity on a connection that's forwarded from a reader instance before closing it. If the session remains idle beyond this period, Aurora cancels the session.
+ `aurora_fwd_writer_max_connections_pct` – The upper limit on database connections that can be used on a writer DB instance to handle queries forwarded from reader instances. It's expressed as a percentage of the `max_connections` setting for the writer. For example, if `max_connections` is 800 and `aurora_fwd_master_max_connections_pct` or `aurora_fwd_writer_max_connections_pct` is 10, then the writer allows a maximum of 80 simultaneous forwarded sessions. These connections come from the same connection pool managed by the `max_connections` setting.

  This setting applies only on the writer when it has write forwarding enabled. If you decrease the value, existing connections aren't affected. Aurora takes the new value of the setting into account when attempting to create a new connection from a DB cluster. The default value is 10, representing 10% of the `max_connections` value.

**Note**  
Because `aurora_fwd_writer_idle_timeout` and `aurora_fwd_writer_max_connections_pct` are DB cluster parameters, all DB instances in each cluster have the same values for these parameters.

For more information about `aurora_replica_read_consistency`, see [Read consistency for write forwarding](aurora-mysql-write-forwarding-consistency.md).

For more information on DB parameter groups, see [Parameter groups for Amazon Aurora](USER_WorkingWithParamGroups.md).

# Amazon CloudWatch metrics and Aurora MySQL status variables for write forwarding
<a name="aurora-mysql-write-forwarding-cloudwatch"></a>

The following Amazon CloudWatch metrics and Aurora MySQL status variables apply when you use write forwarding for Aurora MySQL. For more information about metrics for Aurora MySQL writer and reader DB instances, see the following topics.

**Topics**
+ [Metrics for write forwarding for Aurora MySQL writer DB instances](#aurora-mysql-write-forwarding-cloudwatch-writer-metrics)
+ [Metrics for write forwarding for Aurora MySQL reader DB instances](#aurora-mysql-write-forwarding-cloudwatch-reader-metrics)

## Metrics for write forwarding for Aurora MySQL writer DB instances
<a name="aurora-mysql-write-forwarding-cloudwatch-writer-metrics"></a>

The following Amazon CloudWatch metrics apply when you use write forwarding on one or more DB clusters. These metrics are all measured on the writer DB instance.


| CloudWatch metric | Unit | Description | 
| --- | --- | --- | 
|  `ForwardingWriterDMLLatency`  | Milliseconds |  Average time to process each forwarded DML statement on the writer DB instance. It doesn't include the time for the DB cluster to forward the write request, or the time to replicate changes back to the writer.  | 
|  `ForwardingWriterDMLThroughput`   | Count per second | Number of forwarded DML statements processed each second by this writer DB instance. | 
|  `ForwardingWriterOpenSessions`  | Count | Number of forwarded sessions on the writer DB instance. | 

The following Aurora MySQL status variables apply when you use write forwarding on one or more DB clusters. These status variables are all measured on the writer DB instance.


| Aurora MySQL status variable | Unit | Description | 
| --- | --- | --- | 
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1count | Count | Total number of DML statements forwarded to this writer DB instance. | 
| Aurora\$1fwd\$1writer\$1dml\$1stmt\$1duration | Microseconds | Total duration of DML statements forwarded to this writer DB instance. | 
| Aurora\$1fwd\$1writer\$1open\$1sessions | Count | Number of forwarded sessions on the writer DB instance. | 
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1count | Count | Total number of SELECT statements forwarded to this writer DB instance. | 
| Aurora\$1fwd\$1writer\$1select\$1stmt\$1duration | Microseconds | Total duration of SELECT statements forwarded to this writer DB instance. | 

## Metrics for write forwarding for Aurora MySQL reader DB instances
<a name="aurora-mysql-write-forwarding-cloudwatch-reader-metrics"></a>

The following CloudWatch metrics are measured on each reader DB instance in a DB cluster with write forwarding enabled.


| CloudWatch metric | Unit | Description | 
| --- | --- | --- | 
|  `ForwardingReplicaDMLLatency`  | Milliseconds | Average response time of forwarded DMLs on replica. | 
|  `ForwardingReplicaDMLThroughput`  | Count per second | Number of forwarded DML statements processed each second. | 
|  `ForwardingReplicaOpenSessions`  | Count | Number of sessions that are using write forwarding on a reader DB instance. | 
|  `ForwardingReplicaReadWaitLatency`  | Milliseconds |  Average wait time that a `SELECT` statement on a reader DB instance waits to catch up to the writer. The degree to which the reader DB instance waits before processing a query depends on the `aurora_replica_read_consistency` setting.  | 
|  `ForwardingReplicaReadWaitThroughput`  | Count per second | Total number of SELECT statements processed each second in all sessions that are forwarding writes. | 
|   `ForwardingReplicaSelectLatency`  | Milliseconds | Forwarded SELECT latency, averaged over all forwarded SELECT statements within the monitoring period. | 
|   `ForwardingReplicaSelectThroughput`  | Count per second | Forwarded SELECT throughput per second average within the monitoring period. | 

The following Aurora MySQL status variables are measured on each reader DB instance in a DB cluster with write forwarding enabled.


| Aurora MySQL status variable | Unit | Description | 
| --- | --- | --- | 
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1count | Count | Total number of DML statements forwarded from this reader DB instance. | 
| Aurora\$1fwd\$1replica\$1dml\$1stmt\$1duration | Microseconds | Total duration of all DML statements forwarded from this reader DB instance. | 
| Aurora\$1fwd\$1replica\$1errors\$1session\$1limit | Count |  Number of sessions rejected by the primary cluster due to one of the following error conditions: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-mysql-write-forwarding-cloudwatch.html)  | 
| Aurora\$1fwd\$1replica\$1open\$1sessions | Count | Number of sessions that are using write forwarding on a reader DB instance. | 
| Aurora\$1fwd\$1replica\$1read\$1wait\$1count | Count | Total number of read-after-write waits on this reader DB instance. | 
| Aurora\$1fwd\$1replica\$1read\$1wait\$1duration | Microseconds | Total duration of waits due to the read consistency setting on this reader DB instance. | 
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1count | Count | Total number of SELECT statements forwarded from this reader DB instance. | 
| Aurora\$1fwd\$1replica\$1select\$1stmt\$1duration | Microseconds | Total duration of SELECT statements forwarded from this reader DB instance. | 

## Identifying forwarded transactions and queries
<a name="aurora-write-forwarding-processlist"></a>

You can use the `information_schema.aurora_forwarding_processlist` table to identify forwarded transactions and queries. For more information on this table, see [information\$1schema.aurora\$1forwarding\$1processlist](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.aurora_forwarding_processlist).

The following example shows all forwarded connections on a writer DB instance.

```
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      |
+-----+----------+--------------------+----------+---------+------+--------------+--------------------------------------------+--------------+--------------------+---------------------------------+----------------------+----------------+
```

On the forwarding reader DB instance, you can see the threads associated with these writer DB connections by running `SHOW PROCESSLIST`. The `REPLICA_SESSION_ID` values on the writer, 637 and 639, are the same as the `Id` values on the reader.

```
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)
```