For similar capabilities to Amazon Timestream for LiveAnalytics, consider Amazon Timestream for InfluxDB. It offers simplified data ingestion and single-digit millisecond query response times for real-time analytics. Learn more [here](https://docs.amazonaws.cn//timestream/latest/developerguide/timestream-for-influxdb.html).
# Working with Multi-AZ read replica clusters for Amazon Timestream for InfluxDB
Working with read replica clusters
A read replica cluster deployment is an asynchronous deployment mode of Amazon Timestream for InfluxDB that allows you to configure read replicas attached to a primary DB instance. A read replica cluster has a writer DB instance and a reader DB instance in separate Availability Zones within the same Amazon Web Services Region. Read replica clusters provide high availability and increased capacity for read workloads when compared to Multi-AZ DB instance deployments.
## Instance class availability for read replica clusters
Instance class availability
Read replica cluster deployments are supported for the same instance types as regular Timestream for InfluxDB instances.
****
| Instance class | vCPU | Memory (GiB) | Storage type | Network bandwidth (Gbps) |
| --- | --- | --- | --- | --- |
| db.influx.medium | 1 | 8 | Influx IOPS Included | 10 |
| db.influx.large | 2 | 16 | Influx IOPS Included | 10 |
| db.influx.xlarge | 4 | 32 | Influx IOPS Included | 10 |
| db.influx.2xlarge | 8 | 64 | Influx IOPS Included | 10 |
| db.influx.4xlarge | 16 | 128 | Influx IOPS Included | 10 |
| db.influx.8xlarge | 32 | 256 | Influx IOPS Included | 12 |
| db.influx.12xlarge | 48 | 384 | Influx IOPS Included | 20 |
| db.influx.16xlarge | 64 | 512 | Influx IOPS Included | 25 |
| db.influx.24xlarge | 96 | 768 | Influx IOPS Included | 40 |
## Read replica cluster architecture
Read replica cluster architecture
With a read replica cluster, Amazon Timestream for InfluxDB automatically replicates all writes made to the writer DB instance to all reader DB instances using InfluxData’s licensed read replica add-on. This replication is asynchronous and all writes are acknowledged as soon as they are committed by the writer node. Writes do not require acknowledgement from all reader nodes to be considered as a successful write. Once data is committed by the writer DB instance, it is replicated to the read replica instance almost instantaneously. In case of unrecoverable writer failure, any data that has not been replicated over to at least one of the readers will be lost.
A read replica instance is a read-only copy of a writer DB instance. You can reduce the load on your writer DB instance by routing some or all of the queries from your applications to the read replica. In this way, you can elastically scale out beyond the capacity constraints of a single DB instance for read-heavy database workloads.
The following diagram shows a primary DB instance replicating to a read replica in a different Availability Zone. Clients have read/write access to the primary DB instance and read-only access to the replica.
![\[A primary DB instance in Avaiability Zone A asynchronously replicates to a read replica instance in Availability Zone C.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/rr_azs_diagram.png)
## Parameter groups for read replica clusters
Parameter groups
In a read replica cluster, a *DB parameter group* acts as a container for engine configuration values that are applied to every DB instance in the read replica cluster. A default DB parameter group is set based on the DB engine and DB engine version. The settings in the DB parameter group are used for all of the DB instances in the cluster.
When passing a specific DB parameter group using [CreateDbCluster](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_CreateDbCluster.html) or [UpdateDbCluster](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_UpdateDbCluster.html) for Multi-AZ DB read replica, ensure the `storage-wal-max-write-delay` is set to a duration of 1 hour minimum. If no DB parameter group is specified, `storage-wal-max-write-delay` will default to 1 hour.
## Replica lag in read replica clusters
Replica lag
Although Timestream for InfluxDB read replica clusters allow for high write performance, replica lag can still occur due to the nature of engine-based asynchronous replication. This lag can lead to potential data loss in the event of a failover, making it essential to monitor.
You can track the replica lag from CloudWatch by selecting **All metrics** in the Amazon Web Services Management Console navigation pane. Choose **Timestream/InfluxDB**, then **By DbCluster**. Select your **DbClusterName** and then your **DbReaderInstanceName**. Here, besides the normal set of metrics tracked for all Timestream for InfluxDB instances (see below list), you will also see ReplicaLag, expressed in milliseconds.
+ CPUUtilization
+ MemoryUtilization
+ DiskUtilization
+ ReplicaLag (only for replica instance mode DB instances)
### Common causes of replica lag
Replica lag causes
In general, replica lag occurs when the write and read workloads are too high for the reader DB instances to apply the transactions efficiently. Various workloads can incur temporary or continuous replica lag. Some examples of common causes are the following:
+ High write concurrency or heavy batch updating on the writer DB instance, causing the apply process on the reader DB instances to fall behind.
+ Heavy read workload that is using resources on one or more reader DB instances. Running slow or large queries can affect the apply process and can cause replica lag.
+ Transactions that modify large amounts of data or DDL statements can sometimes cause a temporary increase in replica lag because the database must preserve commit order.
For a tutorial that shows you how to create a CloudWatch alarm when replica lag exceeds a set amount of time, see [Tutorial: Create an Amazon CloudWatch alarm for Multi-AZ cluster replica lag for Amazon Timestream for InfluxDB](timestream-for-influx-creating-cw-alarms.md#timestream-for-influx-tutorial-alarm).
### Mitigating replica lag
Mitigating replica lag
For Timestream for InfluxDB read replica clusters, you can mitigate replica lag by reducing the load on your writer DB instance.
## Availability and durability
Availability and durability
Read replica clusters can be configured to either automatically fail over to one of the reader instances in case of writer failure to prioritize write availability or to avoid failing over to minimize tip data loss. Tip data refers to the replication gap of data not yet replicated to at least one of the reader nodes (see [Replica lag in read replica clusters](#timestream-for-influx-replica-lag)). The default and recommended behavior for read replica clusters is to automatically fail over in case of writer failures. However, if tip data loss is more important than write availability for your use cases, you can override the default by updating the cluster.
Read replica clusters ensure that all DB instances of the cluster are distributed across at least two Availability Zones to ensure increased write availability and data durability in case of an Availability Zone outage.
**Topics**
+ [
## Instance class availability for read replica clusters
](#timestream-for-influx-instance-class-rr)
+ [
## Read replica cluster architecture
](#timestream-for-influx-rr-cluster-architecture)
+ [
## Parameter groups for read replica clusters
](#timestream-for-influx-rr-param-groups)
+ [
## Replica lag in read replica clusters
](#timestream-for-influx-replica-lag)
+ [
## Availability and durability
](#timestream-for-influx-availability)
+ [
# Overview of Amazon Timestream for InfluxDB read replica clusters
](timestream-for-influx-read-replica-overview.md)
+ [
# Creating a Timestream for InfluxDB read replica cluster
](timestream-for-influx-create-rr-cluster.md)
+ [
# Connecting to a Timestream for InfluxDB read replica DB cluster
](timestream-for-influx-connecting-cluster.md)
+ [
# Modifying a read replica cluster for Amazon Timestream for InfluxDB
](timestream-for-influx-modifying-rr-cluster.md)
+ [
# Rebooting a read replica cluster in Amazon Timestream for InfluxDB
](timestream-for-influx-rebooting-rr-cluster.md)
+ [
# Creating CloudWatch alarms to monitor Amazon Timestream for InfluxDB
](timestream-for-influx-creating-cw-alarms.md)
+ [
# Read replica licensing through Amazon Web Services Marketplace
](timestream-for-influx-rr-licensing.md)
# Overview of Amazon Timestream for InfluxDB read replica clusters
Read replicas cluster overview
The following sections discuss Timestream for InfluxDB read replica clusters:
**Topics**
+ [
## Use cases for read replicas
](#timestream-for-influx-rr-use-cases)
+ [
## How read replicas work
](#timestream-for-influx-how-rr-work)
+ [
## Characteristics of Timestream for InfluxDB read replicas
](#timestream-for-influx-rr-characteristics)
+ [
## Read replica instance and storage types
](#timestream-for-influx-rr-instance-storage-types)
+ [
## Considerations when deleting replicas
](#timestream-for-influx-rr-deletion)
## Use cases for read replicas
Read replica use cases
Using a read replica cluster might make sense in a variety of scenarios, including the following:
+ Scaling beyond the compute or I/O capacity of a single DB instance for read-heavy database workloads. You can direct this excess read traffic to one or more read replicas.
+ Serving read traffic while the primary writer instance is unavailable. In some cases, your primary DB instance might not be able to take I/O requests, for example, due to I/O suspension for backups or scheduled maintenance. In these cases, you can direct read traffic to your read replica. For this use case, keep in mind that the data on the read replica might be "stale" because the primary DB instance is unavailable. Also, keep in mind that you will need to turn off automatic failover for these scenarios to work.
+ Business reporting or data warehousing scenarios where you might want business reporting queries to run against a read replica, rather than your production DB instance.
+ Implementing disaster recovery. You can promote a read replica to primary as a disaster recovery solution if the primary DB instance fails.
+ Faster failover for scenarios where availability is more important than durability. Since read replicas use asynchronous replication, there is a chance that some data that was committed by the primary writer instance was not replicated before a failover. However, for applications where uptime is paramount, this trade-off is acceptable. Depending on your workload characteristics, a failover to a read replica could be significantly faster than a failover to a standby DB instance that uses synchronous replication, as the replica instance is already running and does not need to start the engine. This can be particularly beneficial in use cases where every minute counts.
## How read replicas work
How read replicas work
To create a read replica cluster, Amazon Timestream for InfluxDB uses InfluxData’s licensed read replica add-ons. The add-on subscription is activated via the Amazon Web Services Marketplace, directly from the Amazon Timestream management console. For more details, see [Read replica licensing through Amazon Web Services MarketplaceRead replica licensing terminology](timestream-for-influx-rr-licensing.md).
Read replicas are billed as standard DB instances at the same rates as the DB instance type used for each node in your cluster, plus the cost of InfluxData’s licensed add-on. The cost of the add-on is billed in instance-hours via the Amazon Web Services Marketplace. You aren't charged for the data transfer incurred in replicating data between the source DB instance and a read replica within the same Amazon Web Services Region.
Once you have created and configured your read replica cluster and start accepting writes, Amazon Timestream for InfluxDB uses the asynchronous replication method to update the read replica whenever there is a change to the primary DB instance.
The read replica functions as a dedicated DB instance, exclusively accepting read-only connections. Applications can connect to a read replica in the same manner as they would to any other DB instance, providing a seamless and familiar experience. Amazon Timestream for InfluxDB automatically replicates all data from the primary DB instance to the read replica, ensuring data consistency and accuracy. Note that updates are done at the cluster level and applied at the same time to both the primary and replica.
## Characteristics of Timestream for InfluxDB read replicas
Read replica characteristics
****
| Feature or behavior | Timestream for InfluxDB |
| --- | --- |
| What is the replication method? | Logical replication. |
| Can a replica be made writable? | No, Timestream for InfluxDB read replicas are designed to be read-only and cannot be made writable. While a read replica can be promoted to primary in the event of a failover, thereby accepting writes, at any given time, there can only be one writer DB instance in a Timestream for InfluxDB read replica cluster. This ensures data consistency and prevents conflicts that could arise from multiple writable instances. The read replica's role is to provide a redundant, read-only copy of the data, and it will automatically reject write requests to maintain data integrity. |
| Can backups be performed on the replica? | Yes, you can use the built-in engine capabilities to create backups using the Influx CLI. |
| Can you use parallel replication? | No, Timestream for InfluxDB has a single process handling replication. |
## Read replica instance and storage types
Read replica storage and instance types
A read replica is created with the same instance and storage type as the primary DB instance. Any changes to the configuration must be made at the cluster level and will apply to all instances within the cluster. All instance and storage configurations available for Timestream for InfluxDB DB instances are available for Timestream for InfluxDB read replica clusters.
**Instance types**
****
| Instance class | vCPU | Memory (GiB) | Storage type | Network bandwidth (Gbps) |
| --- | --- | --- | --- | --- |
| db.influx.medium | 1 | 8 | Influx IOPS Included | 10 |
| db.influx.large | 2 | 16 | Influx IOPS Included | 10 |
| db.influx.xlarge | 4 | 32 | Influx IOPS Included | 10 |
| db.influx.2xlarge | 8 | 64 | Influx IOPS Included | 10 |
| db.influx.4xlarge | 16 | 128 | Influx IOPS Included | 10 |
| db.influx.8xlarge | 32 | 256 | Influx IOPS Included | 12 |
| db.influx.12xlarge | 48 | 384 | Influx IOPS Included | 20 |
| db.influx.16xlarge | 64 | 512 | Influx IOPS Included | 25 |
| db.influx.24xlarge | 96 | 768 | Influx IOPS Included | 40 |
**Storage options**
****
| Timestream for InfluxDB DB cluster storage | Source DB instance storage allocation | Included IOPS |
| --- | --- | --- |
| Influx IO Included (3K) | 20 GiB to 16 TiB | 3,000 IOPS |
| Influx IO Included (12K) | 400 GiB to 16 TiB | 12,000 IOPS |
| Influx IO Included (16K) | 400 GiB to 16 TiB | 16,000 IOPS |
## Considerations when deleting replicas
Deletion considerations
If you no longer require read replicas, you can explicitly delete the cluster by calling the `delete-db-cluster` API. In the following example, replace each *user input placeholder* with your own information. Keep in mind that you cannot remove a single node from your cluster at this time.
```
aws timestream-influxdb delete-db-cluster \
--region region \
--endpoint endpoint \
--db-cluster-id cluster-id
```
# Creating a Timestream for InfluxDB read replica cluster
Creating a read replica cluster
A Timestream for InfluxDB read replica cluster has a writer DB instance and a reader DB instance in separate Availability Zones. Timestream for InfluxDB read replica clusters provide high availability, increased capacity for read workloads, and faster failover when failover to replica is configured.
## DB cluster prerequisites
DB cluster prerequisites
**Important**
The following are prerequisites to complete before creating a read replica cluster.
**Topics**
+ [
### Configure the network for the DB cluster
](#timestream-for-influx-config-network)
+ [
### Additional prerequisites
](#timestream-for-influx-addl-prereqs)
### Configure the network for the DB cluster
Network configuration
You can only create a Timestream for InfluxDB read replica DB cluster in a virtual private cloud (VPC) based on the Amazon VPC service. It must be in an Amazon Web Services Region that has at least three Availability Zones. The DB subnet group that you choose for the DB cluster must cover at least three Availability Zones. This configuration ensures that each DB instance in the DB cluster is in a different Availability Zone.
To connect to your DB cluster from resources other than EC2 instances in the same VPC, configure the network connections manually.
### Additional prerequisites
Additional prerequisites
**Before you create your read replica cluster, consider the following additional prerequisites:**
To tailor the configuration parameters for your DB cluster, specify a DB cluster parameter group with the required parameter settings. For information about creating or modifying a DB cluster parameter group, see [Parameter groups for read replica clusters](timestream-for-influx-working-read-replica.md#timestream-for-influx-rr-param-groups).
Determine the TCP/IP port number to specify for your DB cluster. The firewalls at some companies block connections to the default ports. If your company firewall blocks the default port, choose another port for your DB cluster. All DB instances in a DB cluster use the same port.
## Create a DB cluster
Create a DB cluster
You can create a Timestream for InfluxDB read replica DB cluster using the Amazon Web Services Management Console, the Amazon CLI, or the Amazon Timestream for InfluxDB API.
------
#### [ Using the Amazon Web Services Management Console ]
You can create a Timestream for InfluxDB read replica DB cluster by choosing **Cluster with read replicas** in the **Deployment settings** section.
To create a read replica DB cluster using the console:
1. Sign in to the [Amazon Web Services Management Console](https://console.amazonaws.cn/timestream) and open the Amazon Timestream console.
1. In the upper-right corner of the Amazon Web Services Management Console, choose the Amazon Web Services Region in which you want to create the read replica DB cluster.
1. In the navigation pane, choose **InfluxDB databases**.
1. Choose **Create InfluxDB database**.
1. In **Deployment settings**, choose **Cluster with read replicas**.
Once you select that option, a message will appear indicating you need to activate your subscription via the Amazon Web Services Marketplace widget. Click on **View subscription options**. Note that it can take 1–2 minutes for the subscription to become active.
![\[The Create InfluxDB database interface that shows the different deployment settings available for the new database. The cluster with read replicas option is selected.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/deployment_settings_rr.jpg)
![\[The Deployment settings interface showing a message that the subscription is in progress.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/subscription_in_progress.jpg)
1. Once the subscription is active, click **View subscription**.
![\[The Deployment settings interface showing a message that the subscription is now active.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/subscription_success_message.jpg)
1. A window will appear presenting information on the cost per vCPU per instance hour for each Region. This follows the same compute pricing model where you are charged for the number of hours your instance is active based on the instance type you have selected. You will only need to subscribe to the add-on once, and that will allow you to create instances in all Regions where Timestream for InfluxDB is available.
![\[Subscription options form showing pricing details on the cost per vCPU per instance hour for each Region.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/purchase_subscription.png)
**Important**
To subscribe to the offer, you will need to have either AWSMarketplaceManageSubscriptions or AWSMarketplaceFullAccess permissions. For more information about these permissions, check [Controlling access to Amazon Web Services Marketplace subscriptions](https://docs.amazonaws.cn/marketplace/latest/buyerguide/buyer-iam-users-groups-policies.html).
1. Once you confirm your subscription, the service will automatically select the Region based on the Region of your instance.
1. In **Database credentials**, complete the following fields:
1. For **DB cluster name**, enter the identifier for your DB cluster.
1. Provide the InfluxDB basic initial configuration parameters: **username**, **organization name**, **bucket name**, and **password**.
1. In **Instance configuration**, specify the **DB instance class**. Select an instance size that best fits your workload needs. Keep in mind that this instance type will be used for all instances in your read replica DB cluster.
1. In **Storage configuration**, select a **Storage type** that fits your needs. In all cases, you will only need to configure the allocated storage. Keep in mind that this storage type will be used for all instances in your read replica DB cluster.
1. In the **Connectivity configuration** section, make sure your InfluxDB cluster is in the same subnet as the clients that require connectivity to your Timestream for InfluxDB DB instance. You could also choose to make your DB instance publicly available in the **Public access** subsection.
1. Choose **Create InfluxDB database**.
1. In the **InfluxDB databases** list, choose the name of your new InfluxDB cluster to show its details. The DB cluster will have a status of **Creating** until it is ready to use.
1. When the status changes to **Available**, you can connect to the DB cluster. Depending on the DB instance class and the amount of storage, it can take up to 20 minutes before the new instance is available.
![\[DB cluster summary page showing two instances with the status "Available".\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/cluster_details_page.png)
1. Once created, you can click on your DB cluster identifier to retrieve information about your newly created cluster. The endpoint showing an instance mode of **PRIMARY** is the one you will need to use for writes and engine administration.
------
#### [ Using the Amazon CLI ]
To create a DB instance using the Amazon Command Line Interface, call the `create-db-cluster` command with the following parameters. Replace each *user input placeholder* with your own information.
```
aws timestream-influxdb create-db-cluster \
--region region \
--vpc-subnet-ids subnet-ids \
--vpc-security-group-ids security-group-ids \
--db-instance-type db.influx.large \
--db-storage-type InfluxIOIncludedT2 \
--allocated-storage 400 \
--password password \
--name cluster-name \
--deployment-type MULTI_NODE_READ_REPLICAS \
--publicly-accessible
//--failover-mode is optional and defaults to AUTOMATIC.
```
------
### Settings for creating read replica clusters
Settings for creating read replica clusters
For details about settings that you choose when you create a read replica cluster, see the following table. For more information about the Amazon CLI options, see [create-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/timestream-influxdb/create-db-cluster.html). For more information about the Amazon Timestream for InfluxDB API parameters, see [CreateDbCluster](https://docs.amazonaws.cn/ts-influxdb/latest/ts-influxdb-api/API_CreateDbCluster.html).
****
| Console setting | Setting description | CLI option and Timestream for InfluxDB API parameter |
| --- | --- | --- |
| Allocated storage | The amount of storage to allocate for each DB instance in your DB cluster (in gibibytes). For more information, see [InfluxDB instance storage](timestream-for-influxdb.md#timestream-for-influx-dbi-storage). | **CLI option: ** `--allocated-storage` **API parameter: **`allocatedStorage` |
| Database port | The port number on which InfluxDB accepts connections. Valid Values: 1024-65535 Default: 8086 Constraints: The value can't be 2375-2376, 7788-7799, 8090, or 51678-51680. | **CLI option: ** `--port` **API parameter: **`port` |
| DB cluster name | The name that uniquely identifies the DB cluster. DB instance names must be unique per customer and per region. | **CLI option: ** `--name` **API parameter: **`name` |
| DB instance type | The compute and memory capacity of each DB instance in your Timestream for InfluxDB DB cluster, for example db.influx.xlarge. If possible, choose a DB instance class large enough that a typical query working set can be held in memory. When working sets are held in memory, the system can avoid writing to disk, which improves performance. | **CLI option: ** `--db-instance-type` **API parameter: **`dbInstanceType` |
| DB cluster parameter group | The ID of the DB parameter group to assign to your DB cluster. DB parameter groups specify how the database is configured. For example, DB parameter groups can specify the limit for query concurrency. | **CLI option: ** `--db-parameter-group-identifier` **API parameter: **`dbParameterGroupIdentifier` |
| Deployment type | Specifies whether the DB cluster will be deployed as a multinode read replica or a Multi-AZ multinode read replica. Possible values: `MULTI_NODE_READ_REPLICAS` | **CLI option: ** `--deployment-type` **API parameter: **`deploymentType` |
| VPC subnet ID | The DB subnet ID you want to use for the DB cluster. Select Choose existing to use an existing DB subnet group, then choose the required subnet group from the Existing DB subnet groups dropdown list. Choose Automatic setup to let Timestream for InfluxDB select a compatible DB subnet group. | **CLI option: ** `--vpc-subnet-ids` **API parameter: **`vpcSubnetIds` |
| Organization | The name of the initial organization for the initial admin user in InfluxDB. An InfluxDB organization is a workspace for a group of users. | **CLI option: ** `--organization` **API parameter: **`organization` |
| Bucket | The name of the initial InfluxDB bucket. All InfluxDB data is stored in a bucket. A bucket combines the concept of a database and a retention period (the duration of time that each data point persists). A bucket belongs to an organization. | **CLI option: ** `--bucket` **API parameter: **`bucket` |
| Log exports | Configuration for sending InfluxDB engine logs to a specified S3 bucket. Configuration for S3 bucket log delivery: `s3Configuration -> (structure)` The name of the S3 bucket to deliver logs to: `bucketName -> (string)` Indicates whether log delivery to the S3 bucket is enabled: `enabled -> (boolean)` Shorthand syntax: `s3Configuration={bucketName=string, enabled=boolean}` | **CLI option: ** `--log-delivery-configuration` **API parameter: **`logDeliveryConfiguration` |
| Password | The password of the initial admin user you created in InfluxDB. This password will allow you to access the InfluxDB UI to perform various administrative tasks and also use the InfluxDB CLI to create an operator token. These attributes will be stored in a secret created in Amazon Secrets Manager in your account. | **CLI option: ** `--password` **API parameter: **`password` |
| Username | The username of the initial admin user created in InfluxDB. Must start with a letter and can't end with a hyphen or contain two consecutive hyphens. For example, my-user1. This username will allow you to access the InfluxDB UI to perform various administrative tasks and also use the InfluxDB CLI to create an operator token. These attributes will be stored in a secret created in Amazon Secrets Manager in your account. | **CLI option: ** `--username` **API parameter: **`username` |
| Public access | Indicates whether the DB cluster is accessible from outside the VPC. **Publicly accessible** gives the DB cluster a public IP address, meaning it's accessible outside the VPC. To be publicly accessible, the DB cluster also has to be in a public subnet in the VPC. **Not publicly accessible** makes the DB cluster accessible only from inside the VPC. | **CLI options: ** `--publicly-accessible``--no-publicly-accessible` **API parameter: **`publiclyAccessible` |
| DB storage type | InfluxDB data. You can choose between three different types of provisioned Influx IOPS Included storage according to your workload's requirements. Possible values: [\[See the AWS documentation website for more details\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/timestream-for-influx-create-rr-cluster.html) | **CLI options: ** `--db-storage-type``--no-publicly-accessible` **API parameter: **`dbStorageType` |
| VPC security group | A list of VPC security group IDs to associate with the DB instance. | **CLI options: ** `--vpc-security-group-ids``--no-publicly-accessible` **API parameter: **`vpcSecurityGroupIds` |
| VPC subnet IDs | A list of VPC subnet IDs to associate with the DB instance. Provide at least two VPC subnet IDs in different Availability Zones when deploying with a Timestream for InfluxDB DB cluster. | **CLI options: ** `--vpc-subnet-ids` **API parameter: **`vpcSubnetIds` |
| Failover mode | How your cluster responds to a primary instance failure. You can configure this with the following options: `AUTOMATIC`: If the primary instance fails, the system automatically promotes a read replica to become the new primary instance. `NO_FAILOVER`: If the primary instance fails, the system attempts to restore the primary instance without promoting a read replica. The cluster remains unavailable until the primary instance is restored. | **CLI options: ** `--failover-mode` **API parameter: **`failoverMode` |
**Important**
As part of the DB cluster response object, you will receive an `influxAuthParametersSecretArn`. This will hold an ARN to a Secrets Manager secret in your account. It will only be populated after your InfluxDB DB instances are available. The secret contains Influx authentication parameters provided during the `CreateDbInstance` process. This is a **read-only** copy as any updates/modifications/deletions to this secret doesn't impact the created DB instance. If you delete this secret, our API response will still refer to the deleted secret ARN.
# Connecting to a Timestream for InfluxDB read replica DB cluster
Connecting to a read replica DB cluster
A Timestream for InfluxDB read replica DB cluster has two reachable DB instances instead of a single DB instance. Each connection is handled by a specific DB instance. When you connect to a read replica DB cluster, the hostname and port that you specify point to a fully qualified domain name called an *endpoint*.
The primary (writer) endpoint connects to the writer DB instance of the read replica DB cluster, which supports both read and write operations. The reader endpoint connects to the reader DB instance, which support only read operations.
Using endpoints, you can map each connection to the appropriate DB instance based on your use case. For example, to perform administrative or write statements, you can connect to whichever DB instance is the writer DB instance. To perform queries, you can connect to the reader endpoint. For diagnosis or tuning, you can connect to a specific DB instance endpoint, `/metrics`, to examine details about a specific DB instance.
For information about connecting to a DB instance, see [Connecting to an Amazon Timestream for InfluxDB DB instance](timestream-for-influx-db-connecting.md). For more information about connecting to read replica clusters, see the following topics.
## Types of read replica cluster endpoints
Read replica cluster endpoint types
An endpoint is represented by a unique identifier that contains a host address. Each Timestream for InfluxDB cluster has:
+ A cluster endpoint.
+ A cluster read-only endpoint.
+ An instance endpoint for each instance in the cluster.
### Cluster endpoint
Cluster endpoint
A *cluster endpoint* (or *writer endpoint*) for a read replica cluster connects to the current writer DB instance for that DB cluster. This endpoint is the only one that can perform write operations such as:
+ InfluxDB-specific administrative commands, e.g., creating, modifying, or deleting organizations, users, buckets, tasks, etc.
+ Writing data to your database cluster.
You use the cluster endpoint for all write operations on the DB cluster, including writes, upserts, deletes, and all configuration and administrative changes.
In addition, you can use the cluster endpoint for read operations, such as queries.
If the current writer DB instance of a DB cluster fails, the read replica cluster automatically fails over to one of its replicas, promoting it as the new writer DB instance. During a failover, the DB cluster continues to serve connection requests to the cluster endpoint from the new writer DB instance, with minimal interruption of service. The read replica endpoint that was promoted to writer will stop serving reads until a new replica is deployed.
The following example illustrates a cluster endpoint for a read replica cluster:
```
ipvtdwa5se-wmyjrrjko.us-west-2.timestream-influxdb.amazonaws.com
```
### Read-only endpoint
Read-only endpoint
The *read-only endpoint* connects to any one of the read replica instances in the cluster. Read replicas will only support read operations, such as Flux or InfluxQL queries; in other words, all operations executed against the `/api/v2/query` endpoint for Flux queries or `/api/query` endpoint for InfluxQL v1-compatible queries. By processing those statements on the reader DB instances, this endpoint reduces the overhead on the writer DB instance. It also helps the cluster to handle a higher number of simultaneous queries.
The following example illustrates a reader endpoint for a read replica cluster. The read-only intent of a reader endpoint is denoted by the `-ro` within the cluster endpoint name.
```
ipvtdwa5se-wmyjrrjko-ro.us-west-2.timestream-influxdb.amazonaws.com
```
### Instance endpoint
Instance endpoint
An *instance endpoint* connects to a specific DB instance within a read replica cluster. Each DB instance in a DB cluster has its own unique instance endpoint. Therefore, there is one instance endpoint for the current writer DB instance of the DB cluster (the primary), and there is one instance endpoint for each of the reader DB instances in the DB cluster.
The instance endpoint provides direct control over connections to the DB cluster. This control can help you address scenarios where using the cluster endpoint or reader endpoint might not be appropriate. For example, your client application might require more fine-grained load balancing based on workload type. In this case, you can configure multiple clients to connect to different reader DB instances in a DB cluster to distribute read workloads.
The following example illustrates an instance endpoint for a DB instance in a read replica cluster:
```
mydbinstance-123456789012.us-east-1.timestream-influxdb.amazonaws.com
```
# Modifying a read replica cluster for Amazon Timestream for InfluxDB
Modifying a read replica cluster
A read replica cluster has a writer DB instance and a reader DB instance in separate Availability Zones. Read replica clusters provide high availability, increased capacity for read workloads, and faster failover when compared to Multi-AZ deployments. For more information about read replica clusters, see [Overview of Amazon Timestream for InfluxDB read replica clusters](timestream-for-influx-read-replica-overview.md).
You can modify a read replica cluster to change its settings.
**Important**
You can't modify the DB instances within a read replica cluster. All modifications must be done at the DB cluster level.
You can modify a read replica cluster using the Amazon Web Services Management Console, the Amazon CLI, or the Amazon Timestream for InfluxDB API.
## Modify a read replica cluster for Amazon Timestream for InfluxDB
Modify a read replica cluster
------
#### [ Using the Amazon Web Services Management Console ]
To modify a read replica DB cluster using the console:
1. Sign in to the [Amazon Web Services Management Console](https://console.amazonaws.cn/timestream) and open the Amazon Timestream console.
1. In the navigation pane, choose **InfluxDB databases** and then choose the read replica cluster you want to modify.
1. Choose **Modify**. The **Modify DB cluster** page appears.
1. Choose any of the settings that you want. For information about each setting, see [Settings for modifying read replica clusters](#timestream-for-influx-rr-modify-settings).
1. After you have made your changes, choose **Continue** and check the summary of modifications.
1. On the confirmation page, review your changes. If they're correct, choose **Modify DB cluster** to save your changes. Alternatively, choose **Back** to edit your changes or **Cancel** to cancel your changes.
**Important**
Currently Amazon Timestream for InfluxDB only supports **Apply Immediately** updates for the read replica cluster. If you confirm the changes, your DB cluster will incur downtime while the changes are being applied.
------
#### [ Using the Amazon CLI ]
To modify a DB instance using the Amazon Command Line Interface, use the `update-db-cluster` command with the following parameters. Replace each *user input placeholder* with your own information.
```
aws timestream-influxdb update-db-cluster \
--region region \
--db-cluster-id db-cluster-id \
--db-instance-type db.influx.4xlarge \
--port 10000 \
--failover mode NO_FAILOVER
```
------
## Settings for modifying read replica clusters
Settings for modifying read replica clusters
For details about settings that you can use to modify a read replica cluster, see the following table. For more information about the Amazon CLI options, see [update-db-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/timestream-influxdb/update-db-cluster.html).
****
| Console setting | Setting description | CLI option and Timestream for InfluxDB API parameter |
| --- | --- | --- |
| Database port | The port number on which InfluxDB accepts connections. Valid Values: 1024-65535 Default: 8086 Constraints: The value can't be 2375-2376, 7788-7799, 8090, or 51678-51680. | **CLI option: ** `--port` **API parameter: **`port` |
| DB instance type | The compute and memory capacity of each DB instance in your Timestream for InfluxDB DB cluster, for example db.influx.xlarge. If possible, choose a DB instance class large enough that a typical query working set can be held in memory. When working sets are held in memory, the system can avoid writing to disk, which improves performance. | **CLI option: ** `--db-instance-type` **API parameter: **`dbInstanceType` |
| DB cluster parameter group | The ID of the DB parameter group to assign to your DB cluster. DB parameter groups specify how the database is configured. For example, DB parameter groups can specify the limit for query concurrency. | **CLI option: ** `--db-parameter-group-identifier` **API parameter: **`dbParameterGroupIdentifier` |
| Log exports | Configuration for sending InfluxDB engine logs to a specified S3 bucket. Configuration for S3 bucket log delivery: `s3Configuration -> (structure)` The name of the S3 bucket to deliver logs to: `bucketName -> (string)` Indicate whether log delivery to the S3 bucket is enabled: `enabled -> (boolean)` Shorthand syntax: `s3Configuration={bucketName=string, enabled=boolean}` | **CLI option: ** `--log-delivery-configuration` **API parameter: **`logDeliveryConfiguration` |
| Failover mode | Configure how your cluster responds to a primary instance failure using the following options: `AUTOMATIC`: If the primary instance fails, the system automatically promotes a read replica to become the new primary instance. `NO_FAILOVER`: If the primary instance fails, the system attempts to restore the primary instance without promoting a read replica. The cluster remains unavailable until the primary instance is restored. | **CLI option: ** `--failover-mode` **API parameter: **`failoverMode` |
# Rebooting a read replica cluster in Amazon Timestream for InfluxDB
Rebooting a read replica cluster
You can reboot a read replica cluster in the event of any health issues.
## Rebooting a read replica cluster for Amazon Timestream for InfluxDB
Modify a read replica cluster
------
#### [ Using the Amazon Web Services Management Console ]
To reboot a read replica DB cluster using the console:
1. Sign in to the [Amazon Web Services Management Console](https://console.amazonaws.cn/timestream) and open the Amazon Timestream console.
1. In the navigation pane, choose **InfluxDB databases** and then choose the read replica cluster you want to reboot.
1. Choose **Restart database**.
1. Choose **Confirm and Restart**.
------
#### [ Using the Amazon CLI ]
To reboot a DB instance using the Amazon Command Line Interface, use the `reboot-db-cluster` command with the following parameters. Replace each *user input placeholder* with your own information.
```
aws timestream-influxdb reboot-db-cluster \
--region region \
--db-cluster-id db-cluster-id \
```
------
# Creating CloudWatch alarms to monitor Amazon Timestream for InfluxDB
Creating CloudWatch alarms to monitor Timestream for InfluxDB
You can create a CloudWatch alarm that sends an Amazon SNS message when the alarm changes state. An alarm watches a single metric over a time period that you specify. The alarm can also perform one or more actions based on the value of the metric relative to a given threshold over a number of time periods. The action is a notification sent to an Amazon SNS topic or Amazon EC2 Auto Scaling policy.
Alarms invoke actions for sustained state changes only. CloudWatch alarms don't invoke actions simply because they are in a particular state. The state must have changed and have been maintained for a specified number of time periods.
You can set CloudWatch alarms on any of the available metrics for Timestream for InfluxDB, including `CPUUtilization`, `MemoryUtilization`, `DiskUtilization`, and `ReplicaLag`.
We recommend to start creating `DiskUtilization`-related alarms for your Timestream for InfluxDB databases, since out-of-storage space issues can turn out to be fairly problematic to InfluxDB. We recommend setting alerts to be sent whenever `DiskUtilization` goes over approximately 75–80 percent.
## To set an alarm using the Amazon CLI
Set an alarm using the Amazon CLI
Call `put-metric-alarm`. For more information, see [put-metric-alarm](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/cloudwatch/put-metric-alarm.html) in the *Amazon CLI Command Reference*.
## To set an alarm using the CloudWatch API
Set an alarm using the CloudWatch API
Call `PutMetricAlarm`. For more information, see [PutMetricAlarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutMetricAlarm.html) in the *Amazon CloudWatch API Reference*. For more information about setting up Amazon SNS topics and creating alarms, see [Using Amazon CloudWatch alarms](https://docs.amazonaws.cn/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html).
## Tutorial: Create an Amazon CloudWatch alarm for Multi-AZ cluster replica lag for Amazon Timestream for InfluxDB
Create an Amazon CloudWatch alarm for Multi-AZ cluster replica lag for Amazon Timestream for InfluxDB
You can create an Amazon CloudWatch alarm that sends an Amazon SNS message when replica lag for a Multi-AZ DB cluster has exceeded a threshold. An alarm watches the `ReplicaLag` metric over a time period that you specify. The action is a notification sent to an Amazon SNS topic or Amazon EC2 Auto Scaling policy.
### To set a CloudWatch alarm for Multi-AZ DB cluster replica lag
Set a CloudWatch alarm for Multi-AZ DB cluster replica lag
1. Sign in to the Amazon Web Services Management Console and open the CloudWatch console at [https://console.aws.amazon.com/cloudwatch/](https://console.amazonaws.cn/cloudwatch).
1. In the navigation pane, choose **Alarms**, then **All alarms**.
1. Choose **Create alarm**.
1. On the **Specify metric and conditions** page, choose **Select metric**.
1. In the search box, enter the name of your DB cluster, select **Timestream/InfluxDB**, **By DbCluster**, and then select your cluster.
![\[The Select metric page showing an empty CloudWatch graph and two Timestream for InfluxDB sort options to choose from.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/select_metric_page.png)
1. The following image shows the **Select metric** page with a read replica cluster named `inframonitoringcluster` selected. Choose the metric you want to create an alarm for, in this case `ReplicaLag`. Click **Select metric**.
![\[The Select metric page showing an empty CloudWatch graph and seven CloudWatch metrics to choose from.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/select_metric_cluster_selected.png)
1. On the **Specify metric and conditions** page, customize the following fields:
![\[The Specify metric and conditions page showing settings selected for the inframonitoringcluster cluster.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/replica_lag_metrics_conditions.png)
1. Select a period of time for your calculations in the **Period** section.
1. Set up the conditions related to your alarm. For **Threshold type**, you can choose between **Static** and **Anomaly detection**.
In this case, we will use **Static** since we know how our workload behaves. Each workload might have different requirements when it comes to what is considered "healthy."
1. Select your threshold value. In the case of **Static** threshold values, these will be in milliseconds.
1. Choose **Next**.
1. On the **Configure actions** page, in the **Notification** section, customize the following settings:
![\[The Configure actions page showing a list of six different actions. The Notification section is completed.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/configure_actions.png)
1. For **Alarm state trigger**, select **In alarm**.
1. Choose **Create new topic** in **Send a notification to the following SNS topic**.
1. Enter a unique topic name and a valid email address that will receive the notification.
1. Choose **Create topic**. Scroll down and choose **Next**.
1. On the **Add name and description** page, enter an **Alarm name** and **Alarm description**. Choose **Next**.
![\[The Add name and description page showing fields for alarm name and alarm description.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/add_name_desc.png)
1. Review your alarm settings on the **Preview and create** page, and then choose **Create alarm**.
**Important**
To keep your Timestream for InfluxDB cluster in a healthy state, we also recommend monitoring and creating alarms for `CPUUtilization` and `MemoryUtilization` that consistently exceed a healthy 85 percent usage and `DiskUtilization` that exceeds 75 percent.
# Read replica licensing through Amazon Web Services Marketplace
Read replica licensing through Amazon Web Services Marketplace
To use Timestream for InfluxDB read replicas, you will need to activate the Timestream for InfluxDB read replicas add-on license through Amazon Web Services Marketplace. Once the license is active, you will pay an hourly rate to use read replica clusters. You will only pay for the hours your read replica cluster is active. If you subscribe to the license but have no active Timestream for InfluxDB read replica clusters, you will not be charged.
**Topics**
+ [
## Read replica licensing terminology
](#timestream-for-influx-rr-licensing-terminology)
+ [
## Payments and billing
](#timestream-for-influx-rr-license-billing)
+ [
## Subscribing to the InfluxDB read replica add-on on Marketplace listings
](#timestream-for-influx-subscribe-rr-add-on)
## Read replica licensing terminology
Terminology
This page uses the following terminology when discussing the Amazon Timestream for InfluxDB integration with Amazon Web Services Marketplace.
**SaaS subscription**
In Amazon Web Services Marketplace, software-as-a-service (SaaS) products such as the pay-as-you-go license model adopt a usage-based subscription model. InfluxData, the software seller for the read replica add-on, tracks your usage and you pay only for what you use.
**InfluxData Marketplace fees**
Fees charged for the InfluxDB read replica add-on software license usage by InfluxData. These service fees are metered through Amazon Web Services Marketplace and appear on your Amazon bill under the Amazon Web Services Marketplace section.
**Amazon Timestream for InfluxDB fees**
Fees that Amazon charges for the Amazon Timestream for InfluxDB services, which excludes licenses when using Timestream for InfluxDB read replica clusters. Fees are metered through the Amazon Timestream for InfluxDB service being used and appear on your Amazon bill.
## Payments and billing
Payments and billing
Timestream for InfluxDB integrates with Amazon Web Services Marketplace to offer hourly, pay-as-you-go licenses for the read replica add-on. The read replica Marketplace fees cover the license costs of the read replica add-on software, and the Amazon Timestream fees cover the costs of your Timestream for InfluxDB read replica cluster usage. For information about pricing, see [Amazon Timestream pricing](https://www.amazonaws.cn/timestream/pricing).
To stop these fees, you must delete any Timestream for InfluxDB read replica clusters. In addition, you can remove your subscriptions to Amazon Web Services Marketplace for read replica add-on license. If you remove your subscriptions without deleting your read replica clusters, Amazon Timestream will continue to bill you for the use of the read replica clusters. For more information, see [Considerations when deleting replicas](timestream-for-influx-read-replica-overview.md#timestream-for-influx-rr-deletion).
You can view bills and manage payments for your Timestream for InfluxDB read replica cluster in the Amazon Billing console. Your bills includes two charges: one for your usage of InfluxData's licensed add-on through Amazon Web Services Marketplace, and one for your usage of Amazon Timestream. For more information about billing, see [Understanding your bill](https://docs.amazonaws.cn/awsaccountbilling/latest/aboutv2/getting-viewing-bill.html) in the *Amazon Billing and Cost Management User Guide*.
## Subscribing to the InfluxDB read replica add-on on Marketplace listings
Subscribe to the InfluxDB read replica add-on
To use the read replica add-on license through Amazon Web Services Marketplace, you must use the Amazon Timestream Amazon Web Services Management Console to subscribe to the InfluxDB read replica add-on. You cannot complete these tasks through the Amazon CLI or the Timestream for InfluxDB API.
**Topics**
+ [
### Subscribe from Amazon Timestream Amazon Web Services Management Console
](#timestream-for-influx-subscribe-console)
+ [
### Subscribe to the InfluxDB read replica add-on in Amazon Web Services Marketplace
](#timestream-for-influx-subscribe-marketplace)
**Note**
If you want to create your read replica cluster by using the Amazon CLI or the Timestream for InfluxDB API, you must complete this step first.
### Subscribe from Amazon Timestream Amazon Web Services Management Console
Subscribe from Amazon Timestream Amazon Web Services Management Console
You can subscribe to the InfluxDB read replica add-on using the Timestream Management Console. Start the **Create InfluxDB Database** flow and follow the steps. For more information, see [Creating a Timestream for InfluxDB read replica cluster](timestream-for-influx-create-rr-cluster.md).
### Subscribe to the InfluxDB read replica add-on in Amazon Web Services Marketplace
Subscribe from Amazon Web Services Marketplace
To use the InfluxDB add-on license with Amazon Web Services Marketplace, you need to have an active Amazon Web Services Marketplace subscription for the InfluxDB read replica add-on. You will need to subscribe to a single add-on offer and that will allow you to create any instance type you need in any of the available regions. For information about Amazon Web Services Marketplace subscriptions, see [SaaS products through Amazon Web Services Marketplace](https://docs.amazonaws.cn/marketplace/latest/buyerguide/buyer-saas-products.html#saas-pricing-models) in the *Amazon Web Services Marketplace Buyer Guide*.
We recommend that you subscribe to InfluxDB in Amazon Web Services Marketplace *before* you start creating a DB instance.
1. Navigate to the [Amazon Web Services Marketplace](https://console.amazonaws.cn/marketplace) and search for InfluxData.
![\[Timestream for InfluxDB read replicas add-on appearing in Amazon Web Services Marketplace search.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/search_mkt_influxdb.png)
1. Select **Timestream for InfluxDB Read Replicas (Add-On)**.
1. Select **View purchase options**.
1. Review the End User License Agreement and choose **Subscribe**.
![\[Offer and pricing details for Timestream for InfluxDB read replicas add-on.\]](http://docs.amazonaws.cn/en_us/timestream/latest/developerguide/images/kronos/addon_details.png)
1. You can now create your Timestream for InfluxDB read replica cluster using the Timestream Management Console, CLI, or API.