Partage via

Réplicas en lecture dans Azure Cosmos DB for PostgreSQL

  • Article

S’APPLIQUE À : Azure Cosmos DB for PostgreSQL (avec l’extension de base de données Citus pour PostgreSQL)

La fonctionnalité de réplica en lecture vous permet de répliquer les données d’un cluster sur un cluster en lecture seule. Les réplicas en lecture sont mis à jour de manière asynchrone avec la technologie de réplication physique de PostgreSQL. Vous pouvez exécuter jusqu’à cinq réplicas à partir du serveur principal.

Les réplicas sont de nouveaux clusters que vous gérez comme des clusters ordinaires. Pour chaque réplica en lecture, vous êtes facturé en fonction de la capacité de calcul approvisionnée dans les vCores et du stockage approvisionné en Gio/mois. Les coûts de calcul et de stockage pour les clusters réplicas sont les mêmes que pour les clusters standard.

Découvrez comment créer et gérer des réplicas.

Quand utiliser un réplica en lecture

La fonctionnalité de réplica en lecture contribue à améliorer les performances et la scalabilité des charges de travail nécessitant une lecture intensive. Les charges de travail de lecture peuvent être isolées sur les réplicas, tandis que les charges de travail d’écriture peuvent être dirigées vers le serveur principal.

Un scénario courant est d’avoir les charges de travail décisionnelles et analytiques qui utilisent le réplica en lecture comme source de données pour la création de rapports.

Dans la mesure où les réplicas sont en lecture seule, ils ne réduisent pas directement les charges relatives à la capacité d’écriture sur le serveur principal.

Considérations

Cette fonctionnalité est destinée aux scénarios où la latence est acceptable dans la réplication et vise à décharger les requêtes. Elle n’est pas destinée aux scénarios de réplication synchrone où les données des réplicas sont supposées être à jour. Il y aura un délai mesurable entre le serveur principal et le réplica. Ce délai peut être de quelques minutes, voire de quelques heures, selon la charge de travail et le temps de latence entre la source et le réplica. Les données du réplica finissent par devenir cohérentes avec les données du serveur principal. Utilisez cette fonctionnalité pour les charges de travail pouvant s’adapter à ce délai.

Créer un réplica

Quand vous démarrez le workflow de création de réplica, un cluster vide est créé. Le nouveau cluster est rempli avec les données qui se trouvaient sur le cluster principal. Le temps de création dépend de la quantité de données présentes sur le serveur principal et du temps écoulé depuis la dernière sauvegarde complète hebdomadaire. Le temps nécessaire peut aller de quelques minutes à plusieurs heures.

La fonctionnalité de réplica en lecture utilise la réplication physique PostgreSQL, et non la réplication logique. Le mode par défaut est la réplication en continu à l’aide d’emplacements de réplication. Quand cela est nécessaire, la copie des journaux de transaction permet de rattraper le retard.

Découvrez comment créer un réplica en lecture dans le portail Azure.

Se connecter à un réplica

Lorsque vous créez un réplica, il n’hérite pas des règles de pare-feu du cluster principal. Ces règles doivent être configurés indépendamment pour le réplica.

Le réplica hérite du compte Administrateur (citus) du cluster principal. Tous les comptes d’utilisateur sont répliqués sur les réplicas en lecture. Vous pouvez uniquement vous connecter à un réplica en lecture à l’aide des comptes d’utilisateur disponibles sur le serveur principal.

Vous pouvez vous connecter au nœud coordinateur du réplica à l’aide de son nom d’hôte et d’un compte d’utilisateur valide, comme vous le feriez sur un cluster ordinaire. Par exemple, pour un serveur nommé my replica, à l’aide du nom d’utilisateur administrateur citus, vous pouvez vous connecter au nœud coordinateur du réplica en utilisant psql :

psql -h c-myreplica.12345678901234.postgres.cosmos.azure.com -U citus@myreplica -d postgres

À l’invite, entrez le mot de passe du compte d’utilisateur.

Promotion d’un réplica vers un cluster indépendant

Vous pouvez promouvoir un réplica vers un cluster indépendant accessible en lecture et en écriture. Un réplica promu ne reçoit plus les mises à jour de son réplica d’origine et la promotion ne peut pas être annulée. Les réplicas promus peuvent eux-mêmes avoir des réplicas.

Il existe deux scénarios courants pour la promotion d’un réplica :

  1. Récupération d’urgence. Si un problème se produit avec le principal ou avec une région entière, vous pouvez ouvrir un autre cluster pour les écritures dans le cadre d’une procédure d’urgence.

  2. Migration vers une autre région. Si vous souhaitez passer à une autre région, créez un réplica dans la nouvelle région, attendez que les données se propagent, puis effectuez la promotion du réplica. Pour éviter le risque de perdre des données lors de la promotion, vous pouvez désactiver les écritures dans le cluster d’origine une fois le réplica à jour.

    Vous pouvez voir où en la mise à jour d’un réplica à l’aide de l’indicateur de performance replication_lag. Pour plus d’informations, consultez les indicateurs de performance.

Considérations

Cette section résume les considérations relatives à la fonctionnalité de réplica en lecture.

Nouveaux réplicas

Un réplica en lecture est créé en tant que nouveau cluster. Un cluster existant ne peut pas être transformé en réplica. Vous ne pouvez pas créer un réplica d’un autre réplica en lecture.

Configuration du réplica

Les réplicas héritent des paramètres des nœuds de calcul, de stockage et worker à partir de leurs principaux. Vous pouvez modifier certains paramètres, mais pas tous, sur un réplica. Par exemple, vous pouvez modifier le calcul, les règles de pare-feu pour l’accès public et les points de terminaison privés pour l’accès privé. Vous ne pouvez pas modifier la taille de stockage ni le nombre de nœuds Worker.

N’oubliez pas de faire en sorte que les réplicas soient suffisamment robustes pour conserver les modifications provenant du serveur principal. Par exemple, veillez à mettre à l’échelle la puissance de calcul dans les réplicas si vous la mettez à l’échelle sur le serveur principal.

Les règles de pare-feu et les paramètres de paramétrage sont hérités du serveur principal au réplica lorsque le réplica est créé ou après sa création.

Réplication entre régions

Les réplicas en lecture peuvent être créés dans la région du cluster principal ou dans toute autre région prise en charge par Azure Cosmos DB for PostgreSQL. La limite de cinq réplicas par cluster compte dans toutes les régions, ce qui signifie cinq au total, et non cinq par région.

Étapes suivantes