View a markdown version of this page

管理叢集端點的 DNS 解析 - Amazon Timestream
了解 DNS 快取解決方案 1：設定 JVM DNS TTL (Java 應用程式）解決方案 2：透過授權名稱伺服器直接解析處理節點 IP 變更最佳實務

如需與 Amazon Timestream for LiveAnalytics 類似的功能，請考慮使用 Amazon Timestream for InfluxDB。它提供簡化的資料擷取和單一位數毫秒查詢回應時間，以進行即時分析。在這裡進一步了解。

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

管理叢集端點的 DNS 解析

InfluxDB 3 多節點叢集的 InfluxDB Timestream 使用 DNS 型流量分佈來平衡節點之間的連線。當容錯移轉發生或節點遭到取代時，DNS 記錄會自動更新以指向可用的執行個體。為了確保您的應用程式可以探索這些變更並維持最佳流量分佈，適當的 DNS 解析組態至關重要。

了解 DNS 快取

許多程式設計環境快取 DNS 查詢以改善效能。不過，此快取可能會讓您的應用程式無法在容錯移轉後探索更新的 IP 地址，或無法將連線分散到多個叢集節點。影響因語言和執行時間而異：

  • Java/JVM 型應用程式 — JVM 快取可設定time-to-live(TTL) 的 DNS 查詢。有些組態會無限期快取，直到 JVM 重新啟動為止。

  • 其他語言：Python、Go、Node.js 和其他執行時間通常依賴作業系統 DNS 解析，可能不會顯示相同的快取行為。

解決方案 1：設定 JVM DNS TTL (Java 應用程式）

對於連線至 Timestream for InfluxDB for InfluxDB 3 叢集端點的 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 資源，TTL 60 秒通常就足夠了。零 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 地址 (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 地址重試。

  • 正常連線耗盡 — 當 DNS 記錄集中不再有 IP 地址時，允許處理中的請求完成，但停止對該 IP 建立新的連線。

  • 建立新的連線 — 重新解析後，使用更新的 IP 地址建立新的連線。固定到舊 IPs現有連線將不會受益於重新解析。

最佳實務

  • 從 TTL 組態開始 — 對於 Java 應用程式，請務必networkaddress.cache.ttl=0先嘗試設定。這是最簡單且最有效的解決方案。

  • 謹慎使用直接解析 — 只在 TTL 組態不足或處理持久性中繼快取時，才使用授權名稱伺服器查詢。

  • 自動化名稱伺服器探索 — 請勿硬式編碼名稱伺服器地址。動態探索它們，因為名稱伺服器指派可能會變更。

  • 僅適用於叢集端點 — 這些技術適用於使用 DNS 型分佈的叢集層級端點 （寫入和讀取）。直接鎖定個別節點的節點特定端點不需要此組態。

  • 測試您的實作 — 確認您的應用程式已正確將連線分散到多個節點，並從模擬節點故障中復原。