AWS timestream documentation change
Summary
Added new FAQ entries about Core to Enterprise upgrade compaction, cluster endpoints, scaling operations, dedicated compactor, and maintenance windows
Security assessment
These are routine documentation updates about cluster operations, scaling, and maintenance features. No security-related content or evidence of addressing security vulnerabilities. Changes focus on operational guidance for upgrades, scaling, and maintenance scheduling.
Diff
diff --git a/timestream/latest/developerguide/faq-clusters.md b/timestream/latest/developerguide/faq-clusters.md index 2b79ad2c8..be70763c7 100644 --- a//timestream/latest/developerguide/faq-clusters.md +++ b//timestream/latest/developerguide/faq-clusters.md @@ -42,0 +43,14 @@ You can upgrade an existing Core cluster to Enterprise through the AWS Managemen +**What should I expect after upgrading from Core to Enterprise regarding compaction?** + + +Because Core edition does not include a compactor, all existing data must be compacted after the upgrade to Enterprise. How this affects your cluster depends on your configuration: + + * **Single-node clusters** : The compactor shares the same node as the writer and reader. You will likely need additional capacity (a larger instance type) to allow the compactor to process all existing data without impacting your running workload. Consider scaling up before or immediately after the upgrade, and scaling back down once compaction catches up. + + * **3-node clusters** : A dedicated compactor node is provisioned, but the full performance benefits of Enterprise (such as optimized query performance from compacted data) will not be realized until the compactor finishes processing all pre-existing data. The time required depends on the volume of data in the database, the current workload, and the instance size and configuration. + + + + +To speed up compaction, you can increase `compaction-max-num-files-per-plan` and reduce `compaction-check-interval` in your parameter group. Scaling up the instance type also gives the compactor more CPU and memory to work with. For details, see [Category 4: Compaction](./compaction-parameters.html) and [Upgrade from Core to Enterprise edition](./upgrading-core-to-enterprise.html). + @@ -47,0 +62,25 @@ Common causes include insufficient IAM permissions, invalid VPC subnet or securi +**What are cluster endpoints and how do they work?** + + +Multi-node Enterprise clusters provide two types of cluster endpoints: a **read/write endpoint** that routes traffic to writer/reader nodes, and a **read-only endpoint** that routes traffic to all nodes capable of read operations. There are also node-specific endpoints for direct access to individual nodes, but these are not recommended for production use as they do not provide automatic failover. For more information, see [Scaling a cluster](./multi-node-scaling.html). + +**What happens during a scaling operation?** + + +When you scale a cluster by applying a new parameter group, the cluster restarts to apply the new node configuration. For multi-node clusters using cluster endpoints, traffic is automatically redistributed to available nodes during the update process. Nodes are distributed across multiple Availability Zones for high availability. You can monitor the scaling progress through the cluster status, which shows `UPDATING` during the operation. For details, see [Scaling a cluster](./multi-node-scaling.html). + +**What is the dedicated compactor and when is it required?** + + +The dedicated compactor is a node that handles background data optimization tasks such as compacting Parquet files in Amazon S3. It is required for Enterprise clusters with 3 or more nodes (`dedicatedCompactor: true`). By running compaction on a separate node, write and read performance on your other nodes is not impacted by background optimization. Single-node Enterprise clusters handle compaction on the same node alongside read and write operations. + +**How do maintenance windows work?** + + +Every Timestream for InfluxDB resource has a weekly maintenance window during which routine maintenance such as OS patching and engine updates is performed. By default, the service manages the maintenance window automatically. You can specify a preferred window using the format `ddd:HH:MM-ddd:HH:MM` (for example, `Sun:02:00-Sun:04:00`) with a minimum duration of 2 hours and a maximum of 24 hours. For details, see [Maintenance windows for Timestream for InfluxDB 3](./influxdb3-maintenance-windows.html). + +**Can I set a maintenance window in my local timezone?** + + +Yes. You can specify a timezone for your maintenance window using IANA timezone identifiers such as `America/New_York`, `Europe/London`, or `Asia/Tokyo`. The `timezone` field is required when configuring a maintenance schedule. The system handles Daylight Saving Time transitions automatically. For the full list of supported timezones, see [Maintenance windows for Timestream for InfluxDB 3](./influxdb3-maintenance-windows.html). +