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 .