Comment répliquer des données PostgreSQL sur des sites distants

Dans un environnement de base de données chargé avec des bases de données de plus grande taille, le besoin de réplication de données en temps réel est un phénomène courant. Les applications ont souvent besoin que les données de production soient répliquées en temps réel sur des sites distants à des fins d'analyse et d'autres besoins critiques en matière d'opérations commerciales.

Les administrateurs de base de données doivent également s'assurer que les données sont répliquées en continu sur les sites distants pour répondre à diverses exigences. Ces exigences, cependant, ne consistent pas toujours à répliquer l'intégralité de la base de données; il peut également être nécessaire de ne répliquer qu'un sous-ensemble de données (comme une table ou un ensemble de tables ou des données de plusieurs tables à l'aide d'un SQL pour l'analyse, la création de rapports, etc.)

Dans ce blog, nous nous concentrerons sur la façon de répliquer des tables vers des bases de données distantes en temps réel.

Qu'est-ce que la réplication au niveau de la table ?

La réplication au niveau de la table est le mécanisme de réplication des données d'une table ou d'un ensemble de tables spécifique d'une base de données (source) vers une autre base de données (cible) hébergée à distance dans un environnement distribué. La réplication au niveau des tables garantit que les données des tables sont distribuées en continu et restent cohérentes sur les sites répliqués (cibles).

Pourquoi utiliser la réplication au niveau de la table ?

La réplication au niveau des tables est un besoin essentiel dans les environnements plus vastes, complexes et hautement distribués. D'après mon expérience, il a toujours été nécessaire de répliquer un ensemble de tables d'une base de données de production vers un entrepôt de données à des fins de reporting. Les données doivent être répliquées en permanence pour s'assurer que les rapports reçoivent les données les plus récentes. Dans les environnements critiques, l'obsolescence des données ne peut être tolérée. Par conséquent, les modifications de données qui se produisent en production doivent être immédiatement répliquées sur le site cible. Cela peut être un véritable défi pour les administrateurs de base de données qui doivent prévoir divers facteurs pour assurer une réplication de table efficace et fluide.

Examinons quelques exigences que la réplication au niveau de la table résout :

• Les rapports peuvent être exécutés sur une base de données dans un environnement autre que la production, comme un entrepôt de données
• Un environnement de base de données distribué avec des applications distribuées extrayant des données de plusieurs sites. Dans le cas d'applications Web ou mobiles distribuées, la copie des mêmes données doit être disponible à plusieurs endroits pour répondre à divers besoins d'application pour lesquels la réplication au niveau de la table pourrait être une bonne solution
• Les applications de paie nécessitant que les données de diverses bases de données situées dans différents centres de données géographiquement répartis ou instances cloud soient disponibles dans une base de données centralisée

Divers facteurs ayant une incidence sur la réplication au niveau de la table :éléments à rechercher

Comme nous l'avons mentionné ci-dessus, les administrateurs de base de données doivent prendre en considération une variété de composants et de facteurs en temps réel pour concevoir et mettre en œuvre un système de réplication efficace au niveau des tables.

Structure des tableaux

Le type de table de données adapté a un impact important sur les performances de réplication. Si la table contient une colonne BYTEA avec des données binaires de plus grande taille, les performances de réplication peuvent être affectées. L'impact de la réplication sur le réseau, le processeur et le disque doit être évalué avec soin.

Taille des données

Si la table à migrer est trop volumineuse, la migration initiale des données prendrait des ressources et du temps, les DBA doivent s'assurer que la base de données de production n'est pas impactée.

Ressources d'infrastructure

L'infrastructure doit disposer de ressources adéquates pour garantir la création d'un système de réplication performant, fiable et stable. Quels composants d'infrastructure doivent être pris en compte ?

CPU

La réplication des données dépend fortement des processeurs. Lors de la réplication à partir de la production, les processeurs ne doivent pas être épuisés, ce qui peut avoir un impact sur les performances de production.

Réseau

Il est essentiel pour les performances de réplication. La latence du réseau entre les bases de données source et cible doit être évaluée par des tests de résistance pour s'assurer qu'il y a suffisamment de bande passante pour que la réplication soit plus rapide. En outre, le même réseau peut être utilisé par d'autres processus ou applications. Donc, la planification des capacités doit être faite ici.

Mémoire

Il doit y avoir suffisamment de mémoire disponible pour garantir que suffisamment de données sont mises en cache pour une réplication plus rapide.

Mises à jour de la table source

Si les modifications de données sur la table source sont importantes, le système de réplication doit avoir la capacité de synchroniser les modifications sur le(s) site(s) distant(s) dès que possible. La réplication finira par envoyer un nombre élevé de requêtes de synchronisation à la base de données cible, ce qui peut nécessiter beaucoup de ressources.

Le type d'infrastructure (centres de données ou cloud) peut également avoir un impact sur les performances de réplication et peut poser des problèmes. La mise en œuvre de la surveillance pourrait également être un défi. S'il y a un décalage et que certaines données manquent sur la base de données cible, cela pourrait être difficile à surveiller et cela ne peut pas être synchrone

Comment mettre en œuvre la réplication de table

La réplication au niveau des tables dans PostgreSQL peut être implémentée à l'aide d'une variété d'outils externes (commerciaux ou open source) disponibles sur le marché ou en utilisant des flux de données personnalisés.

Jetons un coup d'œil à certains de ces outils, leurs caractéristiques et leurs capacités...

Slony

Slony est l'un des outils les plus populaires utilisés pour répliquer de manière asynchrone une ou plusieurs tables individuelles spécifiques en temps réel d'une base de données PostgreSQL à une autre. Il s'agit d'un outil basé sur Perl qui effectue une réplication basée sur des déclencheurs des modifications de données d'une table (ou d'un ensemble de tables) d'une base de données d'un site à un autre. Il est assez fiable et il a des années d'histoire de développement. Bien que très fiable, étant un outil basé sur des déclencheurs, il peut devenir complexe de gérer les configurations de réplication.

Voyons quelques fonctionnalités de Slony...

Avantages d'utiliser Slony

• Prend en charge la méthodologie de réplication maître vers esclave ou plusieurs esclaves, ce qui contribue à améliorer l'évolutivité horizontale de la lecture. En d'autres termes, les esclaves ne sont pas accessibles en écriture
• La configuration de plusieurs esclaves sur un seul maître est possible et prend également en charge la méthodologie de réplication en cascade
• Prend en charge les mécanismes de basculement et de basculement
• Un grand nombre de tables peuvent être répliquées en groupes, en parallèle
• Nous pouvons répliquer entre différentes versions majeures d'instances PostgreSQL, ce qui fait de Slony une excellente option pour les mises à niveau de bases de données
• Simple à installer

Inconvénients de l'utilisation de Slony

• Ne prend pas en charge la réplication DDL
• Certaines modifications de schéma peuvent interrompre la réplication
• Les événements de réplication sont enregistrés dans la base de données dans des tables de journal spécifiques à Slony, ce qui peut entraîner une surcharge de maintenance.
• Si un grand nombre de tables contenant de grands ensembles de données doivent être répliquées, les performances et la maintenance peuvent poser de sérieux problèmes
• Étant une réplication basée sur des déclencheurs, les performances peuvent être affectées

Bucardo

Bucardo est un autre système de réplication open source basé sur perl pour PostgreSQL qui prend en charge la réplication asynchrone de données de table spécifiques entre deux ou plusieurs instances PostgreSQL. Ce qui différencie Bucardo de Slony, c'est qu'il prend également en charge la réplication multi-maîtres.

Examinons différents types de mécanismes de réplication que bucardo aide à mettre en œuvre...

• Réplication multi-maître :les tables peuvent être répliquées dans les deux sens entre deux instances PostgreSQL ou plus et les données transactionnelles seront synchronisées de manière bidirectionnelle
• Maître-esclave :les données des tables dans le maître seront répliquées sur l'esclave de manière asynchrone et l'esclave est disponible pour les opérations de lecture
• Mode copie complète (maître-esclave) :Bucardo -/répliquer l'intégralité des données du nœud maître vers le nœud esclave en supprimant toutes les données de l'esclave

Avantages de l'utilisation de Bucardo

• Simple à installer
• Prend en charge les modes de réplication multi-maître, maître-esclave et copie intégrale
• Il peut être utilisé pour mettre à niveau les bases de données
• La réplication peut être effectuée entre différentes versions de PostgreSQL

Inconvénients de l'utilisation de Bucardo

• Étant une réplication basée sur des déclencheurs, les performances peuvent être un défi
• Les changements de schéma comme les DDL peuvent interrompre la réplication
• La réplication d'un grand nombre de tables peut entraîner des frais de maintenance
• Les ressources de l'infrastructure doivent être optimisées pour une réplication performante, sinon la cohérence ne peut pas être atteinte.

Réplication logique PostgreSQL

La réplication logique est une fonctionnalité intégrée révolutionnaire de PostgreSQL qui permet de répliquer des tables individuelles via des enregistrements WAL. Étant une réplication basée sur WAL (similaire à la réplication en continu), pg logical se démarque par rapport aux autres outils de réplication de table. La réplication de données via des enregistrements WAL est toujours le moyen le plus fiable et le plus performant de répliquer des données sur le réseau. Presque tous les outils du marché proposent une réplication basée sur des déclencheurs, à l'exception de la réplication logique.

Avantages de l'utilisation de la réplication logique PostgreSQL

• La meilleure option lorsque vous souhaitez répliquer une seule table ou un ensemble de tables
• C'est une bonne option si l'exigence est de migrer des tables spécifiques de différentes bases de données vers une seule base de données (comme l'entreposage de données ou les bases de données de rapports) à des fins de création de rapports ou d'analyse
• Aucun problème de déclencheurs

Inconvénients de l'utilisation de la réplication logique PostgreSQL

• Une mauvaise gestion des fichiers WAL/fichiers d'archive WAL peut poser des problèmes à la réplication logique
• Nous ne pouvons pas répliquer les tables sans clés primaires ou uniques
• Les DDL et TRUNCATE ne sont pas répliqués
• Le délai de réplication peut augmenter si les WAL sont supprimés. Cela signifie que la réplication et la gestion des WAL doivent se compléter pour s'assurer que la réplication ne s'interrompt pas
• Les objets volumineux ne peuvent pas être répliqués

Voici quelques ressources supplémentaires pour vous aider à mieux comprendre la réplication logique PostgreSQL et les différences entre celle-ci et la réplication en continu.

Encapsuleurs de données étrangers

Bien que les wrappers de données étrangères ne répliquent pas réellement les données, je voulais souligner cette fonctionnalité de PostgreSQL car elle peut aider les DBA à réaliser quelque chose de similaire à la réplication sans réellement répliquer les données. Cela signifie que les données ne sont pas répliquées de la source vers la cible et qu'elles sont accessibles aux applications à partir de la base de données cible. La base de données cible n'a qu'une structure de table avec un lien contenant les détails de l'hôte et de la base de données de la table source et lorsque l'application interroge la table cible, les données sont extraites de la base de données source vers la base de données cible similaire aux liens de base de données. Si les FDW peuvent vous aider, vous pouvez alors totalement éviter les frais généraux liés à la réplication des données sur le réseau. Souvent, nous nous retrouvons dans une situation où les rapports peuvent être exécutés sur une base de données cible distante sans que les données soient physiquement présentes.

Les FDW sont une excellente option dans les situations suivantes -

• Si vous avez de petites tables statiques dans la base de données source, il n'est pas vraiment utile de répliquer les données
• Peut être très utile si vous avez de très grandes tables dans la base de données source et que vous exécutez des requêtes agrégées sur la base de données cible.

Avantages de l'utilisation d'encapsuleurs de données étrangers

• La réplication des données peut être complètement évitée, ce qui peut économiser du temps et des ressources
• Simple à mettre en œuvre
• Les données extraites sont toujours les plus récentes
• Pas de maintenance en tête

Inconvénients de l'utilisation de wrappers de données étrangers

• Les modifications structurelles apportées à la table source peuvent avoir un impact sur les fonctionnalités de l'application sur la base de données cible
• Dépend fortement du réseau et peut avoir une surcharge importante du réseau en fonction du type de rapports exécutés
• Une surcharge de performances est attendue lorsque les requêtes sont exécutées plusieurs fois, car chaque fois qu'une requête est exécutée, les données doivent être extraites sur le réseau à partir de la base de données source et peuvent également entraîner une surcharge de performances sur la base de données source
• Toute charge sur la source peut avoir un impact sur les performances des applications sur la base de données cible

Conclusion

• La réplication de tables peut servir à diverses fins critiques pour l'entreprise
• Peut prendre en charge les requêtes parallèles distribuées dans les environnements distribués
• La mise en œuvre de la synchronisation synchrone est presque impossible
• L'infrastructure doit être suffisamment équipée, ce qui implique des coûts
• Une excellente option pour créer une base de données centralisée intégrée à des fins de création de rapports et d'analyse