Streaming PostgreSQL versus réplication basée sur des fichiers (en termes de comportement et de configuration du serveur)

J'essaie de comprendre les meilleures utilisations de la réplication PostgreSQL et comment cela fonctionne afin que je puisse dépanner dans un environnement de production.

J'ai du mal à comprendre les différences entre ces 2 types de réplication en termes de (1) configuration (2) comment les 2 serveurs maître / esclave fonctionnent dans chaque scénario

La réplication sur PostgreSQL (9.2+) est essentiellement des fichiers XLOG de 16 Mo (en fonction des paramètres de fréquence pour la création de chaque fichier) sont créés sur le maître et envoyés par une méthode à l'esclave.

Ma configuration (aux fins de cette question)

Configuration de Postgresql.conf sur Master
archive_command = 'rsync -av% p postgres @ [SlaveIP]: [wal_archive_folder] /% f'

Configuration de Recovery.conf sur l'esclave pour lire les fichiers journaux
restore_command = 'cp [wal_archive_folder] /% f \ "% p \"'
primary_conninfo = 'host = [MasterIP] port = 5432 user = postgres'

Ma question est de savoir quelle partie de cette configuration fait cette réplication "en continu" par rapport à "l'envoi de journaux"? Mon maître est configuré pour utiliser rsync pour envoyer des journaux à l'esclave (est-ce l'envoi de journaux?) Mon esclave est configuré pour pouvoir se connecter au maître dans recovery.conf (est-ce en streaming?)

Deuxième partie de la question: que se passe-t-il? Je comprends qu'il existe un autre protocole sur PostgreSQL via WAL_sender & WAL_receiver. Mais je ne sais pas si cela est utilisé uniquement pour le streaming et si oui, comment le rsync est-il utilisé dans le Master?

:) Merci!! Et désolé si c'est une question évidente. J'ai fait beaucoup de lecture de blogs / livres mais j'ai du mal à comprendre. Le wiki de Postgres est tellement en profondeur qu'il faut beaucoup de temps pour tout comprendre (et j'ai des délais)

La "réplication en continu" fait référence à l'envoi continu d'enregistrements WAL via une connexion TCP / IP entre le maître et la réplique, à l'aide du protocole walsender via les replicationconnexions. Le maître lit son propre WAL pg_xloget l'envoie à la réplique à la demande. Il est configuré avec une primary_conninfodirective dans recovery.confet des pg_hba.confentrées sur le maître pour permettre les replicationconnexions. Vous avez également besoin wal_keep_segmentset d'autres options couvertes dans les documents.

"Envoi de journaux" se réfère à l'envoi périodique d'enregistrements WAL sous forme d'archives WAL entières via un protocole de transfert de fichiers vers un emplacement d'archivage à partir duquel la réplique peut ensuite les récupérer. Il est configuré avec une restore_commanddirective dans recovery.confet un archive_commanddans le maître. PostgreSQL ne se soucie pas de savoir où se trouvent les fichiers ni de la façon dont ils sont transférés, mais seulement de archive_commandles y restore_commandplacer et de récupérer l'archive requise; cela permet la construction de systèmes comme PgBarman et WAL-E.

La réplication en streaming n'a pas autant de retard, car les enregistrements sont envoyés lors de leur génération. Cependant, il nécessite que le maître et la réplique soient en ligne et puissent communiquer directement. Il nécessite également que la réplique se maintienne suffisamment bien pour que le maître ait toujours des copies sur disque du WAL dont la réplique a besoin, et vous oblige généralement à consacrer plus d' pg_xlogespace à la conservation de WAL supplémentaire pour la réplique.

La réplication d'envoi de journaux a plus de retard car le réplica ne voit WAL qu'une fois que toute une archive est envoyée. Cependant, il peut fonctionner même lorsque le maître et la réplique ne peuvent pas communiquer directement sur TCP / IP en utilisant un emplacement de stockage partagé. Il continue de fonctionner même si la réplique est en panne pendant un certain temps, car le maître n'aura supprimé le WAL pg_xlogqu'après l'avoir archivé, de sorte que le WAL est toujours dans l'archive et utilisable par la réplique même si le maître ne peut pas l'envoyer en streaming plus. Notez que archive_commandn'abandonne jamais, donc pg_xlogpeut se remplir si l'archivage échoue; pour cette raison, il est préférable d'archiver vers un emplacement fiable, puis de récupérer le serveur de répliques à partir de cet emplacement.

En général, vous combinez les deux, c'est-à-dire que vous utilisez les deux. Dans ce cas, la réplication en streaming est utilisée lorsque tout va bien. Si la réplique prend trop de retard et que le maître a supprimé les xlogs dont elle a besoin, un problème de connectivité se pose, etc., la réplique passera en lecture du WAL archivé jusqu'à ce qu'elle soit rattrapée. Il réessayera périodiquement de revenir au streaming jusqu'à ce qu'il réussisse.

Si vous n'en utilisez qu'un, utilisez l'envoi de journaux, car la réplication en continu sans repli de l'envoi de journaux est (jusqu'à PostgreSQL 9.4) potentiellement sujette à un retard de réplication, provoquant des échecs qui obligent à reconstruire une réplique.

PostgreSQL 9.4 change un peu cela, car la réplication en streaming peut désormais utiliser des "emplacements de réplication". Cela permet au maître de suivre la quantité de WAL dont une réplique a besoin et d'éviter de la jeter jusqu'à ce que la réplique l'ait rejouée. Il n'y a donc plus besoin de wal_keep_segmentssi vous utilisez un emplacement de réplication (pas la valeur par défaut).

Voir mon article sur les emplacements de réplication en streaming dans PostgreSQL 9.4 .

9.4 présente également les bases de la réplication logique en streaming , qui est un autre mécanisme, conçu pour être utilisé par des systèmes de réplication logique comme Londiste, Slony-I, et la nouvelle fonctionnalité de réplication multi-maître asynchrone bidirectionnelle .