Différence entre la réplication de flux et la réplication logique
Quelqu'un pourrait-il m'en dire plus sur la différence entre la réplication physique et la réplication logique dans PostgreSQL?
TL; DR : la réplication logique envoie des modifications ligne par ligne, la réplication physique envoie des modifications de bloc de disque. La réplication logique est meilleure pour certaines tâches, la réplication physique pour d'autres.
À partir de la 9.5, la réplication logique est assez immature. Utilisez la réplication physique si vous posez cette question.
La réplication en streaming peut être une réplication logique. C'est un peu compliqué.
Expédition WAL vs streaming
Il existe deux façons principales d'envoyer des données du maître vers la réplique dans PostgreSQL:
WAL-shipping ou archivage continu , où un journal individuel d'écriture anticipée les fichiers sont copiés à partir de
pg_xlogpar learchive_commanden cours d'exécution sur le maître vers un autre emplacement. UNErestore_commandconfiguré dans la répliquerecovery.confs'exécute sur la réplique pour récupérer les archives afin que la réplique puisse rejouer le WAL.C'est ce qui est utilisé pour la réplication ponctuelle (PITR), qui est utilisée comme méthode de sauvegarde continue.
Aucune connexion réseau directe n'est requise au serveur maître. La réplication peut avoir de longs délais, en particulier sans
archive_timeoutensemble. L'expédition WAL ne peut pas être utilisée pour la réplication synchrone.réplication en continu , où chaque modification est envoyée à un ou plusieurs serveurs de réplique directement via une connexion TCP/IP au fur et à mesure. Les répliques doivent avoir une connexion réseau directe configurée par le maître dans leur
recovery.conf'sprimary_conninfooption.La réplication en streaming a peu ou pas de retard tant que la réplique est suffisamment rapide pour suivre. Il peut être utilisé pour la réplication synchrone . Vous ne pouvez pas utiliser la réplication en streaming pour PITR1 il n'est donc pas très utile pour la sauvegarde continue. Si vous déposez une table sur le maître, oups, elle est également supprimée sur les répliques.
Ainsi, les deux méthodes ont des objectifs différents.
Streaming asynchrone vs synchrone
En plus de cela, il y a réplication synchrone et asynchrone :
Dans la réplication de streaming asynchrone , les répliques sont autorisées à se placer derrière le maître à temps lorsque le maître est plus rapide/plus occupé. Si le maître tombe en panne, vous risquez de perdre des données qui n'ont pas encore été répliquées.
Si la réplique asynchrone se trouve trop loin derrière le maître, le maître peut jeter les informations dont la réplique a besoin si
wal_keep_segmentsest trop bas et aucun emplacement n'est utilisé, ce qui signifie que vous devez recréer la réplique à partir de zéro. Ou le maîtrepg_xlogpeut se remplir et empêcher le maître de fonctionner jusqu'à ce que l'espace disque soit libéré siwal_keep_segmentsest trop haut ou un emplacement est utilisé.Dans réplication synchrone le maître ne termine pas la validation tant qu'une réplique n'a pas confirmé avoir reçu la transaction2. Vous ne perdez jamais de données si le maître tombe en panne et vous devez basculer vers une réplique. Le maître ne jettera jamais les données dont la réplique a besoin ou ne remplira pas son xlog et manquera d'espace disque en raison des retards de réplique. En échange, cela peut ralentir ou même arrêter de fonctionner le maître si les répliques ont des problèmes, et cela a toujours un impact sur les performances du maître en raison de la latence du réseau.
Lorsqu'il existe plusieurs répliques, une seule est synchrone à la fois. Voir
synchronous_standby_names.
Vous ne pouvez pas avoir l'envoi de journaux synchrone.
Vous pouvez réellement combiner l'envoi de journaux et la réplication asynchrone pour éviter d'avoir à recréer une réplique si elle est trop en retard, sans risquer d'affecter le maître. Il s'agit d'une configuration idéale pour de nombreux déploiements, combinée à la surveillance de la distance de la réplique derrière le maître pour s'assurer qu'elle se situe dans les limites acceptables de reprise après sinistre.
Logique vs physique
En plus de que nous avons logique vs réplication physique en streaming, comme introduit dans PostgreSQL 9.4:
Dans la réplication de streaming physique les modifications sont envoyées au niveau du bloc de disque presque, comme "au décalage 14 de la page 18 du disque de la relation 12311, a écrit Tuple avec la valeur hexadécimale 0x2342beef1222 .... ".
La réplication physique envoie tout : le contenu de chaque base de données dans l'installation PostgreSQL, toutes les tables de chaque base de données. Il envoie des entrées d'index, il envoie toutes les nouvelles données de la table lorsque vous
VACUUM FULL, il envoie des données pour les transactions annulées, etc. Il génère donc beaucoup de "bruit" et envoie beaucoup de données en excès. Cela nécessite également que la réplique soit complètement identique, vous ne pouvez donc rien faire qui nécessiterait une transaction, comme la création de tables temporaires ou non enregistrées. L'interrogation de la réplique retarde la réplication, de sorte que les longues requêtes sur la réplique doivent être annulées.En échange, il est simple et efficace d'appliquer les modifications sur la réplique, et la réplique est exactement la même que celle du maître. DDL est répliqué de manière transparente, comme tout le reste, il ne nécessite donc aucune manipulation particulière. Il peut également diffuser de grosses transactions au fur et à mesure qu'elles se produisent, il y a donc peu de délai entre la validation sur le maître et la validation sur la réplique, même pour les modifications importantes.
La réplication physique est mature, bien testée et largement adoptée.
la réplication de streaming logique , nouvelle en 9.4, envoie des modifications à un niveau supérieur et bien plus sélectivement.
Il réplique une seule base de données à la fois. Il n'envoie que des modifications de ligne et uniquement pour les transactions validées, et il n'a pas à envoyer de données de vide, de modifications d'index, etc. Cela rend la réplication logique beaucoup plus efficace en termes de bande passante.
Un fonctionnement à un niveau supérieur signifie également que vous pouvez effectuer des transactions sur les bases de données de réplicas. Vous pouvez créer des tables temporaires et non enregistrées. Même des tables normales, si vous le souhaitez. Vous pouvez utiliser des wrappers de données étrangers, des vues, créer des fonctions, tout ce que vous voulez. Il n'est pas non plus nécessaire d'annuler les requêtes si elles sont trop longues.
La réplication logique peut également être utilisée pour créer une réplication multimaître dans PostgreSQL, ce qui n'est pas possible avec la réplication physique.
En échange, cependant, il ne peut pas (actuellement) diffuser de grandes transactions lorsqu'elles se produisent. Il faut attendre qu'ils s'engagent. Il peut donc y avoir un long délai entre une grosse transaction validée sur le maître et appliquée à la réplique.
Il relit les transactions strictement dans l'ordre de validation, de sorte que les petites transactions rapides peuvent rester bloquées derrière une grosse transaction et être retardées un certain temps.
DDL n'est pas géré automatiquement. Vous devez garder les définitions de table synchronisées entre le maître et le réplica vous-même, ou l'application utilisant la réplication logique doit avoir ses propres fonctionnalités pour ce faire. Il peut être compliqué de bien faire les choses.
Le processus d'application lui-même est plus compliqué que "écrire certains octets où on me le dit" également. Il prend également plus de ressources sur la réplique que la réplication physique.
Les implémentations de réplication logique actuelles ne sont pas matures ou largement adoptées, ni particulièrement faciles à utiliser.
Trop d'options, dites-moi quoi faire
Phew. Compliqué, hein? Et je ne suis même pas entré dans les détails de la réplication retardée, des emplacements, wal_keep_segments, chronologie, fonctionnement de la promotion, Postgres-XL, BDR et multimaster, etc.
Alors, que devez-vous faire ?
Il n'y a pas de bonne réponse unique. Sinon, PostgreSQL ne prendrait en charge que dans un sens. Mais il existe quelques cas d'utilisation courants:
Pour la sauvegarde et la reprise après sinistre , utilisez pgbarman pour effectuer des sauvegardes de base et conserver WAL pour vous, ce qui permet de gérer facilement la sauvegarde continue. Vous devez toujours prendre des pg_dump sauvegardes comme assurance supplémentaire.
Pour haute disponibilité sans risque de perte de données , utilisez la réplication synchrone en streaming.
Pour une haute disponibilité avec un faible risque de perte de données et de meilleures performances , vous devez utiliser la réplication de streaming asynchrone. L'archivage WAL est activé pour le repli ou utilise un emplacement de réplication. Surveillez la distance entre la réplique et le maître à l'aide d'outils externes comme Icinga.