PostgreSQL
 sql >> Base de données >  >> RDS >> PostgreSQL

Différence entre la réplication de flux et la réplication logique

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.

Notez que dans PostgreSQL 12 (actuel au moment de la mise à jour), la réplication logique est stable et fiable, mais assez limitée. Utilisez la réplication physique si vous vous posez cette question.

La réplication en continu peut être réplication logique. Tout est un peu compliqué.

Expédition WAL vs streaming

Il existe deux manières principales d'envoyer des données du maître au réplica dans PostgreSQL :

  • Expédition WAL ou archivage continu , où les fichiers journaux individuels à écriture anticipée sont copiés à partir de pg_xlog par la archive_command s'exécutant sur le maître vers un autre emplacement. Une restore_command configuré dans le recovery.conf du réplica s'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é comme méthode de sauvegarde continue.

    Aucune connexion réseau directe n'est nécessaire au serveur maître. La réplication peut avoir de longs délais, en particulier sans archive_timeout Positionner. 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 répliques directement via une connexion TCP/IP au fur et à mesure. Les répliques doivent avoir une connexion réseau directe que le maître a configurée dans leur recovery.conf 's primary_conninfo option.

    La réplication en continu a peu ou pas de retard tant que la réplique est suffisamment rapide pour suivre le rythme. Il peut être utilisé pour la réplication synchrone . Vous ne pouvez pas utiliser la réplication en continu pour PITR, ce 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 déposé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 synchrone et asynchrone réplication en continu :

  • Dans la réplication de flux asynchrone la ou les répliques sont autorisées à prendre du retard sur 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 le réplica asynchrone se situe trop loin derrière le maître, le maître peut jeter des informations dont le réplica a besoin si max_wal_size (s'appelait auparavant wal_keep_segments) is too low and no slot is used, meaning you have to re-create the replica from scratch. Or the master's pg_wal(was pg_xlog) peut se remplir et empêcher le maître de fonctionner jusqu'à ce que l'espace disque soit libéré si max_wal_size est trop élevé ou un emplacement est utilisé.

  • En réplication synchrone le maître ne termine pas la validation tant qu'un réplica n'a pas confirmé qu'il a reçu la transaction. Vous ne perdez jamais de données si le maître tombe en panne et que vous devez basculer vers une réplique. Le maître ne jettera jamais les données dont la réplique a besoin ou remplira son xlog et manquera d'espace disque en raison des retards de la réplique. En échange, cela peut ralentir ou même arrêter le travail du 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 d'envoi de journaux synchrone.

Vous pouvez en fait combiner l'envoi de journaux et la réplication asynchrone pour éviter d'avoir à recréer une réplique si elle prend trop de 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 entre le réplica et le maître pour s'assurer qu'il se trouve dans les limites acceptables de reprise après sinistre.

Logique vs physique

En plus de ça nous avons logique vs physique réplication en continu, telle qu'introduite dans PostgreSQL 9.4 :

  • Dans la réplication physique en continu les modifications sont envoyées presque au niveau du bloc de disque, comme "au décalage 14 de la page de disque 18 de la relation 12311, a écrit un tuple avec la valeur hexadécimale 0x2342beef1222...".

    La réplication physique envoie tout :le contenu de chaque base de données dans l'installation de PostgreSQL, toutes les tables de chaque base de données. Il envoie les 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, de sorte que vous ne pouvez rien faire qui nécessiterait une transaction, comme créer des tables temporaires ou non journalisées. L'interrogation du réplica retarde la réplication, de sorte que les longues requêtes sur le réplica doivent être annulées.

En échange, il est simple et efficace d'appliquer les modifications sur le réplica, et le réplica est exactement le même que le 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, de sorte qu'il y a 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.

  • réplication de flux logique , une nouveauté de la version 9.4, envoie les modifications à un niveau supérieur et de manière beaucoup plus sélective.

Il réplique une seule base de données à la fois. Il envoie uniquement les modifications de ligne et uniquement pour les transactions validées, et il n'a pas à envoyer de données vides, de modifications d'index, etc. Il peut envoyer des données de manière sélective uniquement pour certaines tables d'une base de données. Cela rend la réplication logique beaucoup plus efficace en termes de bande passante.

Opérer à un niveau supérieur signifie également que vous pouvez effectuer des transactions sur les répliques de bases de données. Vous pouvez créer des tables temporaires et non consignées. Même des tables normales, si vous voulez. Vous pouvez utiliser des wrappers de données étrangères, 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 s'exécutent trop longtemps.

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 grosses transactions au fur et à mesure qu'elles se produisent. Il faut attendre qu'ils s'engagent. Il peut donc y avoir un long délai entre la validation d'une grosse transaction sur le maître et son application au réplica.

Il rejoue 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 conserver vous-même les définitions de table synchronisées entre le maître et la réplique, ou l'application utilisant la réplication logique doit avoir ses propres installations pour le faire. Il peut être compliqué de bien faire les choses.

Le processus d'application lui-même est plus compliqué que "écrire quelques octets là où on me dit de le faire". Cela 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, ou 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 slots, max_wal_size , délais, fonctionnement de la promotion, Postgres-XL, BDR et multimaître, etc.

Alors que devez-vous faire ?

Il n'y a pas une seule bonne réponse. Sinon, PostgreSQL ne prendrait en charge que cette méthode. 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, offrant une sauvegarde continue facile à gérer. Vous devriez toujours prendre périodiquement pg_dump sauvegardes comme assurance supplémentaire.

Pour une haute disponibilité sans risque de perte de données utiliser la réplication synchrone en continu.

Pour une haute disponibilité avec un faible risque de perte de données et de meilleures performances vous devez utiliser la réplication de flux asynchrone. Activez l'archivage WAL pour le repli ou utilisez un emplacement de réplication. Surveillez la distance entre la réplique et le maître à l'aide d'outils externes comme Icinga.

Références