Managing DB instances - Amazon Timestream
Updating Db instancesMaintaining a DB instanceDeleting a DB instanceConfiguring and managing a multi-AZ deploymentMulti-AZ DB instance deploymentsFailover process for Amazon TimestreamSetting the JVM TTL for DNS name lookupsSetup to view InfluxDB Logs on Timestream Influxdb Instances

Managing DB instances

Updating DB instances

You can change the settings of a DB instance to accomplish tasks such as updating your engine configurations by updating your the assigned DbParameterGroup or updating your log delivery configuration. In this topic, you can find out how to update your Amazon Timestream for InfluxDB DB instance and learn about the settings for DB instances.

We recommend that you test any changes on a test instance before modifying a production instance. Doing this helps you to fully understand the impact of each change. Testing is especially important when upgrading database versions.

Modifications to your DB instance will be applied immediately and reboot your DB instance for the change to take effect.

Important

Some modifications result in downtime because Amazon Timestream for InfluxDB must reboot your DB instance for the change to take effect. Review the impact to your database and applications before updating your DB instance settings.

Using the AWS Management Console

  1. Sign in to the AWS Management Console and open the Amazon Timestream for InfluxDB console.

  2. In the navigation pane, choose InfluxDB Databases, and then choose the DB instance that you want to modify.

  3. Choose Update. The Update DB instance page appears.

  4. Change any of the settings that you want.

  5. Choose Continue and check the summary of modifications.

  6. Currently only Apply immediately is supported. This option can cause an outage in some cases since it will reboot your DB instance.

  7. On the confirmation page, review your changes. If they are correct, choose Update DB instance to save your changes and apply them. Or choose Back to edit your changes or Cancel to cancel your changes.

Using the AWS Command Line Interface

To update a DB instance by using the AWS Command Line Interface, call the update-db-instance command. Specify the DB instance identifier and the values for the options that you want to modify. For information about each option, see Settings for DB instances.

Example

The following code modifies mydbinstance by setting a different dbparametergroup. The changes are applied immediately.

For Linux, macOS, or Unix:

aws timestream-influxdb update-db-instance \
    --identifier mydbinstance \
    --db-parameter-group-name newparamgroup

For Windows:

aws timestream-influxdb update-db-instance ^
    --identifier mydbinstance ^
    --db-parameter-group-name newparamgroup

Maintaining a DB instance

Periodically, Amazon Timestream for InfluxDB performs maintenance on Amazon Timestream for InfluxDB resources. Maintenance most often involves updates to the following resources in your DB instance:

  • Underlying hardware

  • Underlying operating system (OS)

  • Database engine version

Updates to the operating system most often occur for security issues.

Some maintenance items require that Amazon Timestream for InfluxDB take your DB instance offline for a short time. Maintenance items that require a resource to be offline include required operating system or database patching. Required patching is automatically scheduled only for patches that are related to security and instance reliability. Such patching occurs infrequently, typically once every few months. It seldom requires more than a fraction of your maintenance window.

  • Maintenance windows are configured to take place everyday between 12 AM and 4 AM local time for the Region your instance is being hosted.

  • Customer resources might be patched once a week in any one of the seven maintenance windows in the week.

Deleting a DB instance

Considerations when deleting a DB instance

Deleting a DB instance has an effect on instance recoverability, and snapshot availability. Consider the following issues:

  • If you want to delete all Timestream for InfluxDB resources, note that the DB instances resources incur billing charges.

  • When the status for a DB instance is deleting, its CA certificate value doesn't appear in the Timestream for InfluxDB console or in output for AWS Command Line Interface commands or Timestream API operations.

  • The time required to delete a DB instance varies depending on how much data is deleted, and whether a final snapshot is taken.

You can delete a DB instance using the AWS Management Console, the AWS Command Line Interface, or the Timestream API. You must provide the name of the DB instance:

Using the AWS Management Console

  1. Sign in to the AWS Management Console and open the Amazon Timestream for InfluxDB console.

  2. In the navigation pane, choose InfluxDB Databases, and then choose the DB instance that you want to delete.

  3. Choose Delete.

  4. Enter confirm in the box.

  5. Choose Delete.

Using the AWS Command Line Interface

To find the instance IDs of the DB instances in your account, call the list-db-instances command:

aws timestream-influxdb list-db-instances \
--endpoint-url YOUR_ENDPOINT \
--region YOUR_REGION

To delete a DB instance by using the AWS CLI, call the delete-db-instance command with the following options:

aws timestream-influxdb list-db-instances \
--identifier YOUR_DB_INSTANCE \
Example

For Linux, macOS, or Unix:

aws timestream-influxdb delete-db-instance \
    --identifier mydbinstance

For Windows:

aws timestream-influxdb delete-db-instance ^
    --identifier mydbinstance

Configuring and managing a multi-AZ deployment

Timestream for InfluxDB Multi-AZ deployments can only have one standby. When the deployment has one standby DB instance, it's called a Multi-AZ DB instance deployment. A Multi-AZ DB instance deployment has one standby DB instance that provides failover support, but doesn't serve read traffic.

You can use the AWS Management Console to determine whether your DB instance is a Single-AZ or Multi-AZ deployment.

Using the AWS Management Console

  1. Sign in to the AWS Management Console and open the Amazon Timestream for InfluxDB console.

  2. In the navigation pane, choose InfluxDB Databases, and then choose DB identifier.

A Multi-AZ DB instance deployment has the following characteristics:

  • There is only one row for the DB instance.

  • The value of Role is Instance or Primary.

  • The value of Multi-AZ is Yes.

Multi-AZ DB instance deployments

Amazon Timestream for InfluxDB provides high availability and failover support for DB instances using Multi-AZ deployments with a single standby DB instance. This type of deployment is called a Multi-AZ DB instance deployment. Amazon Timestream for InfluxDB use the Amazon failover technology.

In a Multi-AZ DB instance deployment, Amazon Timestream automatically provisions and maintains a synchronous standby replica in a different Availability Zone. The primary DB instance is synchronously replicated across Availability Zones to a standby replica to provide data redundancy. Running a DB instance with high availability can enhance availability during DB instance failure and Availability Zone disruption. For more information on Availability Zones, see AWS Regions and Availability Zones.

Note

The high availability option isn't a scaling solution for read-only scenarios. You can't use a standby replica to serve read traffic.

Using the Amazon Timestream console, you can create a Multi-AZ DB instance deployment by simply specifying Create a standby instance option in the Availability and durability configuration section when creating a DB instance. You can also specify a Multi-AZ DB instance deployment with the AWS Command Line Interface or Amazon Timestream API. Use the create-db-instance or CLI command, or the CreateDBInstance API operation.

DB instances using Multi-AZ DB instance deployments can have increased write and commit latency compared to a Single-AZ deployment. This can happen because of the synchronous data replication that occurs. You might have a change in latency if your deployment fails over to the standby replica, although AWS is engineered with low-latency network connectivity between Availability Zones. For production workloads, we recommend that you use IOPS included storage 12K or 16K IOPS for fast, consistent performance. For more information about DB instance classes, see DB instance classes.

Failover process for Amazon Timestream

If a planned or unplanned outage of your DB instance results from an infrastructure defect, Amazon Timestream for InfluxDB automatically switches to a standby replica in another Availability Zone if you have turned on Multi-AZ. The time that it takes for the failover to complete depends on the database activity and other conditions at the time the primary DB instance became unavailable. Failover times are typically 60–120 seconds. However, large transactions or a lengthy recovery process can increase failover time. When the failover is complete, it can take additional time for the Timestream console to reflect the new Availability Zone.

Note

Amazon Timestream handles failovers automatically so you can resume database operations as quickly as possible without administrative intervention. The primary DB instance switches over automatically to the standby replica if any of the conditions described in the following table occurs.

Failover reason Description
The operating system underlying the Timestream database instance is being patched in an offline operation. A failover was triggered during the maintenance window for an OS patch or a security update.
The primary host of the Timestream Multi-AZ instance is unhealthy. The Multi-AZ DB instance deployment detected an impaired primary DB instance and failed over.
The primary host of the Timestream Multi-AZ instance is unreachable due to loss of network connectivity. Timestream monitoring detected a network reachability failure to the primary DB instance and triggered a failover.
The Timestream instance was modified by customer. An Timesteam for InfluxDB DB instance modification triggered a failover. For more information, see Updating DB instances.
The Timestream Multi-AZ primary instance is busy and unresponsive. The primary DB instance is unresponsive. We recommend that you do the following: * Examine the event for excessive CPU, memory, or swap space usage. * Evaluate your workload to determine whether you're using the appropriate DB instance class. For more information, see DB instance classes.
The storage volume underlying the primary host of the Timestream Multi-AZ instance experienced a failure. The Multi-AZ DB instance deployment detected a storage issue on the primary DB instance and failed over.

Setting the JVM TTL for DNS name lookups

The failover mechanism automatically changes the Domain Name System (DNS) record of the DB instance to point to the standby DB instance. As a result, you need to re-establish any existing connections to your DB instance. In a Java virtual machine (JVM) environment, due to how the Java DNS caching mechanism works, you might need to reconfigure JVM settings.

The JVM caches DNS name lookups. When the JVM resolves a host name to an IP address, it caches the IP address for a specified period of time, known as the time-to-live (TTL).

Because AWS resources use DNS name entries that occasionally change, we recommend that you configure your JVM with a TTL value of no more than 60 seconds. Doing this makes sure that when a resource's IP address changes, your application can receive and use the resource's new IP address by requerying the DNS.

On some Java configurations, the JVM default TTL is set so that it never refreshes DNS entries until the JVM is restarted. Thus, if the IP address for an AWS resource changes while your application is still running, it can't use that resource until you manually restart the JVM and the cached IP information is refreshed. In this case, it's crucial to set the JVM's TTL so that it periodically refreshes its cached IP information.

You can get the JVM default TTL by retrieving the networkaddress.cache.ttl property value:

String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
Note

The default TTL can vary according to the version of your JVM and whether a security manager is installed. Many JVMs provide a default TTL less than 60 seconds. If you're using such a JVM and not using a security manager, you can ignore the rest of this topic.

To modify the JVM's TTL, set the networkaddress.cache.ttl property value. Use one of the following methods, depending on your needs:

  • To set the property value globally for all applications that use the JVM, set networkaddress.cache.ttl in the $JAVA_HOME/jre/lib/security/java.security file.

    networkaddress.cache.ttl=60

  • To set the property locally for your application only, set networkaddress.cache.ttl in your application's initialization code before any network connections are established.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");

Setup to view InfluxDB Logs on Timestream Influxdb Instances

By default InfluxDB generates logs that go to stdout. For more information, see Manage InfluxDB logs

To view InfluxDB Logs generated from the Instance you have created through Timestream InfluxDB, we provide the opportunity to provide hourly logs. These logs will go to a specified S3 bucket that you must create before creating your instance.

  • Before creating the instance, the provided S3 bucket must also give Timestream-InfluxDB permission to send logs to this bucket by providing a bucket policy with Timestream InfluxDB Service Principal as following (replace {BUCKET_NAME} with the actual name of your Amazon S3 bucket:

    {
    "Version": "2012-10-17",
    "Id": "PolicyForInfluxLogs",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "timestream-influxdb.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::{BUCKET_NAME}/InfluxLogs/*"
        }
    ]
}

  • The bucket provided must be in the same account and same Region of your created Timestream InfluxDB instance

    Here is the command you can call to make an instance to receive influx logs:

    aws timestream-influxdb create-db-instance \
    --name myinfluxDbinstance \
    --allocated-storage 400 \
    --db-instance-type db.influx.4xlarge \
    --vpc-subnet-ids subnetid1 subnetid2
    --vpc-security-group-ids mysecuritygroup \    
    --username masterawsuser \
    --password \
    --db-storage-type InfluxIOIncludedT2

    Here is the format of this parameter.

    -- log-delivery-configuration
{
    "S3Configuration": {
      "BucketName": "string",
      "Enabled": true|false
    }
}

  • This field is not required and logging is not enabled by default.

  • Not setting this field is the same as not having logs enabled.

  • Logs will be sent to specified bucket with a prefix of InfluxLogs/.

  • After creating the instance, you can modify the log delivery configuration with the update-db-instance API command.

InfluxDB offers different types of logs. These can be configured by setting the InfluxDB Parameters. Use the flux-log-enabled and log-level parameters to configure the type of logs that is emitted from the instance. For more information, see Supported parameters and parameter values.