Amazon Timestream for LiveAnalytics に類似した機能をご希望の場合は Amazon Timestream for InfluxDB をご検討ください。リアルタイム分析に適した、シンプルなデータインジェストと 1 桁ミリ秒のクエリ応答時間を特徴としています。詳細については、こちらを参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
トラブルシューティング
「dev」バージョンが認識されないという警告
移行中に「WARN: Couldn't parse version "dev" reported by server, assuming latest backup/restore APIs are supported」という警告が表示される可能性があります。この警告は無視してかまいません。
復元ステージ中に移行が失敗した
復元ステージ中に移行が失敗した場合、ユーザーは --retry-restore-dir フラグを使用することで復元を再試行できます。前回バックアップされたディレクトリへのパスを含む --retry-restore-dir フラグを使用して、バックアップステージをスキップし、復元ステージを再試行します。復元中に移行が失敗した場合は、移行に使用された、作成済みのバックアップディレクトリが表示されます。
復元が失敗した原因としては、以下が考えられます。
InfluxDB 送信先トークンが無効 – バケットが、ソースインスタンスと同じ名前を持つ送信先インスタンスに存在しているため。個々のバケット移行では、
--dest-bucketオプションを使用して、移行済みバケットに一意の名前を設定します。送信元ホストまたは送信先ホストのいずれか、もしくは任意の S3 バケットにより接続に失敗したため。
Amazon Timestream for InfluxDB の基本的な運用ガイドライン
以下は、基本的な運用についてのガイドラインであり、Amazon Timestream for InfluxDB の使用時にすべてのユーザーが従う必要があります。Amazon Timestream for InfluxDB のサービスレベルアグリーメントでは、次のガイドラインに従う必要があります。
メトリクスを使用して、メモリ、CPU、ストレージの使用状況をモニタリングします。Amazon CloudWatch は、使用パターンが変更されたり、デプロイメントの最大容量に近づいたりすると、通知するように設定できます。このようにして、システムのパフォーマンスと可用性を維持できます。
最大ストレージ容量に近づいたら、DB インスタンスをスケールアップする。アプリケーションからのリクエストの予期しない増加に対応するために、ストレージとメモリにいくらかのバッファがあることが必要です。これを実現するには、この時点で、新しいインスタンスを作成してデータを移行する必要があります。
データベースのワークロードでプロビジョニングした I/O がより多く必要になると、フェイルオーバーやデータベース障害後の復旧が遅くなります。DB インスタンスの I/O 処理能力を高めるには、以下のいずれかまたはすべての操作を実行します。
I/O 処理能力がより高い別の DB インスタンスに移行します。
Influx IOPS 込みストレージを既に使用している場合は、より高い IOPS 込みでストレージタイプをプロビジョニングします。
クライアントアプリケーションが DB インスタンスのドメインネームサービス (DNS) のデータをキャッシュしている場合には、有効期限 (TTL) の値を 30 秒未満に設定します。DB インスタンスの基になる IP アドレスは、フェイルオーバー後に変更されている可能性があります。そのため、DNS データを長時間キャッシュすると、接続障害が発生する可能性があります。アプリケーションが、使用されなくなった IP アドレスに接続しようとする可能性があります。
DB インスタンスの RAM の推奨事項
Amazon Timestream for InfluxDB のパフォーマンスのベストプラクティスは、作業セットをほぼ完全にメモリ内に保持できるように十分な RAM を割り当てることです。作業セットは、インスタンスで頻繁に使用されるデータとインデックスです。DB インスタンスを使用するほど、作業セットが増大します。
