FAQ Amazon Timestream

Les données de séries temporelles sont une séquence de points de données, tels que les cours des actions, la température et l’utilisation du processeur d’une instance Amazon EC2, enregistrés au fil du temps. Dans le cas des données de séries temporelles, chaque point de données se compose d’un horodatage, d’un ou plusieurs attributs et de l’événement qui évolue dans le temps. Ces données sont utilisées pour obtenir des informations sur les performances et l’état d’une application, détecter les anomalies et identifier les opportunités d’optimisation.

Par exemple, les ingénieurs DevOps peuvent souhaiter consulter des données qui mesurent l’évolution des indicateurs de performance de l’infrastructure, les fabricants peuvent souhaiter suivre les données des capteurs IoT qui mesurent les variations de température d’un équipement dans une installation, et les spécialistes du marketing en ligne peuvent souhaiter analyser les données de parcours de navigation qui capturent la façon dont un utilisateur navigue sur un site web au fil du temps. Les données de séries temporelles étant générées à partir de sources multiples en volumes extrêmement élevés, elles doivent être stockées et analysées de manière rentable et en temps quasi réel pour obtenir des informations commerciales clés.

Amazon Timestream propose InfluxDB entièrement gérée, l’une des bases de données de séries temporelles open source les plus populaires du marché, et LiveAnalytics, une base de données de séries temporelle sans serveur conçue pour évoluer.

Oui, vous pouvez souscrire des Savings Plans de base de données pour votre utilisation d’Amazon Timestream et réduire vos coûts jusqu’à 20 % si vous vous engagez à utiliser une quantité constante sur une période d’un an. Des informations supplémentaires sur l’utilisation éligible sont disponibles sur la page de tarification des Savings Plans de base de données.

Vous pouvez commencer à utiliser Timestream à l’aide de la console de gestion AWS, de l’interface de la ligne de commande AWS (AWS CLI) ou des SDK. Pour plus d’informations, notamment des tutoriels et d’autres contenus sur la façon de démarrer, veuillez consulter le guide du développeur.

Amazon Timestream pour InfluxDB doit être utilisé pour les cas d’utilisation qui nécessitent des requêtes de séries temporelles en temps quasi réel et lorsque vous avez besoin de fonctionnalités InfluxDB ou d’API open source. Le moteur Timestream existant, Amazon Timestream pour LiveAnalytics, doit être utilisé lorsque vous devez ingérer plus de dizaines de gigaoctets de données de séries temporelles par minute et exécuter des requêtes SQL sur des téraoctets de données temporelles en quelques secondes.

Oui. Les deux moteurs se complètent pour une faible latence et une ingestion à grande échelle de données de séries temporelles. Vous pouvez ingérer des données dans Timestream pour InfluxDB et utiliser un plugin Telegraf pour envoyer des données dans Timestream afin d’analyser les données historiques via des requêtes SQL.

Si vous décidez de migrer vos données Timestream pour InfluxDB vers Timestream pour LiveAnalytics, vous devrez payer des frais de facturation publics pour l’utilisation de ce service, y compris l’ingestion, le stockage et les requêtes. Il est facultatif d’utiliser Timestream pour LiveAnalytics avec Timestream pour InfluxDB.

Timestream pour InfluxDB peut être utilisé séparément ou avec vos charges de travail Timestream pour LiveAnalytics. Timestream pour InfluxDB est destiné aux applications en temps quasi réel avec des temps de réponse à un chiffre en millisecondes. Timestream pour LiveAnalytics répond aux cas d’utilisation qui nécessitent d’ingérer des gigaoctets de données en quelques minutes et d’interroger des téraoctets de données en quelques secondes. Vous pouvez combiner Timestream pour InfluxDB et Timestream pour LiveAnalytics dans vos applications ou tableaux de bord.

Non. Timestream crée dynamiquement le schéma d’une table en fonction d’un ensemble d’attributs et de mesures dimensionnels. Cela permet une définition de schéma flexible et incrémentielle qui peut être ajustée à tout moment sans affecter la disponibilité.

Une fois que vos bases de données ont été créées et sont disponibles, vous pouvez récupérer les informations relatives aux points de terminaison depuis la console Timestream. Vous pouvez également utiliser l’API Describe pour récupérer les informations relatives aux points de terminaison (DescribeDatabase lors de l’utilisation de Timestream pour LiveAnalytics et DescribeDBInstances lors de l’utilisation de Timestream pour InfluxDB).

Vous pouvez visualiser vos données de séries temporelles Timestream et créer des alertes à l’aide de Grafana, un outil d’analytique et de visualisation interactif multiplateforme et open source. Pour en savoir plus et trouver des exemples d’applications, consultez la documentation.

Vous pouvez créer des fonctions AWS Lambda qui interagissent avec Timestream. Pour plus d’informations, consultez la documentation.

Vous pouvez envoyer les données de séries temporelles collectées à l’aide de Telegraf open source directement dans Timestream à l’aide du connecteur Telegraf. Pour plus d’informations, consultez la documentation.

Vous pouvez accéder à Timestream depuis votre Amazon Virtual Private Cloud (Amazon VPC) à l’aide de points de terminaison d’un VPC. Les points de terminaison d’un VPC Amazon sont faciles à configurer et fournissent une connectivité fiable aux API Timestream, sans nécessiter de passerelle Internet ni d’instance NAT.

AWS CloudFormation simplifie le provisionnement et la gestion en fournissant des modèles CloudFormation pour un provisionnement rapide et fiable des services ou des applications. CloudFormation fournit un support complet pour Timestream en fournissant des modèles pour créer des bases de données (à la fois pour Timestream pour LiveAnalytics et Timestream pour InfluxDB). Les modèles sont à jour avec la dernière annonce de Timestream pour InfluxDB et offrent flexibilité et facilité d’utilisation aux clients de Timestream.

Amazon Timestream pour LiveAnalytics est une base de données de séries temporelles rapide, évolutive et sans serveur conçue pour les charges de travail à grande échelle. Elle est sans serveur et s’adapte automatiquement à la hausse ou à la baisse pour ajuster la capacité et les performances. Vous n’avez donc pas besoin de gérer l’infrastructure sous-jacente. Son architecture entièrement découplée vous permet d’ingérer des milliards de points de données et d’exécuter des millions de requêtes par jour.

Le moteur de requête adaptatif Timestream pour LiveAnalytics vous permet d’accéder à des données récentes et historiques et de les analyser conjointement, sans avoir à spécifier leur emplacement. Il intègre des fonctions d’analytique des séries temporelles qui vous aident à identifier les tendances et les modèles de vos données en temps quasi réel.

Timestream pour LiveAnalytics est conçu pour collecter, stocker et traiter des données de séries temporelles. Son architecture sans serveur prend en charge des services d’ingestion de données, de stockage et de traitement des requêtes entièrement découplés qui peuvent évoluer indépendamment, permettant une mise à l’échelle pratiquement infinie pour répondre aux besoins de votre application. Plutôt que de prédéfinir le schéma au moment de la création de la table, le schéma d’une table Timestream est créé dynamiquement en fonction des attributs des données de séries temporelles entrantes, ce qui permet une définition de schéma flexible et incrémentielle.

Pour le stockage des données, Timestream pour LiveAnalytics partitionne les données par heure et par attributs, accélérant ainsi l’accès aux données à l’aide d’un index spécialement conçu. Les attributs de vos données, tels que le nom de la mesure ou la clé de partitionnement choisie, jouent un rôle essentiel dans le partitionnement efficace et la récupération performante de vos données. En outre, Timestream pour LiveAnalytics automatise la gestion du cycle de vie des données en proposant un stockage en mémoire pour les données récentes et un stockage magnétique pour les données historiques et en prenant en charge des règles configurables pour déplacer automatiquement les données de la mémoire vers la mémoire magnétique lorsqu’elles atteignent un certain âge.

Timestream pour LiveAnalytics simplifie également l’accès aux données grâce à son moteur de requêtes adaptatif spécialement conçu pour accéder aux données et les combiner de manière fluide sur différents niveaux de stockage sans avoir à spécifier leur emplacement. Vous pouvez ainsi obtenir rapidement et facilement des informations à partir de vos données à l’aide de SQL. Enfin, Timestream fonctionne parfaitement avec vos services de collecte de données, de visualisation, d’analytique et de machine learning (ML) préférés, ce qui vous permet d’inclure facilement Timestream dans vos solutions de séries temporelles.

Timestream pour LiveAnalytics offre une disponibilité de 99,99 %. Pour plus d’informations, consultez le contrat de niveau de service (SLA).

Avec Timestream pour LiveAnalytics, vous ne payez que pour ce que vous utilisez. Vous êtes facturé séparément pour les écritures, les données stockées et les données analysées par des requêtes. Timestream met automatiquement à l’échelle votre capacité d’écriture, de stockage et de requête en fonction de l’utilisation. Vous pouvez définir la politique de conservation des données pour chaque table et choisir de stocker les données dans un stockage en mémoire ou magnétique. Pour une tarification détaillée, consultez la page de tarification.

Oui, Timestream pour LiveAnalytics propose un essai gratuit d’un mois pour tous les nouveaux comptes. L’utilisation de l’essai gratuit est plafonnée à 50 Go d’ingestion, 100 Go de stockage magnétique, 750 Go-heures de stockage mémoire et 750 Go de données numérisées.

Vous êtes facturé au tarif standard de Timestream pour LiveAnalytics pour l’utilisation au-delà de ce que propose l’essai gratuit. Vous trouverez des informations supplémentaires sur la page des tarifs.

Pour connaître la disponibilité actuelle selon les régions, consultez la page de tarification.

Timestream pour LiveAnalytics offre des latences en temps quasi réel pour l’ingestion de données. La mémoire intégrée Timestream pour LiveAnalytics est optimisée pour les requêtes ponctuelles rapides, et la mémoire magnétique est optimisée pour prendre en charge les requêtes analytiques rapides. Avec Timestream pour LiveAnalytics, vous pouvez exécuter des requêtes qui analysent des dizaines de gigaoctets de données de séries temporelles provenant de la mémoire en quelques millisecondes et des requêtes analytiques qui analysent des téraoctets de données de séries temporelles provenant de la mémoire magnétique en quelques secondes. Les requêtes planifiées améliorent encore les performances des requêtes en calculant et en stockant les agrégats, les cumuls et d’autres analytiques en temps réel utilisées pour alimenter les tableaux de bord opérationnels, les rapports commerciaux, les applications et les systèmes de surveillance des appareils fréquemment consultés.

Vous pouvez stocker des exaoctets de données dans une seule table. Au fur et à mesure que vos données augmentent au fil du temps, Timestream pour LiveAnalytics utilise son architecture distribuée et son énorme parallélisme pour traiter de plus grands volumes de données tout en maintenant les latences des requêtes quasiment inchangées.

L’architecture sans serveur Timestream prend en charge des systèmes d’ingestion de données, de stockage et de traitement des requêtes entièrement découplés qui peuvent évoluer indépendamment. Timestream pour LiveAnalytics surveille en permanence les exigences de votre application en matière d’ingestion, de stockage et de taux de requêtes afin de se mettre à l’échelle instantanément sans durée d’indisponibilité pour l’application.

Pour connaître les limites et quotas actuels, consultez la documentation.

Vous pouvez collecter des données de séries temporelles à partir d’appareils connectés, de systèmes informatiques et d’équipements industriels, et les écrire dans Amazon Timestream pour LiveAnalytics. Vous pouvez envoyer des données à Timestream pour LiveAnalytics soit directement depuis votre application à l’aide des SDK AWS, soit depuis des services de collecte de données tels qu’AWS IoT Core, le service géré Amazon pour Apache Flink ou Telegraf. Pour plus d’informations, consultez la documentation.

Les données d’arrivée tardive sont des données dont l’horodatage remonte au passé et qui se situent en dehors de la limite de rétention de la mémoire. Les données futures sont des données qui ont un horodatage dans le futur. Timestream vous permet de stocker et d’accéder aux deux types.

Pour stocker les données d’arrivée tardive, il vous suffit de les écrire dans Timestream pour LiveAnalytics, et le service déterminera automatiquement si elles sont écrites dans la mémoire ou dans la mémoire magnétique en fonction de l’horodatage des données et de la période de conservation des données configurée pour la mémoire et les mémoires magnétiques. Pour stocker des données remontant à plus de 15 minutes, modélisez vos données sous la forme d’un enregistrement à mesures multiples et représentez l’horodatage futur sous forme de mesure dans l’enregistrement.

À l'aide du chargement par lots, vous pouvez intégrer des fichiers CSV stockés dans Amazon Simple Storage Service (Amazon S3) dans Timestream pour LiveAnalytics. Vous pouvez utiliser le chargement par lots pour remplir des données qui ne sont pas immédiatement requises pour l’analyse. Vous pouvez créer des tâches de chargement par lots à l’aide de la console de gestion AWS, de l’interface de ligne de commande AWS et des SDK AWS. Pour plus d’informations, consultez la documentation.

Vous pouvez collecter des données à partir de vos appareils IoT et les stocker dans Timestream à l’aide des actions de règles AWS IoT Core. Pour plus d’informations, consultez la documentation.

Vous pouvez utiliser Apache Flink pour transférer vos données de séries temporelles depuis Amazon Kinesis directement vers Timestream pour LiveAnalytics. Pour plus d’informations, consultez la documentation.

Vous pouvez utiliser Apache Flink pour envoyer vos données de séries temporelles depuis Amazon Managed Streaming pour Apache Kafka (Amazon MSK) directement vers Timestream pour LiveAnalytics. Pour plus d’informations, consultez la documentation.

Timestream organise et stocke les données de séries temporelles dans des partitions. Le partitionnement des données est déterminé par le service sur la base des attributs des données. Les attributs tels que timestamp et measure_name ou les clés de partition définies par le client jouent un rôle clé dans le choix des partitions. Consultez le blog de Werner Vogels pour plus de détails. Si vous souhaitez optimiser les performances de vos requêtes afin de mieux répondre à vos besoins spécifiques, nous vous recommandons d’utiliser des clés de partition définies par le client. À l'aide de Timestream, vous pouvez automatiser la gestion du cycle de vie des données en configurant simplement des politiques de conservation des données pour déplacer automatiquement les données de la mémoire vers la mémoire magnétique lorsqu’elles atteignent l’âge configuré.

Le magasin de mémoire Timestream pour LiveAnalytics est un magasin optimisé pour l’écriture qui accepte et dé-duplique les données de séries temporelles entrantes. Le stockage mémoire est également optimisé pour les requêtes ponctuelles sensibles à la latence.

Le magasin magnétique Timestream pour LiveAnalytics est un magasin optimisé pour la lecture, conçu pour exécuter des requêtes d’analytiques rapides pouvant analyser des centaines de téraoctets de données. Le stockage magnétique est également optimisé pour les requêtes d’analytiques rapides qui analysent des centaines de téraoctets de données.

Vous pouvez définir la période de conservation pour la mémoire et la mémoire magnétique. Les valeurs par défaut sont respectivement de 12 heures et 10 ans. Lorsque l’âge des données, déterminé par l’horodatage de l’enregistrement, dépasse la période de conservation configurée de la mémoire, Timestream pour LiveAnalytics classe automatiquement les données dans la mémoire magnétique. De même, si l’âge des données dépasse la période de conservation de la mémoire magnétique configurée, le service supprime automatiquement les données.

Timestream pour LiveAnalytics garantit la durabilité de vos données en répliquant automatiquement les données de votre mémoire et de votre stockage magnétique dans différentes zones de disponibilité au sein d’une même région. Toutes vos données sont écrites sur le disque avant que votre demande d’écriture ne soit considérée comme terminée.

Vous pouvez utiliser SQL pour interroger vos données de séries temporelles stockées dans Timestream. Vous pouvez également exécuter des fonctions d'analytique de séries temporelles à des fins d’interpolation, de régression et de lissage à l’aide de SQL. Pour en savoir plus, consultez la documentation. Le moteur de traitement de requêtes adaptatif de Timestream vous permet d’accéder aux données dans tous les niveaux de stockage à l’aide d'une seule instruction SQL. Il accède en toute transparence aux données et les combine à différents niveaux de stockage sans que vous ayez besoin de préciser l’emplacement des données. 

Les requêtes planifiées de Timestream pour LiveAnalytics constituent une solution évolutive, sans serveur et entièrement gérée de calcul et de stockage des agrégats, des synthèses et d’autres analytiques en temps réel utilisées dans les tableaux de bord opérationnels, les rapports d’activité, les applications et les systèmes de surveillance des appareils fréquemment consultés.

Avec les requêtes planifiées, il vous suffit de définir les requêtes d’analytique en temps réel qui calculent les agrégats, les cumuls et d’autres analytiques en temps réel sur vos données entrantes. Timestream exécute ces requêtes périodiquement et automatiquement et écrit de manière fiable les résultats des requêtes dans un tableau séparé. Vous pouvez ensuite pointer vos tableaux de bord, rapports, applications et systèmes de surveillance pour simplement interroger les tables de destination au lieu d’interroger les tables sources beaucoup plus grandes qui contiennent les données de séries temporelles entrantes. Cela permet de réduire considérablement les performances et les coûts, car les tables de destination contiennent beaucoup moins de données que les tables sources, ce qui permet d’accéder aux données et de les stocker plus rapidement et à moindre coût.

Vous pouvez utiliser les pilotes JDBC et ODBC pour connecter Timestream pour LiveAnalytics à vos outils d’intelligence économique préférés et à d’autres applications. Consultez la documentation JDBC et ODBC pour plus de détails.

Vous pouvez visualiser et analyser des données de séries temporelles dans Timestream pour LiveAnalytics à l’aide d’Amazon QuickSight et de Grafana. Vous pouvez également utiliser QuickSight pour vos besoins en matière de machine learning.

Vous pouvez créer des tableaux de bord riches et interactifs pour vos données de séries temporelles à l’aide de QuickSight. Pour plus d’informations, consultez la documentation.

Vous pouvez utiliser les blocs-notes Amazon SageMaker pour intégrer vos modèles de ML à Timestream pour LiveAnalytics. Pour plus d’informations, consultez la documentation.

Les données sont toujours chiffrées, qu’elles soient au repos ou en transit. Timestream pour LiveAnalytics vous permet de spécifier une clé gérée par le client AWS Key Management Service (AWS KMS) pour chiffrer les données dans le magasin magnétique.

Timestream pour LiveAnalytics est conforme aux normes ISO (9001, 27001, 27017 et 27018), PCI DSS, FedRAMP (modéré) et Health Information Trust (HITRUST) Alliance Common Security Framework (CSF). Il est également éligible à la loi HIPAA et entre dans le champ d’application des rapports AWS SOC 1, SOC 2 et SOC 3.

Deux options de sauvegarde sont disponibles pour vos ressources Timestream : les sauvegardes à la demande et les sauvegardes planifiées. Les sauvegardes à la demande sont des sauvegardes uniques qui peuvent être lancées depuis la console Timestream ou AWS Backup. Les sauvegardes à la demande sont utiles lorsque vous souhaitez créer une sauvegarde avant d’apporter à votre table une modification susceptible de vous obliger à annuler les modifications. Les sauvegardes planifiées sont des sauvegardes récurrentes que vous pouvez configurer, à l’aide des politiques AWS Backup, aux fréquences souhaitées (par exemple 12 heures, 1 jour, 1 semaine, etc.). Les sauvegardes planifiées sont utiles lorsque vous souhaitez créer des sauvegardes continues pour atteindre vos objectifs de protection des données.

La première sauvegarde, à la demande ou planifiée, de la table est une sauvegarde complète et chaque sauvegarde suivante de la même table est incrémentielle, copiant uniquement les données qui ont changé depuis la dernière sauvegarde. 

Les sauvegardes et les restaurations sont facturées en fonction de la taille du stockage de sauvegarde de la table sélectionnée, mesurée sur une base de Go-mois. Les frais seront indiqués dans la rubrique Sauvegarde de votre facture AWS et incluent les coûts liés au stockage des sauvegardes, aux transferts de données, aux restaurations et aux suppressions anticipées. Les sauvegardes étant de nature incrémentielle, la taille de stockage de la sauvegarde suivante de la table est la taille de la quantité de données modifiées depuis la dernière sauvegarde. Consultez la tarification AWS Backup pour plus de détails.

Pour commencer, vous devez activer AWS Backup pour protéger vos ressources Timestream pour LiveAnalytics (il s’agit d’une action unique). Une fois activé, accédez à la console de gestion AWS ou utilisez l’interface de ligne de commande ou le SDK d’AWS Backup pour créer des sauvegardes à la demande ou planifiées de vos données, puis copiez ces sauvegardes entre les comptes et les régions. Vous pouvez configurer la gestion du cycle de vie de vos sauvegardes en fonction de vos besoins en matière de protection des données. Pour plus d’informations, consultez la documentation sur la création d’une sauvegarde. 

Vous pouvez restaurer vos tables Timestream pour LiveAnalytics via laconsole de gestion AWS ou à l’aide de l’interface de ligne de commande ou du SDK AWS Backup. Sélectionnez l’ID du point de reprise pour la ressource que vous souhaitez restaurer et fournissez les entrées requises, telles que le nom de la base de données de destination, le nouveau nom de la table et les propriétés de conservation pour démarrer le processus de restauration. Une fois la restauration réussie, vous pouvez accéder aux données. Lorsque vous tentez de restaurer la dernière sauvegarde incrémentielle de votre table, toutes les données de la table sont restaurées. Pour en savoir plus, consultez la documentation.

Amazon Timestream pour InfluxDB est un nouveau moteur de base de données de séries temporelles qui permet aux développeurs d’applications et aux équipes DevOps d’exécuter facilement des bases de données InfluxDB sur AWS pour des applications de séries temporelles en temps réel à l’aide d’API open source. Avec Timestream pour InfluxDB, il est facile de configurer, d’exploiter et de mettre à l’échelle des charges de travail de séries temporelles capables de répondre à des requêtes avec des réponses à un chiffre en millisecondes.

Timestream pour InfluxDB prend en charge la version open source 2.7 d’InfluxDB. 

Vous devez utiliser Timestream pour InfluxDB si vous gérez vous-même InfluxDB, si vous souhaitez utiliser des API de séries temporelles open source ou si vous créez des applications de séries temporelles en temps réel qui nécessitent des réponses de requête à un chiffre en millisecondes. Avec Timestream pour InfluxDB, vous bénéficiez des avantages des API open source et d’un large éventail d’agents Telegraf open source pour collecter des données temporelles. Vous n’avez pas besoin de gérer des tâches complexes et chronophages, telles que l’installation, les mises à niveau, le stockage, la réplication pour une haute disponibilité et les sauvegardes d’InfluxDB.

Timestream pour InfluxDB fournit un SLA de 99,9 % de disponibilité lorsqu’il est déployé avec une configuration multi-AZ et de 99,5 % de disponibilité pour une configuration mono-AZ.

Timestream pour InfluxDB est conçu pour des cas d’utilisation de séries temporelles en temps quasi réel. En fonction des configurations de l’instance et des caractéristiques des charges de travail, vous pouvez vous attendre à une latence d’écriture/lecture d’environ 1 seconde avec une latence de requête de quelques millisecondes à un chiffre.

Pour migrer vers Timestream pour InfluxDB à partir d’une instance InfluxDB autogérée, vous pouvez simplement restaurer une sauvegarde d’une base de données InfluxDB existante vers une instance Timestream pour InfluxDB avec quelques minutes de durée d’indisponibilité. Vous pouvez reconfigurer vos agents de collecte de données, tels que les agents Telegraf open source, pour cibler le point de terminaison InfluxDB géré par Timestream pour InfluxDB. Les technologies de tableau de bord, telles que l’interface utilisateur InfluxDB, Grafana auto-hébergé ou Amazon Managed Grafana, continueront de fonctionner en les configurant pour utiliser le point de terminaison Timestream pour InfluxDB sans aucune autre modification de code.

Pour migrer de Timestream pour LiveAnalytics vers Timestream pour InfluxDB, vous pouvez exporter vos données de Timestream pour LiveAnalytics vers Amazon S3, apporter les modifications nécessaires aux fichiers CSV exportés et les charger dans Timestream pour InfluxDB.

Vous pouvez considérer une instance de base de données comme un environnement de base de données dans le cloud comprenant les ressources de calcul et de stockage que vous spécifiez. Vous pouvez créer et supprimer des instances de base de données, définir et affiner les attributs d’infrastructure de vos instances de base de données et contrôler l’accès et la sécurité via laconsole de gestion AWS, les API Timestream pour InfluxDB et l’interface de ligne de commande AWS. Vous pouvez exécuter une ou plusieurs instances de base de données et chaque instance de base de données peut prendre en charge une ou plusieurs bases de données (compartiments) ou organisations, en fonction des caractéristiques de la charge de travail et de la configuration de l’instance.

Les instances de base de données sont simples à créer à l’aide de la console de gestion AWS, des API Timestream pour InfluxDB ou de l’interface de ligne de commande AWS. Pour lancer une instance de base de données à l’aide de la console de gestion AWS, choisissez bases de données InfluxDB, puis sélectionnez le bouton Créer une base de données InfluxDB sur le tableau de bord. À partir de là, vous pouvez spécifier les paramètres de votre instance de base de données, notamment le type d’instance, le type et la quantité de stockage, les informations d’identification de l’utilisateur principal, etc.

Vous pouvez également créer votre instance de base de données à l’aide de l’API CreateDBInstance ou de la commande create-db-instance.

Une fois que votre instance de base de données est disponible, vous pouvez récupérer son point de terminaison via la description de l’instance de base de données dans la console de gestion AWS, l’API GetDBInstance ou la commande get-db-instance. À l’aide de ce point de terminaison et de votre jeton d’accès, vous pouvez utiliser les API InfluxDB pour envoyer des demandes d’écriture et de lecture, ainsi que pour gérer le moteur à l’aide de votre outil de base de données ou de votre langage de programmation préféré. Vous pouvez également accéder à l’interface utilisateur InfluxDB depuis votre navigateur en utilisant ce même point de terminaison. Afin d'autoriser les demandes de réseau vers votre instance de base de données en cours d’exécution, vous devez autoriser l'accès ou activer l’accès IP public.

Par défaut, vous êtes autorisé à disposer d’un total de 40 flux temporels pour les instances InfluxDB.

Vous ne payez que ce que vous utilisez et il n’a pas de frais minimums ou d’installation. Vous êtes facturé sur la base des éléments suivants :

• Heures d’instance de base de données : en fonction de la classe (par exemple, db.influx.large et db.influx.4xlarge) de l’instance de base de données consommée. Les heures d’instance de base de données partielles effectuées sont facturées par incréments d’une seconde, avec un minimum facturable de dix minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d’instance de base de données.
• Stockage (par Go-mois) : capacité de stockage que vous avez provisionnée pour votre instance de base de données. Si vous mettez à l’échelle votre capacité de stockage au cours du mois, votre facture sera ajustée au prorata.
• Transfert de données : transfert de données sur Internet entrant et sortant de votre instance de base de données.

Pour obtenir des informations sur les tarifs de Timestream pour InfluxDB, consultez la page de tarification.

La facturation commence dès que l’instance de base de données est disponible. La facturation se poursuit jusqu’à l’arrêt de l’instance de base de données, ce qui se produirait lors de la suppression ou en cas de défaillance de l’instance.

Les heures d’instance de base de données sont facturées pour chaque heure d’exécution de votre instance de base de données dans un état disponible. Si vous ne souhaitez plus être facturé pour votre instance de base de données, vous devez l’arrêter ou la supprimer afin que des heures d’instance supplémentaires ne vous soient pas facturées. Les heures d’instance de base de données partielles effectuées sont facturées par incréments d’une seconde, avec un minimum facturable de dix minutes, après un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d’instance de base de données.

Lorsque votre instance de base de données est arrêtée, le stockage provisionné vous est facturé, mais pas les heures d’ouverture de l’instance de base de données.

Si vous spécifiez que votre instance de base de données doit être un déploiement multi-AZ, vous serez facturé en fonction du prix multi-AZ posté sur la page de tarification Timestream pour InfluxDB. La facturation multi-AZ est basée sur les éléments suivants :

• Heures d’instance de base de données : en fonction de la classe (par exemple, db.influx.large et db.influx.4xlarge) de l’instance de base de données consommée. Comme pour les déploiements standard dans une seule zone de disponibilité, les heures partielles consommées par instance de base de données sont facturées par tranches d’une seconde, avec un minimum de 10 minutes à la suite d’un changement de statut facturable, tel que la création, le démarrage ou la modification de la classe d’instance de base de données. Si vous convertissez votre déploiement d’instance de base de données entre le mode standard et multi-AZ dans une heure donnée, les deux tarifs s’appliqueront pour cette heure.
• Stockage provisionné (pour une instance de base de données multi-AZ) : si vous convertissez votre déploiement entre standard et multi-AZ au cours d’une heure donnée, le tarif de stockage applicable pour cette heure vous sera facturé le plus élevé des tarifs de stockage applicables.
• Transfert de données : le transfert de données lié à la réplication des données entre votre appareil principal et votre serveur de secours ne vous est pas facturé. Le transfert de données sur Internet entrant et sortant de votre instance de base de données est facturé de la même façon qu’avec un déploiement standard.

Sauf indication contraire, nos prix n’incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes. Pour les clients dont l’adresse de facturation est située au Japon, l’utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. 

• Votre facture de cluster Timestream pour InfluxDB Read Replica est calculée par instance au sein du cluster, selon les prix indiqués sur la page de tarification de Timestream pour InfluxDB. La structure de facturation comprend quatre éléments principaux :
  Les heures d’ouverture des nœuds de cluster sont facturées en fonction de la classe d’instance que vous avez sélectionnée (par exemple, db.influx.large ou db.influx.4xlarge). Nous facturons par tranches d’une seconde avec un minimum de 10 minutes après tout changement de statut facturable, y compris la création, le démarrage ou la modification d’une classe d’instance. Si vous passez d’un type de cluster à un autre en moins d’une heure, les deux tarifs applicables vous seront facturés pendant cette période.
• Pour le stockage, vous serez facturé en fonction de la capacité que vous avez provisionnée. Lors de la conversion entre types de déploiement (cluster, base de données standard ou multi-AZ) dans un délai d’une heure, nous appliquons le plus élevé des taux de stockage applicables pour cette heure.
• En ce qui concerne le transfert de données, vous n’aurez pas à payer de frais pour la réplication des données entre votre instance principale et votre instance de réplication. Cependant, le transfert de données Internet vers et depuis votre cluster de bases de données est soumis au même tarif que les déploiements standard.
• La fonctionnalité Read Replica est fournie par le biais d’un module complémentaire sous licence créé et vendu par InfluxData et qui sera activé via AWS Marketplace. Cette licence fonctionne selon un modèle de paiement à l’utilisation, avec des frais basés sur les heures de votre instance en fonction du nombre de vCPU dans votre classe d’instance configurée.
  

Afin de sélectionner votre classe d'instance de base de données et votre capacité de stockage initiales, vous devez évaluer les besoins de calcul, de mémoire et de stockage de votre application. Pour plus d’informations sur les classes d’instance de base de données disponibles, consultez le guide de l’utilisateur Timestream pour InfluxDB.

Le stockage inclus Timestream pour InfluxDB IOPS est une option de stockage sur SSD conçue pour fournir des performances d’E/S rapides, prévisibles et cohérentes. Avec le stockage inclus Timestream pour InfluxDB IOPS, vous avez le choix entre trois niveaux, allant des petites charges de travail aux charges de travail optimisées à grande échelle et aux hautes performances optimisées. Vous ne spécifiez que la taille de volume allouée au niveau qui correspond le mieux à vos besoins. Le stockage inclus Timestream pour InfluxDB IOPS est optimisé pour les charges de travail de base de données transactionnelles (OLTP) gourmandes en E/S. Pour plus de détails, consultez le guide de l’utilisateur Timestream pour InfluxDB.

Choisissez le type de stockage le plus adapté à votre charge de travail.

• Charges de travail OLTP hautes performances  : Timestream pour InfluxDB IOPS, stockage inclus.

Par défaut, Timestream pour InfluxDB choisit les paramètres de configuration optimaux pour votre instance de base de données, en tenant compte de la classe d’instance et de la capacité de stockage. Toutefois, si vous souhaitez les modifier, vous pouvez le faire à l’aide de la console de gestion AWS, de Timestream pour les API InfluxDB ou de l’interface de ligne de commande AWS. Notez que la modification des paramètres de configuration par rapport aux valeurs recommandées peut avoir des effets imprévus, allant de la dégradation des performances à des pannes du système, et ne doit être tentée que par des utilisateurs expérimentés qui souhaitent assumer ces risques.

Au lancement, nous fournirons un ensemble limité de paramètres que vous pourrez modifier, notamment : l’activation du journal des flux, le niveau de journalisation, la désactivation des métriques, l’absence de tâches, la simultanéité des requêtes, la taille de la file d’attente et le type de suivi. Cette liste peut s’allonger au fil du temps en fonction des besoins des clients.

Un groupe de paramètres de base de données agit comme un conteneur pour les valeurs de configuration du moteur qui peuvent être appliquées à une ou plusieurs instances de base de données. Si vous créez une instance de base de données sans spécifier de groupe de paramètres de base de données, un groupe de paramètres de base de données par défaut est utilisé. Ce groupe par défaut contient les valeurs par défaut du moteur et les valeurs par défaut du système Timestream pour InfluxDB optimisées pour l’instance de base de données que vous exécutez.

Toutefois, si vous souhaitez que votre instance de base de données s’exécute avec les valeurs de configuration de votre moteur personnalisées, vous pouvez simplement créer un nouveau groupe de paramètres de base de données, modifier les paramètres souhaités et modifier l’instance de base de données pour utiliser le nouveau groupe de paramètres de base de données. 

Lorsque vous créez ou modifiez votre instance de base de données pour qu’elle s’exécute en tant que déploiement multi-AZ, Timestream pour InfluxDB provisionne et gère automatiquement une réplique de secours synchrone dans une zone de disponibilité différente. Les mises à jour vers votre instance de base de données sont répliquées de manière synchrone sur les zones de disponibilité vers l’instance de secours, afin qu’elles restent toutes deux synchronisées et qu’elles protègent vos dernières mises à jour de base de données contre une défaillance d’instance DB. 

Lors de certains types de maintenance planifiée, ou dans le cas peu probable d’une défaillance d’une instance de base de données ou d’une défaillance de la zone de disponibilité, Timestream pour InfluxDB bascule automatiquement vers le mode veille afin que vous puissiez reprendre les écritures et les lectures de la base de données dès que le mode veille sera promu. Étant donné que l’enregistrement de nom pour votre instance de base de données reste le même, votre application peut reprendre les opérations de base de données sans qu’une intervention manuelle d’administration soit nécessaire.

Avec les déploiements multi-AZ, la réplication est transparente. Vous n’interagissez pas directement avec l’instance de secours, et elle ne prend pas en charge le trafic de lecture.

Les zones de disponibilité sont des emplacements distincts au sein d’une région qui sont conçus pour être isolés des pannes dans d’autres zones de disponibilité. Chaque zone de disponibilité fonctionne sur sa propre infrastructure indépendante et physiquement distincte et est conçue pour être extrêmement fiable. Les points de défaillance courants tels que les générateurs et les équipements de refroidissement ne sont pas partagés entre les zones de disponibilité. En outre, elles sont physiquement séparés. Ainsi même un sinistre extrêmement rare, comme un incendie, une tempête ou une inondation, n’affecterait qu’une seule zone de disponibilité. Les zones de disponibilité dans la même région bénéficient d’une connectivité de réseau avec une faible latence.

Lorsque vous exécutez une instance de base de données en tant que déploiement multi-AZ, la principale sert à écrire et à lire la base de données. En outre, Timestream pour InfluxDB fournit et maintient une instance de secours en coulisse, qui est une réplique à jour de la version principale. L’instance de secours est encouragée dans les scénarios de basculement. Après le basculement, l’instance secours devient l’instance principale et accepte vos opérations de base de données. Vous n’interagissez pas directement avec l’instance de secours (par exemple, pour les opérations de lecture) à aucun moment avant la promotion.

Les avantages principaux de l’exécution de votre instance de base de données en tant que déploiement multi-AZ sont une durabilité et une disponibilité de la base de données améliorées. La disponibilité améliorée et la tolérance de panne offertes par les déploiements Multi-AZ en font le choix naturel pour les environnements de production.

En exécutant votre instance de base de données sous forme de déploiement multi-AZ, vos données sont protégées dans le cas peu probable d’une défaillance d’un composant d’une instance de base de données ou d’une perte de disponibilité dans une zone de disponibilité.

Par exemple, si un volume de stockage sur votre disque principal tombe en panne, Timestream pour InfluxDB lance automatiquement un basculement vers le support de secours, où toutes les mises à jour de votre base de données sont intactes. Cela fournit une durabilité des données supplémentaire par rapport aux déploiements standard dans une zone de disponibilité unique où une opération de restauration initiée par l’utilisateur serait requise et où les mises à jour effectuées après la dernière période de restauration (généralement au cours des 5 dernières minutes) ne seraient pas disponibles.

Vous profitez également d’une disponibilité de base de données améliorée lorsque votre instance de base de données est exécutée en tant que déploiement multi-AZ. Si une défaillance de zone de disponibilité ou d'instance DB se produit, l'impact sur votre disponibilité est limité à la durée de mise en place du basculement. Les avantages de la disponibilité multi-AZ s’étendent également jusqu’à la maintenance planifiée. Un autre avantage implicite d’exécuter votre instance de base de données en tant que déploiement multi-AZ est le fait que le basculement d’instance de base de données est automatique et ne nécessite pas d’administration. 

Vous pouvez observer des temps de latence élevés par rapport à un déploiement d’instance de base de données standard dans une seule zone de disponibilité, du fait de la réplication synchrone des données réalisée pour votre compte.

Non, l’instance de secours multi-AZ ne peut pas répondre aux demandes de lecture. Les déploiements multi-AZ sont conçus pour fournir une disponibilité et durabilité de base de données améliorées, plutôt que des avantages de dimensionnement en lecture. À ce titre, la fonction utilise la réplication synchrone entre les instances principales et de secours. Notre implémentation veille à ce que les instances principales et de secours soient constamment synchronisées, mais exclut l’utilisation de l’instance de secours pour les opérations de lecture ou d’écriture.

Pour créer un déploiement d’instance de base de données multi-AZ, il vous suffit de choisir l’option Créer une instance de secours pour le déploiement multi-AZ lors du lancement d’une instance de base de données avec la console de gestion AWS. Sinon, si vous utilisez les API Timestream pour InfluxDB, vous pouvez appeler l’API CreateDBInstance et définir le paramètre multi-AZ sur la valeur Exact.
Vous pouvez également modifier l’une de vos instances existantes et définir le type de déploiement sur multi-AZ.

Timestream pour InfluxDB détecte et récupère automatiquement les scénarios de défaillance les plus courants pour les déploiements multi-AZ afin que vous puissiez reprendre les opérations de base de données le plus rapidement possible sans intervention administrative. Timestream pour InfluxDB effectue automatiquement un basculement dans les cas suivants :

• Perte de disponibilité dans la zone de disponibilité principale
• Perte de connectivité réseau avec le serveur principal
• Échec d'unité de calcul sur le serveur principal
• Échec de stockage sur l’instance principale

Remarque : les déploiements multi-AZ Timestream pour InfluxDB ne basculent pas automatiquement en réponse à des opérations de base de données, telles que des requêtes de longue durée, des blocages ou des erreurs de corruption de base de données.

Le basculement est automatiquement géré par Timestream pour InfluxDB afin que vous puissiez reprendre les opérations de base de données le plus rapidement possible sans intervention administrative. En cas de panne, Timestream pour InfluxDB retourne simplement l’enregistrement du nom canonique (CNAME) de votre instance de base de données pour qu’il pointe vers la zone de secours, qui est à son tour promue pour devenir la nouvelle instance principale. Nous vous encourageons à suivre les bonnes pratiques et à implémenter une nouvelle tentative de connexion de base de données au niveau de la couche d’application.

Les basculements, tels que définis par l’intervalle entre la détection de la panne sur le serveur principal et la reprise des transactions sur le serveur de secours, se terminent généralement en quelques minutes. Le temps de basculement peut également être affecté par la nécessité de récupérer des transactions importantes non validées, par la taille de l’index et par d’autres facteurs. L’utilisation de types d’instances suffisamment grands est recommandée avec multi-AZ pour de meilleurs résultats. AWS recommande également d’utiliser le stockage inclus Timestream pour InfluxDB IOPS avec les instances multi-AZ pour des performances de débit rapides, prévisibles et cohérentes.

Timestream pour InfluxDB bascule automatiquement sans intervention de l’utilisateur dans diverses conditions de défaillance. Pour le moment, vous ne pouvez pas lancer manuellement un basculement forcé de votre instance de base de données Timestream pour InfluxDB.

Avec les déploiements multi-AZ, vous définissez simplement le paramètre Multi-AZ sur Exact. La création de l’instance de secours, de la réplication synchrone et du basculement est traitée automatiquement. Ceci signifie que vous ne pouvez pas sélectionner la zone de disponibilité dans laquelle votre instance de secours est déployée ou modifier le nombre d’instances de secours disponibles ((Timestream pour InfluxDB provisionne une instance de secours dédiée par instance de base de données principale). Par ailleurs, la réplique de secours ne peut pas être configuré pour accepter des activités en lecture de base de données.

Oui, votre instance de secours est automatiquement provisionnée dans une zone de disponibilité différente de la même région que celle de votre instance de base de données principale.

Oui, vous pouvez obtenir une visibilité sur l’emplacement du serveur principal actuel à l’aide de la console de gestion AWS ou de l’API GetDBInstance.

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. En outre, vous pourriez envisager d’avoir une architecture avec redondance pour votre application et d’autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d’une zone de disponibilité. Les déploiements multi-AZ répondent à ce besoin pour le niveau de base de données sans administration de votre part.

Un cluster Timestream pour InfluxDB Read Replica améliore la disponibilité et la capacité de mise à l’échelle de lecture de votre base de données. Lorsque vous créez un cluster, Timestream pour InfluxDB provisionne et gère automatiquement au moins une réplique lisible asynchrone dans une zone de disponibilité différente. Les mises à jour de votre nœud primaire sont répliquées de manière asynchrone vers ces répliques en lecture, ce qui vous permet de répartir la charge de travail de vos requêtes sur plusieurs nœuds.

Le cluster prend en charge le basculement automatique lors d’une maintenance planifiée ou dans le cas peu probable d’une défaillance d’un nœud ou d’une zone de disponibilité. En cas de basculement, vos applications peuvent continuer à fonctionner sans intervention manuelle puisque les points de terminaison d’écriture et de lecture conservent les mêmes enregistrements de nom. Cependant, il est important de noter que lors de la période de restauration, pendant que nous restaurons le nœud défaillant et le rétablissons en tant que réplique de lecture, les applications utilisant les points de terminaison du nœud de réplication pour la lecture seront temporairement indisponibles.

Dans un cluster Read Replica, le nœud primaire gère toutes les écritures de base de données, lit et gère les configurations et les fonctions administratives spécifiques au moteur. Parallèlement, Timestream pour InfluxDB provisionne et gère automatiquement une réplique de lecture qui reste à jour avec le nœud primaire. Read Replica a deux objectifs principaux : étendre votre capacité de lecture en acceptant des demandes de lecture supplémentaires, et être promu au rang principal lors de scénarios de basculement. Lors d’un événement de basculement, lorsque Read Replica est promu au rang principal, toutes les opérations de base de données sont prises en charge. Une fois que le nœud précédemment défaillant redevient opérationnel, il rejoint le cluster en tant que réplique de lecture, préservant ainsi la résilience du cluster.

Les clusters Read Replica offrent trois avantages clés : une capacité de mise à l’échelle accrue, une disponibilité accrue et une optimisation de la charge de travail. La capacité de mise à l’échelle accrue provient de votre capacité à répartir les charges de travail de lecture sur plusieurs nœuds de cluster, ce qui la rend particulièrement utile pour les applications où les exigences en lecture l’emportent largement sur les opérations d’écriture.

Lorsqu’ils sont configurés avec le basculement activé, les clusters Read Replica offrent une disponibilité accrue grâce à des fonctionnalités de basculement plus rapides. Étant donné que tous les nœuds du cluster restent actifs, vous pouvez promouvoir une réplique au rang de serveur principal sans attendre le démarrage du nœud, afin de minimiser les durées d’indisponibilité lors des scénarios de basculement.

En outre, les clusters Read Replica permettent une gestion efficace de la charge de travail. Vous pouvez dédier votre nœud primaire à la gestion des requêtes simples et rapides généralement utilisées pour les tableaux de bord, les alarmes et les notifications en temps réel, tout en dirigeant les requêtes analytiques plus complexes vers vos répliques de lecture. Cette séparation garantit des performances optimales pour différents types de charges de travail.

Le processus de réplication a démontré un impact négligeable sur les performances, avec un effet minimal sur la consommation du processeur ou de la mémoire. Il est toutefois important de noter que le délai de réplication, c’est-à-dire le délai entre le moment où un enregistrement est accepté sur le serveur principal et le moment où il devient disponible dans les répliques en lecture, peut varier en fonction du niveau de charge de vos nœuds de réplication.

Timestream pour InfluxDB publie une métrique CloudWatch appelée « ReplicaLag » qui vous permet de surveiller l’état de synchronisation de vos répliques en lecture. Cette métrique, mesurée en millisecondes, permet de suivre la distance entre les répliques et le nœud primaire. La latence de réplication peut être affectée par les niveaux de charge de votre base de données. Nous recommandons donc aux clients de surveiller activement cette métrique afin de s’assurer que leurs répliques en lecture conservent des niveaux de synchronisation acceptables pour leur cas d’utilisation.

Pour configurer un cluster Read Replica dans Timestream pour InfluxDB, commencez par vous connecter à la console de gestion AWS et accédez à la console Amazon Timestream. Choisissez « Créer une base de données InfluxDB » dans la section Bases de données InfluxDB. Lors de la configuration des paramètres de déploiement, sélectionnez « Cluster de bases de données avec répliques en lecture ». Vous devez activer un abonnement via AWS Marketplace, ce qui nécessite les autorisations AWSMarketplaceManageSubscriptions ou AWSMarketplaceFullAccess. Après avoir confirmé votre abonnement, fournissez les informations de configuration de base et sélectionnez le nœud et les classes de stockage appropriés qui s’appliqueront à tous les nœuds de votre cluster.

Non, dans un cluster Read Replica, il ne peut y avoir qu’un seul nœud primaire qui gère les opérations d’écriture à un moment donné. Le nœud primaire répond à toutes les demandes d’écriture tout en gérant les lectures de base de données, les configurations spécifiques au moteur et les fonctions administratives. Les répliques de lecture sont tenues à jour avec ce nœud primaire et ne peuvent accepter que les demandes de lecture. Bien qu’il soit possible de promouvoir une réplique en lecture pour qu’elle devienne la principale lors de scénarios de basculement, l’architecture du cluster utilise un modèle à écriture unique pour garantir la cohérence des données.

Pour les clusters Read Replica, vous pouvez activer ou désactiver la fonction de basculement lors de la création ou de la modification du cluster. Lorsque cette option est activée, la gestion des répliques, des processus de réplication et de basculement est gérée automatiquement par Timestream pour InfluxDB. Vous ne pouvez pas sélectionner de zones de disponibilité spécifiques pour vos répliques, et Timestream pour InfluxDB gère au moins une réplique en lecture par cluster. Les répliques de lecture acceptent activement les demandes de lecture afin de répartir votre charge de travail.

Timestream pour InfluxDB détecte et récupère automatiquement les scénarios de défaillance courants dans les déploiements de clusters Read Replica, ce qui vous permet de reprendre rapidement les opérations de base de données sans intervention administrative. Le système effectue automatiquement un basculement vers une réplique en lecture dans les cas suivants :

• Perte de disponibilité dans la zone de disponibilité du nœud primaire
• Perte de connectivité réseau avec le nœud primaire
• Défaillance de l’unité de calcul sur le nœud primaire
• Panne de stockage sur le nœud primaire

Remarque : les clusters Timestream pour InfluxDB Read Replica ne basculent pas automatiquement en réponse à des opérations de base de données, telles que des requêtes de longue durée, des blocages ou des erreurs de corruption de base de données. N’oubliez pas que le basculement automatique ne se produira que si vous avez spécifiquement activé cette fonctionnalité pour votre cluster Read Replica lors de la configuration ou lors de la modification du cluster.

Le basculement dans un cluster Read Replica est automatiquement géré par Timestream pour InfluxDB lorsque la fonctionnalité est activée, ce qui permet aux opérations de base de données de reprendre rapidement sans intervention administrative. Pendant le basculement, Timestream pour InfluxDB met à jour l’enregistrement du nom canonique (CNAME) de votre base de données pour qu’il pointe vers la réplique de lecture, qui est ensuite promue pour devenir la nouvelle instance principale. Nous vous recommandons d’implémenter une logique de nouvelle tentative de connexion à la base de données dans votre couche d’application en tant que meilleure pratique.

Étant donné que les nœuds d’un cluster Read Replica sont actifs, le temps de basculement sera stable quelles que soient les caractéristiques de la charge de travail. En général, les basculements s’effectuent en quelques minutes, entre la détection de la panne principale et la reprise des transactions sur la réplique promue. Pour des performances optimales, nous vous recommandons d’utiliser des types de nœuds de taille adéquate et le stockage inclus Timestream pour InfluxDB IOPS.

Lorsque le basculement est activé, Timestream pour InfluxDB gère automatiquement le basculement dans diverses conditions de défaillance. Actuellement, le lancement manuel du basculement forcé n’est pas pris en charge pour les clusters Timestream pour InfluxDB Read Replica.

Oui, votre réplique de lecture est automatiquement provisionnée dans une zone de disponibilité différente de la même région que votre nœud primaire.

Oui, vous pouvez consulter l’emplacement de votre nœud principal et de votre nœud Read Replica via la console de gestion AWS ou en utilisant l’API GetDBInstance.

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région, de sorte que l’impact de la latence doit être minime. Cependant, nous vous recommandons de concevoir l’architecture de votre application et des autres ressources AWS de manière redondante sur plusieurs zones de disponibilité pour une résilience maximale. Les clusters Read Replica prennent naturellement en charge cette architecture, car vous pouvez répartir vos charges de travail de lecture entre les nœuds de différentes zones de disponibilité, et lorsque le basculement est activé, votre application peut continuer à fonctionner même si une zone de disponibilité devient indisponible.