Best practices with Amazon Aurora MySQL
This topic includes information on best practices and options for using or migrating data to an Amazon Aurora MySQL DB cluster. The information in this topic summarizes and reiterates some of the guidelines and procedures that you can find in Managing an Amazon Aurora DB cluster.
Contents
- Determining which DB instance you are connected to
- Best practices for Aurora MySQL performance and scaling
- Best practices for Aurora MySQL high availability
- Recommendations for MySQL features in Aurora MySQL
- Using multithreaded replication in Aurora MySQL
- Invoking AWS Lambda functions using native MySQL functions
- Avoiding XA transactions with Amazon Aurora MySQL
- Keeping foreign keys turned on during DML statements
- Configuring how frequently the log buffer is flushed
- Minimizing and troubleshooting Aurora MySQL deadlocks
Determining which DB instance you are connected to
To determine which DB instance in an Aurora MySQL DB cluster a connection is
connected to, check the innodb_read_only
global variable, as shown in
the following example.
SHOW GLOBAL VARIABLES LIKE 'innodb_read_only';
The innodb_read_only
variable is set to ON
if you are
connected to a reader DB instance. This setting is OFF
if you are connected to a writer DB
instance, such as primary instance in a provisioned cluster.
This approach can be helpful if you want to add logic to your application code to balance the workload or to ensure that a write operation is using the correct connection.