PostgreSQL a une matrice de différentes options de haute disponibilité qui représentent de nombreuses façons différentes de construire la réplication dans un SGBDR.
Des questions
La réplication d'Oracle Data Guard est similaire à la fonction "Hot / Warm Standby Using PITR" de PostgreSQL, qui est intégrée à la base de données à partir de PostgreSQL 9.0. La version 9.1 ajoute également la réplication synchrone. Un avantage de PostgreSQL sur Oracle ici est que Sync Rep peut être contrôlé par transaction. Vous pouvez avoir un "Important!" Entièrement synchrone Transaction suivie d'un "OK pour perdre" asynchrone dans Postgres.
Le RAC d'Oracle est similaire à ce que PostgreSQL appelle "basculement de disque partagé" dans cette grille. La principale différence est que RAC est entièrement intégré au produit Oracle, tandis que le «basculement de disque partagé» décrit simplement une méthode pour faire quelque chose. Vous devez assembler le logiciel de clusterware nécessaire autour de cela pour PostgreSQL, et il y a une variété de choses avancées que RAC fait, vous aurez du mal à les dupliquer dans PostgreSQL. J'entends régulièrement que la plupart de ces choses sont si compliquées à configurer que peu d'installations Oracle les corrigent non plus - simplement parce que RAC est intégré ne signifie pas qu'il se configure automatiquement.
La principale chose que vous pouvez faire dans Oracle qui est également très difficile à dupliquer dans PostgreSQL est la réplication multimaître. Il est possible de faire du multi-maître dans PostgreSQL, mais uniquement avec des logiciels complémentaires comme Bucardo. Et tous ces programmes ont encore plus de restrictions sur ce que vous pouvez en faire que les installations Oracle Multi-Master.
Je ne suis pas sûr de comprendre la partie "prise en charge par Oracle" dans votre question. Postgres n'est en aucun cas «pris en charge» par Oracle.
Le StandBy physique d'Oracle est équivalent à la réplication de streaming PostgreSQL.
Lorsque vous utilisez la réplication en streaming, la réplication asynchrone de PostgreSQL équivaut à la mise en veille d'Oracle en utilisant le mode "Performances maximales", tandis que la réplication synchrone (depuis 9.1) de PostgreSQL équivaut à la mise en veille d'Oracle en utilisant le mode "Disponibilité maximale".
Oracle a une autre option appelée Real Application Cluster (RAC) qui n'est pas disponible dans Postgres (il fait également l'équilibrage de la charge et la redirection automatique de la session vers un autre nœud, si l'un tombe en panne)
la source
Sur Oracle, vous avez essentiellement le choix entre exécuter une redondance d'UC et utiliser RAC .
L'objectif principal de la haute disponibilité est de supprimer les points de défaillance uniques. RAC le fait au niveau du serveur permettant la défaillance d'un serveur sans interruption de service. Vous devrez réaliser quelque chose de similaire à la fin du stockage en utilisant ASM , la mise en miroir et deux ou plusieurs pools de stockage physiquement indépendants (ou un SAN).
L'utilisation d'une redondance d'UC entraînera une interruption de service en cas de panne, mais est plus simple et comporte moins de "compromis d'ingénierie"
Un matériel de bonne qualité est également essentiel, par exemple SAS et non SATA, blocs d'alimentation redondants, onduleurs, etc.
Il existe également d'autres aspects de la haute disponibilité que vous devrez peut-être prendre en considération (par exemple, une erreur humaine) - ce livre blanc d'Oracle les aborde plus en détail.
la source