Prêt pour la production?
Oui, il est prêt pour la production et largement utilisé. Les adeptes de Heroku sont basés sur la réplication asynchrone intégrée de PostgreSQL par exemple, tout comme les standbys AWS RDS et les réplicas en lecture. La réplication en streaming est utilisée presque universellement avec PostgreSQL.
La configuration de la réplication n'est pas vraiment charmante, mais des outils comme repmgr aident quelque peu à cela, et s'améliorent lentement avec chaque version majeure. La possibilité pour pg_basebackup de prendre une copie du système en utilisant la réplication en streaming (et de le faire à partir d'un autre standby) est d'une grande aide.
En général, une fonctionnalité ne sera tout simplement pas publiée dans PostgreSQL tant qu'elle n'est pas prête pour la production. Les bugs se produisent, comme dans tout logiciel, mais ils sont généralement corrigés peu de temps après leur identification. Les nouvelles fonctionnalités vraiment majeures ont parfois des bogues et des problèmes découverts après la version .0, mais dans ce cas, les corriger est une priorité élevée; les bugs ne sont pas seulement laissés pour compte.
Je ne suis au courant d'aucun problème sérieux avec la réplication en streaming - synchronisation ou async - et je n'en ai vu aucun signalé depuis un bon moment. Ils étaient moins stables que la norme habituelle de Pg dans les versions .0 des principales versions dans lesquelles ils ont été introduits, mais les deux ont mûri rapidement et sont parfaitement prêts pour la production.
(Mise à jour: il y avait un bogue spécifique dans la nouvelle version 9.3 avant 9.3.4 qui a causé des problèmes de réplication dans certains cas; les utilisateurs de 9.3 devraient mettre à jour vers 9.3.4 immédiatement. Les versions plus anciennes ne sont pas affectées.)
La seule mise en garde que je veux mentionner est un détail mineur avec la réplication synchrone: si vous vous engagez sur le maître, puis annulez la requête après qu'elle se soit validée en attendant que la réplique soit confirmée, elle est traitée comme validée sur le maître avant même sa réplication. Vous obtenez le même effet en redémarrant le maître en attendant que la réplique réponde. Dans la pratique, cela n'est pas pertinent, mais c'est à peu près le seul problème auquel je peux penser.
Comparer avec MySQL?
La réplication native de Pg est assez différente de celle de MySQL.
MySQL utilise la réplication logique où il envoie les modifications logiques apportées aux données de la table, à la structure de la table, etc., et la réplique applique ces modifications.
La réplication de PostgreSQL est de niveau inférieur (en 9.5 et en dessous; les futures versions pourraient également ajouter une réplication logique). Il envoie les blocs qui ont changé dans les tableaux. C'est plus simple, plus facile à obtenir et impose une charge moindre sur le serveur de réplique, mais consomme plus de bande passante réseau et nécessite plus de stockage sur le maître pour contenir les modifications non encore répliquées. Il est préférable de le configurer pour utiliser la réplication en streaming avec repli d'archivage WAL, ce qui le rend plus complexe à configurer que celui de MySQL. Il réplique les changements de bas niveau comme l'activité VACUUM, pas seulement les changements de tuple, en gardant l'état sur disque de la réplique identique à celui du maître. Il est incapable de répliquer une seule base de données; l'ensemble du système doit être répliqué, ce qui peut être frustrant si vous avez une grande base de données à taux de désabonnement élevé et sans importance et une petite base de données à faible taux de désabonnement et vitale.
Dans l'ensemble, cela dépend de ce que vous voulez en faire.
Je considère la réplication de PostgreSQL comme considérablement meilleure pour les répliques utilisées pour la sauvegarde, la haute disponibilité et la reprise après sinistre. Cela est particulièrement vrai lorsqu'il est combiné avec une récupération ponctuelle (PITR) .
D'un autre côté, ce n'est pas aussi bon pour les réplicas de rapports en lecture seule, car la nécessité de retarder l'application des données répliquées lors de l'exécution de transactions longues signifie que vous devez soit le laisser annuler de très longues requêtes en cours d'exécution, soit prendre beaucoup de retard sur le maître, consommant plus d'espace disque sur le maître et le forçant à travailler plus fort pour suivre.
Des travaux sont en cours pour activer la réplication logique dans PostgreSQL , où les modifications logiques de la structure de la table, du contenu de la table, etc. sont répliquées, plutôt que leur état sur disque. La conception du catalogue de Pg et la prise en charge de tout ce qui est défini par l'utilisateur rend cette tâche assez complexe. Une partie du travail préparatoire a été mise en place pour la version 9.4, mais il est peu probable que la réplication logique complète soit utilisable avant la version 9.6 ou ultérieure.
