Cluster endpoint

 An endpoint for a Aurora DB cluster that connects to the current primary instance for that DB cluster. Each Aurora DB cluster has a cluster endpoint.

The cluster endpoint provides failover support for read/write connections to the DB cluster. If the current primary instance of a DB cluster fails, Aurora automatically fails over to a new primary instance. During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new primary instance, with minimal interruption of service.

The following example illustrates a cluster endpoint for an Aurora MySQL DB cluster.

mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com:3306

Reader  endpoint

An endpoint for an Aurora DB cluster that connects to one of the available Aurora Replicas for that DB cluster. Each Aurora DB cluster has a reader endpoint.

The reader endpoint provides load balancing support for read-only connections to the DB cluster. The DB cluster distributes connection requests to the reader endpoint among available Aurora Replicas. If the DB cluster contains only a primary instance, the reader endpoint serves connection requests from the primary instance. If an Aurora Replica is created for that DB cluster, the reader endpoint continues to serve connection requests to the reader endpoint from the new Aurora Replica, with minimal interruption in service.

The following example illustrates a reader endpoint for an Aurora MySQL DB cluster.

mydbcluster.cluster-ro-123456789012.us-east-1.rds.amazonaws.com:3306

Instance endpoint

AN endpoint for a DB instance in an Aurora DB cluster that connects to that specific DB instance. Each DB instance in a DB cluster, regardless of instance type, has its own unique instance endpoint.

The instance endpoint provides direct control over connections to the DB cluster, for scenarios where using the cluster endpoint or reader endpoint may not be appropriate. For example, your client application may require load balancing by read workload, instead of by connections, in which case you can configure multiple clients to connect to different Aurora Replicas in a DB cluster to distribute read workloads. For an example that uses instance endpoints to improve connection speed after a failover, see Fast Failover with Amazon Aurora PostgreSQL.

The following example illustrates an instance endpoint for a DB instance in an Aurora MySQL DB cluster.

mydbinstance.123456789012.us-east-1.rds.amazonaws.com:3306

Endpoint Considerations

Some considerations for working with Aurora endpoints are as follows:

• Before using an instance endpoint to connect to a specific DB instance in a DB cluster, consider using the cluster endpoint or reader endpoint for the DB cluster instead.The cluster endpoint and reader endpoint provide support for high-availability scenarios. If the primary instance of a DB cluster fails, Aurora automatically fails over to a new primary instance. It does so by either promoting an existing Aurora Replica to a new primary instance or creating a new primary instance. If a failover occurs, you can use the cluster endpoint to reconnect to the newly promoted or created a primary instance, or use the reader endpoint to reconnect to one of the other Aurora Replicas in the DB cluster.If you don’t take this approach, you can still make sure that you’re connecting to the right DB instance in the DB cluster for the intended operation. To do so, you can manually or programmatically discover the resulting set of available DB instances in the DB cluster and confirm their instance types after failover, before using the instance endpoint of a specific DB instance.For more information about failovers, see Fault Tolerance for an Aurora DB Cluster.
• The reader endpoint only load-balances connections to available Aurora Replicas in an Aurora DB cluster. It does not load-balance specific queries. If you want to load-balance queries to distribute the read workload for a DB cluster, you need to manage that in your application and use instance endpoints to connect directly to Aurora Replicas to balance the load.
• During a failover, the reader endpoint might direct connections to the new primary instance of a DB cluster for a short time, when an Aurora Replica is promoted to the new primary instance.
  

  Amazon Aurora Storage

  Aurora data is stored in the cluster volume, which is a single, virtual volume that utilizes solid state disk (SSD) drives. A cluster volume consists of copies of the data across multiple Availability Zones in a single region. Because the data is automatically replicated across Availability Zones, your data is highly durable with less possibility of data loss. This replication also ensures that your database is more available during a failover because the data copies already exist in the other Availability Zones and continue to serve data requests to the instances in your DB cluster.

  Aurora cluster volumes automatically grow as the amount of data in your database increases. An Aurora cluster volume can grow to a maximum size of 64 terabytes (TB). Table size is limited to the size of the cluster volume. That is, the maximum table size for a table in an Aurora DB cluster is 64 TB. Even though an Aurora cluster volume can grow to up to 64 TB, you are only charged for the space that you use in an Aurora cluster volume. For pricing information, see Amazon RDS for Aurora Pricing.

  Amazon Aurora Replication

  Aurora Replicas are independent endpoints in an Aurora DB cluster. They provide read-only access to the data in the DB cluster volume. They enable you to scale the read workload for your data over multiple replicated instances, to both improve the performance of data reads and also increase the availability of the data in your Aurora DB cluster. Aurora Replicas are also failover targets and are quickly promoted if the primary instance for your Aurora DB cluster fails.

  For more information on Aurora Replicas and other options for replicating data in an Aurora DB cluster, see Replication with Amazon Aurora.

  Amazon Aurora Reliability

  Aurora is designed to be reliable, durable, and fault tolerant. You can architect your Aurora DB cluster to improve availability by doing things such as adding Aurora Replicas and placing them in different Availability Zones, and also Aurora includes several automatic features that make it a reliable database solution.

  Storage Auto-Repair

  Because Aurora maintains multiple copies of your data in three Availability Zones, the chance of losing data as a result of a disk failure is greatly minimized. Aurora automatically detects failures in the disk volumes that make up the cluster volume. When a segment of a disk volume fails, Aurora immediately repairs the segment. When Aurora repairs the disk segment, it uses the data in the other volumes that make up the cluster volume to ensure that the data in the repaired segment is current. As a result, Aurora avoids data loss and reduces the need to perform a point-in-time restore to recover from a disk failure.

  Survivable Cache Warming

  Aurora “warms” the buffer pool cache when a database starts up after it has been shut down or restarted after a failure. That is, Aurora preloads the buffer pool with the pages for known common queries that are stored in an in-memory page cache. This provides a performance gain by bypassing the need for the buffer pool to “warm up” from normal database use.

  The Aurora page cache is managed in a separate process from the database, which allows the page cache to survive independently of the database. In the unlikely event of a database failure, the page cache remains in memory, which ensures that the buffer pool is warmed with the most current state when the database restarts.

  Crash Recovery

  Aurora is designed to recover from a crash almost instantaneously and continue to serve your application data. Aurora performs crash recovery asynchronously on parallel threads, so that your database is open and available immediately after a crash.

  For more information about crash recovery, see Fault Tolerance for an Aurora DB Cluster.

  The following are considerations for binary logging and crash recovery on Aurora MySQL:

  • Enabling binary logging on Aurora directly affects the recovery time after a crash because it forces the DB instance to perform binary log recovery.
  • The type of binary logging used affects the size and efficiency of logging. For the same amount of database activity, some formats log more information than others in the binary logs. The following settings for the binlog_format parameter result in different amounts of log data:
    • ROW — The most log data
    • STATEMENT — The least log data
    • MIXED — A moderate amount of log data that usually provides the best combination of data integrity and performance

    The amount of binary log data affects recovery time. If there is more data logged in the binary logs, the DB instance must process more data during recovery, which increases recovery time.

  • Aurora does not need the binary logs to replicate data within a DB cluster or to perform the point in time restore (PITR).
  • If you don’t need the binary log for external replication (or an external binary log stream), we recommend that you set the parameterbinlog_format to OFFdisable binary logging. Doing so reduces recovery time.

  For more information about Aurora binary logging and replication, see Replication with Amazon Aurora. For more information about the implications of different MySQL replication types, see Advantages and Disadvantages of Statement-Based and Row-Based Replication in the MySQL documentation.

  Amazon Aurora Performance Enhancements

  Amazon Aurora includes performance enhancements to support the diverse needs of high-end commercial databases.

  Amazon Aurora MySQL Performance Enhancements

  Aurora MySQL includes the following performance enhancements:

Fast insert

Fast insert accelerates parallel inserts sorted by primary key and applies specifically to LOAD DATAand statementsINSERT INTO ... SELECT ....