Discussion :

[slyz0r]

Hello *,

J'ai une base MySQL fonctionnant avec le moteur INNODB. J'ai fait quelques recherches sur le cluster MySQL et je me suis aperçu que le moteur utilisé (NDBCLUSTER) apportait pas mal de restrictions embêtantes comme les foreign keys ou les Index full text qui n'existent pas contrairement à INNODB.

J'ai alors pensé à Oracle, cette solution en particulier : https://shop.oracle.com/pls/ostore/f...79431805720007

Connaissez-vous les restrictions du cluster Oracle ? Est-il possible de migrer une base INNODB et de garder tous ses avantages ? Auriez-vous un retour d'expérience sur le sujet ?

Merci d'avance à tous et bonne journée !

[ojo77]

RAC supporte toutes les fonctionnalités acceptées par l'édition dite "entreprise" du SGBD Oracle.

Par contre il n'y a pas de grand intérêt à passer à RAC hors de la haute disponibilité. Une Haute disponibilité quasi équivalent peut-être atteinte en utilisant Oracle Dataguard sans pâtir des inconvénients liés à RAC et plus particulièrement à la mémoire partagée entre les nœuds et à la communication entre les instances.

Bref, pas de limitation fonctionnelle à RAC mais à tester avec précautions ...

[slyz0r]

En fait, actuellement, nous avons une application web utilisant une base INNODB sous MySQL (avec foreign keys, index full text,...).

Le cluster MySQL ne permet pas d'utiliser ses fonctionnalités. Par contre, il apporte tout ce que je recherche. Une ferme de plusieurs serveurs avec un hyperviseur qui pourrait faire du load balancing ainsi qu'un failover automatique en cas de perte d'un noeud.

Chez Oracle, je dois donc me tourner vers du RAC pour ceci ou Data guard suffit ? Quelles sont les différences ?

[ojo77]

RAC est la solution cluster d'Oracle, c'est cette brique qui va permettre de faire du load balancing et/ou un failover.

RAC présente une base de donnée qui est utilisée simultanément par plusieurs instances alors que Dataguard est un système de réplication qui ne va pas permettre l'équilibrage de charge.

Cependant, il est plus intéressant, du point de vue des performances et coût de licences, de doubler le nombre de processeur d'une machine non RAC que d'équilibrer la charge sur deux machines en RAC.