Présentation de la réplication

La fonctionnalité de réplication de Cloud Bigtable vous permet de copier vos données dans plusieurs régions ou plusieurs zones d'une même région afin d'augmenter leur disponibilité et leur durabilité. Vous pouvez également isoler des charges de travail en redirigeant différents types de requêtes vers plusieurs clusters.

Cette page explique le fonctionnement de la réplication dans Cloud Bigtable et décrit certains cas d'utilisation courants. Elle présente également le modèle de cohérence utilisé par Cloud Bigtable lorsque vous activez la réplication et décrit ce qui se passe lors du basculement d'un cluster vers un autre.

  • Pour découvrir des exemples de paramètres à utiliser pour mettre en œuvre des cas d'utilisation courants, consultez la section Exemples de paramètres de réplication.
  • Pour apprendre à créer une instance qui utilise la réplication, consultez la page Créer une instance.
  • Pour savoir comment activer la réplication pour une instance existante, consultez la page Ajouter un cluster.
  • Pour comprendre les coûts associés à la réplication, consultez la page Tarification.

Avant de lire cette page, vous devez avoir lu la présentation de Cloud Bigtable.

Fonctionnement de la réplication

Pour utiliser la fonctionnalité de réplication dans une instance Cloud Bigtable, créez une instance avec plusieurs clusters ou ajoutez des clusters à une instance existante.

Cloud Bigtable accepte jusqu'à quatre clusters répliqués, situés dans les zones Google Cloud où Cloud Bigtable est disponible. Les clusters d'une instance doivent se situer dans des zones uniques. Vous pouvez créer un cluster supplémentaire dans toute zone où Cloud Bigtable est disponible. Le fait de placer des clusters dans différentes zones ou régions vous permet d'accéder à vos données même si une zone ou une région Google Cloud devient indisponible.

Lorsque vous créez une instance avec plusieurs clusters, Cloud Bigtable commence immédiatement à synchroniser vos données entre les clusters, en créant une copie distincte et indépendante de vos données dans chaque zone où votre instance comporte un cluster. De même, lorsque vous ajoutez un nouveau cluster à une instance existante, Cloud Bigtable copie vos données existantes de la zone du cluster d'origine vers la zone du nouveau cluster, puis synchronise les modifications apportées aux données entre les zones.

Cloud Bigtable réplique automatiquement toutes les modifications apportées aux données, y compris les suivantes :

  • Mises à jour des données dans les tables existantes
  • Création ou suppression de tables
  • Ajout ou suppression de familles de colonnes
  • Modifications apportées au règlement concernant la récupération de mémoire d'une famille de colonnes

Cloud Bigtable considère chaque cluster de votre instance comme un cluster principal. Vous pouvez donc effectuer des opérations de lecture et d'écriture dans chaque cluster. Vous pouvez également configurer votre instance pour rediriger les requêtes de plusieurs types d'applications vers différents clusters.

Avant d'ajouter des clusters à une instance, vous devez prendre en compte les restrictions qui s'appliquent lorsque vous modifiez les stratégies de récupération de mémoire des tables répliquées.

Cas d'utilisation

Cette section décrit quelques cas d'utilisation courants de la réplication Cloud Bigtable. Pour découvrir les meilleurs paramètres de configuration pour chaque cas d'utilisation et consulter des conseils sur la mise en œuvre d'autres cas, consultez les Exemples de paramètres de réplication.

Isoler les applications actives des lectures par lot

Lorsque vous utilisez un seul cluster pour exécuter une tâche d'analyse par lot effectuant de nombreuses lectures volumineuses aux côtés d'une application réalisant une combinaison d'opérations de lecture et d'écriture, cela peut ralentir l'exécution de cette dernière. Avec la réplication, vous pouvez utiliser des profils d'application avec un routage à un seul cluster pour acheminer vers des clusters différents le trafic des applications et les tâches d'analyse par lot, afin que ces dernières ne nuisent pas à l'exécution de vos applications. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Améliorer la disponibilité

Si vous ne disposez que d'un seul cluster dans une instance, la durabilité et la disponibilité de vos données sont limitées à la zone dans laquelle se trouve le cluster. La réplication peut améliorer la durabilité et la disponibilité en stockant des copies séparées de vos données dans plusieurs zones ou régions et en opérant un basculement automatique entre les clusters si nécessaire. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Fournir une sauvegarde en quasi-temps réel

Dans certains cas, vous devrez toujours rediriger les requêtes vers un seul cluster (par exemple, si vous devez à tout prix éviter la lecture de données obsolètes). Cependant, vous pouvez tout de même utiliser la réplication pour traiter les requêtes avec un seul cluster et en utiliser un autre pour effectuer une sauvegarde en quasi-temps réel. Si le cluster actif devient indisponible, vous pouvez basculer manuellement vers le cluster de sauvegarde pour réduire le temps d'arrêt. En savoir plus sur la mise en œuvre de ce cas d'utilisation

Assurez-vous que vos données ont une présence mondiale

Vous pouvez configurer une réplication dans des emplacements situés à travers le monde pour rapprocher vos données de vos clients. Par exemple, vous pouvez créer une instance avec des clusters répliqués aux États-Unis, en Europe et en Asie, puis configurer des profils d'application pour acheminer le trafic des applications vers le cluster le plus proche. En savoir plus sur la mise en œuvre de ce cas d'utilisation.

Modèle de cohérence

Par défaut, la réplication de Cloud Bigtable est cohérente à terme. Ce terme signifie que lorsque vous écrivez une modification dans un cluster, vous pouvez éventuellement lire cette modification à partir des autres clusters de l'instance, mais uniquement après que la modification a été répliquée entre les clusters.

Si votre instance est réactive, le délai de réplication est généralement de quelques secondes ou de quelques minutes, et non de plusieurs heures. Toutefois, si vous écrivez une grande quantité de données sur un cluster, ou si un cluster est surchargé ou temporairement indisponible, la réplication peut prendre un certain temps. En outre, la réplication peut prendre plus de temps si vos clusters sont éloignés les uns des autres. Par conséquent, il n'est pas prudent de supposer que vous lisez toujours la dernière valeur écrite, ou que quelques secondes suffisent après une écriture pour que Cloud Bigtable réplique la modification.

Si vous devez garantir une cohérence différente, Cloud Bigtable peut également fournir une cohérence écriture-lecture lorsque la réplication est activée, pour vous assurer qu'une application ne lira jamais des données plus anciennes que ses écritures les plus récentes. Pour assurer la cohérence écriture-lecture sur un groupe d'applications, chaque application doit utiliser un profil d'application configuré pour le routage vers un cluster unique. Tous les profils d'application doivent rediriger les requêtes vers le même cluster. Vous pouvez utiliser les clusters supplémentaires de l'instance simultanément à d'autres fins.

Pour certains cas d'utilisation de réplication, Cloud Bigtable peut également fournir une cohérence forte, ce qui garantit que toutes vos applications voient vos données dans le même état. Pour obtenir une cohérence forte, servez-vous de la configuration de profil d'application de routage à cluster unique pour la cohérence écriture-lecture décrite ci-dessus, mais n'utilisez pas les clusters supplémentaires de l'instance, sauf si vous devez basculer vers un autre cluster. Consultez les exemples de paramètres de réplication pour voir si cela est possible pour votre cas d'utilisation.

Profils d'application

Si une instance utilise la réplication, vous devez configurer des profils d'application pour contrôler les clusters qui gèrent les requêtes entrantes de vos applications. Les profils d'application déterminent également si vous pouvez effectuer des transactions à ligne unique, y compris des opérations lecture-modification-écriture (par exemple, incréments et ajouts), et des opérations de vérification et de mutation (également appelées mutations ou écritures conditionnelles).

Pour en savoir plus, consultez la page Profils d'application. Pour découvrir des exemples de paramètres à utiliser pour mettre en œuvre des cas d'utilisation courants, consultez la section Exemples de paramètres de réplication.

Basculements

Lorsqu'un cluster Cloud Bigtable ne répond plus, la réplication permet au trafic entrant de basculer vers un autre cluster de la même instance. Le basculement peut s'effectuer manuellement ou automatiquement, en fonction du profil d'application utilisé et de sa configuration.

Pour en savoir plus, consultez la section Basculements.

Supprimer des plages de lignes lorsque la réplication est activée

L'API Cloud Bigtable Admin vous permet de supprimer une plage contiguë de lignes d'une table en fonction de leurs clés de ligne. Si les instances n'utilisent pas la réplication, Cloud Bigtable peut supprimer rapidement et efficacement une plage de lignes. Cependant, lorsque vous activez la réplication, la suppression d'une plage de lignes est nettement plus lente et beaucoup moins efficace.

Étapes suivantes