PostgreSQL Streaming vs réplication logique - Comparaison

La réplication des informations stockées dans votre base de données est essentielle pour distribuer les données et vous assurer de disposer d'une sauvegarde pouvant être utilisée pour la reprise après sinistre, en cas de problème.

La réplication PostgreSQL se présente sous deux formes, et les deux ont leurs utilisations de niche. Comprendre comment appliquer l'une ou l'autre de ces méthodes de réplication de données peut rationaliser vos processus de distribution de données. La dernière chose que vous souhaitez est de perdre le travail crucial que vous avez effectué sur une base de données.

Examinons les avantages, les inconvénients et les cas d'utilisation de la réplication en continu et de la logique dans PostgreSQL.

Définir la réplication de données dans PostgreSQL

Si vous savez déjà ce qu'est la réplication de données, vous pouvez continuer et faire défiler jusqu'à la section suivante. Mais si vous débutez dans l'ingénierie des bases de données, nous voulons jeter les bases très rapidement.

Comme son nom l'indique, la réplication est le processus consistant à copier fréquemment des données d'une base de données sur un serveur informatique vers une autre base de données sur un serveur différent, afin que tous les utilisateurs aient accès au même niveau d'informations. En informatique, la réplication est utilisée pour éliminer les défauts d'un système numérique.

La réplication élimine les silos de données, protège les informations précieuses et rationalise le développement.

Dans PostgreSQL, il existe deux options de réplication :la réplication logique et la réplication en continu. Ces méthodes sont idéales pour différents cas d'utilisation et, en tant que développeur, vous serez peut-être plus enclin à utiliser l'une plutôt que l'autre. Mais il est bon de comprendre comment utiliser les deux afin de pouvoir décider lequel appliquer dans différents scénarios.

Réplication logique dans PostgreSQL

La réplication en continu a été introduite pour une utilisation avec PostgreSQL v10.0. La réplication logique fonctionne en copiant/répliquant des objets de données et leurs modifications en fonction de leur identité de réplication.

Dans de nombreux cas, l'identité des données est une clé primaire. Dans PostgreSQL, il donne aux utilisateurs un contrôle précis sur les données répliquées et la sécurité des informations.

Le terme logique est utilisé pour le distinguer de la réplication physique, qui utilise une réplication octet par octet et des adresses de bloc exactes. Pour en savoir plus, consultez la documentation officielle de PostgreSQL ici.

Grâce à un modèle de publication et d'abonnement, il fonctionne en permettant à un ou plusieurs abonnés de s'abonner à une ou plusieurs publications sur un nœud d'éditeur. Les abonnés peuvent extraire des informations des publications et republier les données pour une réplication en cascade ou une configuration plus complexe.

La réplication logique des données peut également prendre la forme d'une réplication transactionnelle. Si l'ingénieur souhaite copier une table, il peut utiliser cette méthode de réplication pour prendre un instantané des données du côté de l'éditeur et l'envoyer à la base de données de l'abonné.

Au fur et à mesure que les abonnés modifient les données d'origine, la base de données de l'éditeur reçoit des mises à jour en temps réel. Pour assurer la cohérence transactionnelle des publications avec un seul abonnement, l'abonné doit appliquer les données dans le même ordre que l'éditeur.

Avantages de la réplication logique dans PostgreSQL

La réplication logique permet aux utilisateurs d'employer un serveur de destination pour les écritures et permet aux développeurs d'avoir différents index et définitions de sécurité. Cela offre une flexibilité accrue pour le transfert de données entre les éditeurs et les abonnés.

Prise en charge inter-versions

De plus, il est livré avec une prise en charge inter-versions et peut être défini entre différentes versions de PostgreSQL. Il fournit également un filtrage basé sur les événements. Les publications peuvent avoir plusieurs abonnements, ce qui facilite le partage de données sur un vaste réseau.

Charge minimale du serveur

Par rapport aux solutions basées sur des déclencheurs, il a une charge de serveur minimale tout en offrant une flexibilité de stockage grâce à la réplication d'ensembles plus petits. Comme mentionné ci-dessus, la réplication logique des données peut même copier des données contenues dans des tables partitionnées de base.

Il est également essentiel de mentionner que la réplication logique des données permet la transformation des données même lorsqu'elles sont en cours de configuration et permet le streaming parallèle entre les éditeurs.

Inconvénients de la réplication logique dans PostgreSQL

La réplication logique ne copiera pas les séquences, les objets volumineux, les vues matérialisées, les tables racine de partition et les tables étrangères.

Dans PostgreSQL, la réplication logique des données n'est prise en charge que par les opérations DML. Les développeurs ne peuvent pas utiliser DDL ou tronquer, et le schéma doit être défini au préalable. De plus, il ne prend pas en charge la réplication mutuelle (bidirectionnelle).

Si les utilisateurs rencontrent des conflits avec des contraintes sur les données répliquées dans une table, la réplication s'arrête. La seule façon pour la réplication de reprendre est si la cause du conflit est résolue.

Un conflit involontaire peut stopper l'élan de votre équipe, vous devez donc comprendre comment résoudre rapidement tout problème.

Si le conflit n'est pas résolu rapidement, le slot de réplication se figera dans son état actuel, le nœud éditeur commencera à accumuler des journaux WAL (Write-Ahead Logs) et le nœud finira par manquer d'espace disque.

Cas d'utilisation de la réplication logique dans PostgreSQL

De nombreux ingénieurs utiliseront la réplication logique pour :

• Distribution des modifications au sein d'une seule base de données ou d'un sous-ensemble de base de données aux abonnés en temps réel
• Fusionner plusieurs bases de données en une seule base de données centrale (souvent à des fins d'analyse)
• Créer des réplications sur différentes versions de PostgreSQL
• Déployer des réplications entre des instances PostgreSQL sur différentes plates-formes, telles que Linux vers Windows
• Partage de données répliquées avec d'autres utilisateurs ou groupes
• Distribuer un sous-ensemble de base de données entre plusieurs bases de données

Réplication en continu dans PostgreSQL

La réplication en continu a été introduite pour être utilisée avec PostgreSQL 9.0. Le processus envoie et applique les fichiers WAL (Write-Ahead Logging) d'un serveur de base de données principal ou principal à une réplique ou à une base de données réceptrice. Les WAL sont utilisés pour la réplication et pour assurer l'intégrité des données.

Fonctionnement de la réplication en continu

La réplication en continu fonctionne pour combler le fossé entre les transferts de données inhérents à l'envoi de journaux basé sur des fichiers, qui attend qu'un WAL atteigne sa capacité maximale pour expédier des données.

En diffusant les enregistrements WAL, les serveurs de base de données diffusent les enregistrements WAL en morceaux pour synchroniser les données. Le serveur de secours se connecte au réplica et reçoit les blocs WAL au fur et à mesure qu'ils sont envoyés.

Avec la réplication en continu, l'utilisateur doit décider s'il souhaite configurer une réplication asynchrone ou synchrone. Lorsque la réplication en continu est initialement déployée, elle sera par défaut la réplication asynchrone.

Cela indique qu'il y a un délai entre la modification initiale sur le primaire et la réflexion de cette modification sur la réplique. L'asynchronisation ouvre la porte à une perte de données potentielle si le maître tombe en panne avant que les modifications ne soient copiées ou si la réplique est tellement désynchronisée avec l'original qu'elle a déjà supprimé les données pertinentes pour apporter des modifications.

La réplication synchrone est une option beaucoup plus sûre car elle apporte des modifications en temps réel. Le transfert du maître vers la réplique est considéré comme incomplet tant que les deux serveurs n'ont pas vérifié les informations. Une fois les modifications de données confirmées, le transfert est enregistré sur les WAL des deux serveurs.

Que vous utilisiez la réplication asynchrone ou synchrone, les répliques doivent être connectées au maître via une connexion réseau. De plus, il est essentiel que les utilisateurs configurent des privilèges d'accès pour les flux WAL de la réplique, afin que les informations ne soient pas compromises.

Avantages de la réplication en continu dans PostgreSQL

L'un des avantages les plus importants de l'utilisation de la réplication en continu est que la seule façon de perdre des données est si les serveurs principal et récepteur tombent en panne en même temps. Si vous transmettez des informations importantes, la réplication en continu garantit pratiquement qu'une copie de votre travail sera enregistrée.

Les utilisateurs peuvent connecter plus d'un serveur de secours au serveur principal, et les journaux seront transmis du serveur principal à chacun des serveurs de secours connectés. Si l'une des répliques est retardée ou se déconnecte, la diffusion se poursuivra vers les autres répliques.

La configuration de l'envoi de journaux via la réplication en continu n'interfère pas avec tout ce que l'utilisateur exécute actuellement sur la base de données principale. Si le serveur de données principal doit être arrêté, il attendra que les enregistrements mis à jour aient été envoyés à la réplique avant de s'éteindre.

Inconvénients de la réplication en continu dans PostgreSQL

La réplication en continu ne copie pas les informations dans une version ou une architecture différente, ne modifie pas les informations des serveurs de secours et n'offre pas de réplication granulaire.

En particulier avec la réplication asynchrone des données en continu, les anciens fichiers WAL qui ne sont pas encore copiés sur la réplique peuvent être recyclés lorsque l'utilisateur apporte des modifications au maître. Pour s'assurer que les fichiers vitaux ne sont pas perdus, l'utilisateur peut définir wal_keep_segments sur une valeur plus élevée.

Sans informations d'identification d'authentification utilisateur configurées pour les serveurs de réplique, il peut être facile d'extraire des données sensibles. Pour que les mises à jour en temps réel se produisent entre le maître et la réplique, l'utilisateur doit changer la méthode de réplication de la réplication asynchrone par défaut à la réplication synchrone.

Cas d'utilisation pour la réplication en continu dans PostgreSQL

De nombreux ingénieurs utiliseront la réplication en continu pour :

• Créer une sauvegarde pour leur base de données principale en cas de panne de serveur ou de perte de données
• Favoriser une solution à haute disponibilité avec le moins de retard de réplication possible
• Éliminer les requêtes volumineuses pour soulager une partie du stress sur le système principal
• Répartition des charges de travail de la base de données sur plusieurs machines, en particulier pour les formats en lecture seule

Que nous réserve l'avenir ?

Le PostgreSQL Global Development Group a annoncé la sortie de PostgreSQL 14 le 30 septembre 2021. La nouvelle version est livrée avec des mises à niveau en streaming et en réplications logiques via la plate-forme.

Pour la réplication en streaming, la version 14 permet aux utilisateurs de :

• Définissez le paramètre de serveur log_recovery_conflict_waits pour signaler automatiquement les longs temps d'attente des conflits de récupération
• Suspendre la récupération sur un serveur de secours lors de la modification des paramètres sur un serveur principal (au lieu d'arrêter immédiatement le serveur de secours)
• Utiliser la fonction pg_get_wal_replay_pause_state() pour signaler l'état de la récupération plus en détail
• Fournir un paramètre de serveur en lecture seule in_hot_standby
• Tronquez rapidement les petites tables lors de la récupération sur les clusters qui ont un grand nombre de tampons partagés
• Autoriser la synchronisation du système de fichiers au début de la reprise sur incident via Linux
• Utiliser la fonction pg_xact_commit_timestamp_origin() sur une transaction spécifiée pour renvoyer l'horodatage de validation et l'origine de la réplication
• Utiliser la fonction pg_last_committed_xact() pour ajouter l'origine de réplication sur l'enregistrement renvoyé
• Utilisez des contrôles d'autorisation de fonction standard pour modifier les fonctions d'origine de la réplication (la valeur par défaut limite toujours l'accès aux superutilisateurs)

Pour la réplication logique, la version 14 permet aux utilisateurs de :

• Diffuser les longues transactions en cours aux abonnés avec l'API de réplication logique
• Autoriser plusieurs transactions lors des réplications de table
• Générer des sous-transactions WAL-log immédiates et des associations XID de haut niveau
• Utiliser la fonction pg_create_logical_replication_slot() pour améliorer les API de décodage logique pour les commits en deux phases
• Ajouter des messages d'invalidation du cache au WAL lors de l'exécution de la commande pour permettre le streaming logique des transactions en cours
• Contrôler les messages de décodage logique qui sont envoyés au flux de réplication
• Utiliser le mode de transfert binaire pour des réplications plus rapides
• Filtrer le décodage par XID

PostgreSQL travaille déjà sur la version 15, qui devrait être publiée au troisième trimestre 2022. L'un des problèmes de réplication à résoudre dans la dernière version consiste à empêcher l'utilisation de variables héritées de l'environnement du serveur dans la réplication en continu. Mais à mesure que de plus en plus d'utilisateurs s'adapteront à la version 14, PostgreSQL ajoutera probablement plus de tâches pour améliorer les fonctions de réplication.

Comparaison rapide de la réplication PostgreSQL :réplication logique et réplication en continu

Conclusion

Nous espérons que ce guide vous sera utile lors de la configuration de vos fonctions de réplication. Si vous avez des questions ou si vous souhaitez savoir comment ScaleGrid peut vous aider dans vos déploiements PostgreSQL, contactez l'un de nos nombreux experts en bases de données.