Amazon Timestream FAQs

Introduction | Database instances | Billing | Hardware | Database configuration | Multi-AZ deployments

To migrate to Timestream for InfluxDB from a self-managed InfluxDB instance, you can simply restore a backup from an existing InfluxDB database into a Timestream for InfluxDB instance with a few minutes of downtime. You can reconfigure your data collection agents, such as open source Telegraf agents, to target the InfluxDB endpoint managed by Timestream for InfluxDB. Dashboarding technologies, such as InfluxDB UI, self-hosted Grafana, or Amazon Managed Grafana, will continue to work by configuring them to use the Timestream for InfluxDB endpoint without any other code changes.

To migrate from Timestream for LiveAnalytics to Timestream for InfluxDB, you can export your data from Timestream for LiveAnalytics to Amazon S3, make any required modifications to the CSV files exported, and load it into Timestream for InfluxDB.

DB instances are simple to create using either the Amazon Web Services Management Console, Timestream for InfluxDB APIs, or Amazon CLI. To launch a DB instance using the Amazon Web Services Management Console, choose InfluxDB Databases and then select the Create InfluxDB Database button on the dashboard. From there, you can specify the parameters for your DB instance, including instance type, storage type and amount, primary user credentials, and more.

Alternatively, you can create your DB instance using the CreateDBInstance API or create-db-instance command.

You pay only for what you use and there are no minimum or setup fees. You are billed based on the following:

For Timestream for InfluxDB pricing information, visit the pricing page.

If you specify that your DB instance should be a Multi-AZ deployment, you will be billed according to the Multi-AZ pricing posted on the Timestream for InfluxDB pricing page. Multi-AZ billing is based on the following:

Choose the storage type that’s most suited for your workload.

By default, Timestream for InfluxDB chooses the optimal configuration parameters for your DB instance, taking into account the instance class and storage capacity. However, if you want to change them, you can do so using the Amazon Web Services Management Console, Timestream for InfluxDB APIs, or Amazon CLI. Note that changing configuration parameters from recommended values can have unintended effects, ranging from degraded performance to system crashes, and should only be attempted by advanced users who wish to assume these risks.

At launch, we will provide a limited set of parameters that will be able to be modified by you, and these include: flux-log-enabled, log-level, metrics-disable, no-tasks, query-concurrency, query-queue-size, and tracing-type. This list might grow over time based on customer requirements.

A DB parameter group acts as a container for engine configuration values that can be applied to one or more DB instances. If you create a DB instance without specifying a DB parameter group, a default DB parameter group is used. This default group contains engine defaults and Timestream for InfluxDB system defaults optimized for the DB instance that you’re running.

However, if you want your DB instance to run with your custom-specified engine configuration values, you can simply create a new DB parameter group, modify the desired parameters, and modify the DB instance to use the new DB parameter group. 

When you create or modify your DB instance to run as a Multi-AZ deployment, Timestream for InfluxDB automatically provisions and maintains a synchronous standby replica in a different Availability Zone. Updates to your DB instance are synchronously replicated across Availability Zones to the standby in order to keep both in sync and protect your latest database updates against DB instance failure. 

During certain types of planned maintenance, or in the unlikely event of DB instance failure or Availability Zone failure, Timestream for InfluxDB will automatically failover to the standby so that you can resume database writes and reads as soon as the standby is promoted. Since the name record for your DB instance remains the same, your application can resume database operation without the need for manual administrative intervention.

With Multi-AZ deployments, replication is transparent. You do not interact directly with the standby, and it cannot be used to serve read traffic.

The chief benefits of running your DB instance as a Multi-AZ deployment are enhanced database durability and availability. The increased availability and fault tolerance offered by Multi-AZ deployments make them a natural fit for production environments.

Running your DB instance as a Multi-AZ deployment safeguards your data in the unlikely event of a DB instance component failure or loss of availability in one Availability Zone.

For example, if a storage volume on your primary fails, Timestream for InfluxDB automatically initiates a failover to the standby, where all of your database updates are intact. This provides additional data durability relative to standard deployments in a single Availability Zone where a user-initiated restore operation would be required and updates that occurred after the latest restorable time (typically within the last 5 minutes) would not be available.

You also benefit from enhanced database availability when running your DB instance as a Multi-AZ deployment. If an Availability Zone failure or DB instance failure occurs, your availability impact is limited to the time automatic failover takes to complete. The availability benefits of Multi-AZ also extend to planned maintenance. Another implied benefit of running your DB instance as a Multi-AZ deployment is that DB instance failover is automatic and requires no administration. 

In order to create a Multi-AZ DB instance deployment, simply choose the Create a Standby Instance option for Multi-AZ Deployment when launching a DB instance with the Amazon Web Services Management Console. Alternatively, if you are using the Timestream for InfluxDB APIs, you would call the CreateDBInstance API and set the Multi-AZ parameter to the True value.

At this time, you will not be able to convert an existing Single-AZ Timestream for InfluxDB DB instance to Multi-AZ. The only way to achieve this would be to create a new Multi-AZ DB instance and migrate your workload to it.

Timestream for InfluxDB detects and automatically recovers from the most common failure scenarios for Multi-AZ deployments so that you can resume database operations as quickly as possible without administrative intervention. Timestream for InfluxDB automatically performs a failover in the event of any of the following:

Note: Timestream for InfluxDB Multi-AZ deployments do not fail over automatically in response to database operations, such as long running queries, deadlocks, or database corruption errors.

Failover is automatically handled by Timestream for InfluxDB so that you can resume database operations as quickly as possible without administrative intervention. When failing over, Timestream for InfluxDB simply flips the canonical name (CNAME) record for your DB instance to point at the standby, which is in turn promoted to become the new primary. We encourage you to follow best practices and implement database connection retry at the application layer.

Failovers, as defined by the interval between the detection of the failure on the primary and the resumption of transactions on the standby, typically complete within a couple of minutes. Failover time can also be affected by whether large, uncommitted transactions must be recovered, the size of the index, and other factors. The use of adequately large instance types is recommended with Multi-AZ for ideal results. We also recommend the use of Timestream for InfluxDB IOPS Included Storage with Multi-AZ instances for fast, predictable, and consistent throughput performance.