View a markdown version of this page

管理集群终端节点的 DNS 解析 - Amazon Timestream
了解 DNS 缓存解决方案 1：配置 JVM DNS TTL（Java 应用程序）解决方案 2：通过权威域名服务器直接解析处理节点 IP 变更最佳实践

要获得与亚马逊 Timestream 类似的功能 LiveAnalytics，可以考虑适用于 InfluxDB 的亚马逊 Timestream。适用于 InfluxDB 的 Amazon Timestream 提供简化的数据摄取和个位数毫秒级的查询响应时间，以实现实时分析。点击此处了解更多信息。

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

管理集群终端节点的 DNS 解析

适用于 InfluxDB 3 多节点集群的 InfluxDB Timestream 使用基于 DNS 的流量分配来平衡节点间的连接。当发生故障转移或节点被替换时，DNS 记录会自动更新以指向可用实例。为了确保您的应用程序能够发现这些变化并保持最佳的流量分布，正确的 DNS 解析配置至关重要。

了解 DNS 缓存

许多编程环境都会缓存 DNS 查找以提高性能。但是，这种缓存可以防止您的应用程序在故障转移后发现更新的 IP 地址，也无法在多个群集节点之间分配连接。影响因语言和运行时间而异：

  • 基于 Java/JVM 的应用程序 — JVM 缓存 DNS 查找以获取可配置的 (TTL)。 time-to-live有些配置会无限期缓存，直到 JVM 重新启动。

  • 其他语言 — Python、Go、Node.js 和其他运行时通常依赖操作系统 DNS 解析，可能不会表现出相同的缓存行为。

解决方案 1：配置 JVM DNS TTL（Java 应用程序）

对于连接到 InfluxDB 3 集群终端节点的 InfluxDB Timestream 的 Java 应用程序，请将 JVM DNS 缓存 TTL 设置为零。这样可以确保每个连接都会触发全新的 DNS 查找，从而实现适当的流量分配和即时故障转移检测。

检查您当前的 TTL 设置：

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

使用以下方法之一配置 TTL：

  • 全局配置-设置networkaddress.cache.ttl在$JAVA_HOME/jre/lib/security/java.security：

    networkaddress.cache.ttl=0

  • 特定于应用程序的配置-在建立网络连接之前，在应用程序初始化代码中设置该属性：

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

  • JVM 参数 — 启动应用程序时作为系统属性传递：

    java -Dsun.net.inetaddr.ttl=0 -jar your-application.jar
注意

对于非集群终端节点或常规 AWS 资源，60 秒的 TTL 通常就足够了。零 TTL 建议特定于 InfluxDB 3 集群端点，在这些端点中，流量分配和快速故障转移检测至关重要。

解决方案 2：通过权威域名服务器直接解析

如果 TTL 配置不足（例如，由于操作系统级缓存中间，或者您的编程语言不存在 DNS 缓存问题），则可以通过直接查询权威域名服务器来强制进行全新 DNS 解析。仅在标准 TTL 配置无法解决问题时才使用此方法。

直接解析工作流程

  1. 确定您的集群终端节点的权威域名服务器：

    dig <cluster-endpoint> NS

    在输出中，请注意后面列出的域名服务器。AUTHORITY SECTION IN SOA例如：ns-1458.awsdns-54.org。

  2. 直接查询权威域名服务器以绕过缓存：

    dig @ns-1458.awsdns-54.org <cluster-endpoint>

    这将返回端点的当前 IP 地址，反映基于 DNS 的实际流量分布。

  3. 使用已解析的 IP 地址进行应用程序连接。定期或在出现连接错误时重复此解决方法以刷新地址。

示例：

# Find authoritative nameserver
dig my-cluster.timestream-influxdb.us-east-1.amazonaws.com NS

# Resolve using authoritative nameserver
dig @ns-1458.awsdns-54.org my-cluster.timestream-influxdb.us-east-1.amazonaws.com

# Use returned IP addresses in your application

处理节点 IP 变更

重要

节点 IP 地址不是静态的。它们在故障转移、节点重启、维护操作和集群扩展期间会发生变化。切勿无限期缓存已解析的 IP 地址。

实施以下做法来处理 IP 变更：

  • 定期重新解析-使用后台任务每 30-60 秒重新解析端点。将新 IP 地址与缓存值进行比较，并相应地更新您的连接池。

  • 错误驱动的重新解决-当连接失败（超时、连接被拒绝、重置）时，请立即重新解析端点并使用更新后的 IP 地址重试。

  • 正常连接耗尽 — 当 IP 地址不再在 DNS 记录集中时，允许进行中的请求完成，但停止创建与该 IP 的新连接。

  • 创建新连接-重新解析后，使用更新的 IP 地址创建新连接。固定到旧连接的现有连接 IPs 不会从重新解析中受益。

最佳实践

  • 从 TTL 配置开始 — 对于 Java 应用程序，请务必networkaddress.cache.ttl=0先尝试进行设置。这是最简单、最有效的解决方案。

  • 谨慎使用直接解析 — 仅在 TTL 配置不足或处理持久中间缓存时才使用权威域名服务器查询。

  • 自动发现域名服务器——不要对域名服务器地址进行硬编码。动态发现它们，因为域名服务器分配可能会发生变化。

  • 仅适用于集群终端节点-这些技术适用于使用基于 DNS 的分发的集群级终端节点（写入和读取）。直接针对单个节点的特定于节点的端点不需要此配置。

  • 测试您的实现-验证您的应用程序是否正确地将连接分配到多个节点上，并从模拟的节点故障中恢复。