Solutions PostgreSQL vs Oracle High Availability?


8

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.

Voici la matrice des fonctionnalités de haute disponibilité, d'équilibrage de charge et de réplication de PostgreSQL

Des questions

  • Lesquelles des approches de la matrice de haute disponibilité PostgreSQL sont prises en charge par Oracle?
  • Oracle fait-il de la haute disponibilité avec des techniques qui ne sont pas disponibles avec PostgreSQL?

Réponses:


7

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.


Greg J'ai vraiment apprécié votre vidéo "Synchronous Replication and Durability Tuning Greg Smith". Je l'ai regardée hier soir! Cela m'a vraiment aidé à comprendre les différentes options. Cela ne me dérange pas toutes les options de réplication dans Postgres, cela prend juste un certain temps pour déterminer ce qui est le bon pour mon application.
Ams

Il convient de noter que le multi-maître est parfois une solution à la recherche d'un problème, à la suite d'un argumentaire de vente Oracle réussi.
Rob Grant

4

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)


Je comprends parfaitement que postgres n'est pas pris en charge par Oracle. Ce que je cherche à savoir, c'est quelles approches de réplication sont implémentées par les deux produits. Mes pensées sont si une approche de réplication est assez bonne pour Oracle, alors c'est probablement l'une des meilleures approches de réplication.
Ams

2
La raison pour laquelle il existe tant de choix de réplication est que chacun est adapté à un type d'application différent. L'idée que certains sont "assez bons" et d'autres ne le sont pas n'est pas vraie. Par exemple, l'approche de réplication basée sur les déclencheurs n'est pas populaire pour Oracle. Mais c'est dans PostgreSQL et MySQL, car il convient aux types d'applications qu'Oracle ne vise pas.
Greg Smith

1

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.