Publicité
+ Répondre à la discussion
Affichage des résultats 1 à 3 sur 3
  1. #1
    Nouveau Membre du Club
    Inscrit en
    juin 2006
    Messages
    418
    Détails du profil
    Informations forums :
    Inscription : juin 2006
    Messages : 418
    Points : 34
    Points
    34

    Par défaut Alimenter un MySQL Cluster 7.2 à partir de SyBase pour un fail over et cache de données

    Bonjour à tous,

    Je vous expose mon besoin ainsi que le contexte et espérons que ej suis sur le bon forum

    Dans le cadre d’une refonte applicative , le but qui a été défini est d’assurer une solution de haute disponibilité , priorité au Fail over, tout en absorbant un grand nombre d’utilisateurs (plusieurs milliers faisant autant voire plus d’opérations ) : la mise en place d’un cluster de données a été donc décidée par l’ancienne équipe d’architecture afin de mettre en place cette solution de « cache applicative » et le choix du nouveau MySQL Cluster 7.2 a été déjà fait avant même que j’intègre le projet , un choix à respecter (déjà imposé à vrai dire) mais que j’essaie de comprendre afin de l’adapter au besoin et étudier sa mise en place.

    Maintenant, le vrai challenge c’est de pouvoir se baser sur une partie du SI existant pour alimenter le modèle MYSQL qui sera clustérisé gros, il y a 5 principales grosses tables qui sont pratiquement mise à jour toutes les Xmn, hébergées sur 5 serveurs SYBASE différents ( aucune migration possible, épargnez moi les politiques interne entre départements ) ..ces tables doivent servir à alimenter le modèle MySQL du cluster qui se constituera d’ un modèle simple ayant , comme début, une seule table sans jointures et possédant une clé primaire bien définie qui centralisera les données issues des 3 tables, en gros une ligne correspondra ç une agrégation scalaire ( pas de SUM , AVG , COUNT etc.…) des 5 lignes récupérées des 3 tables sources) , qui hébergé sur un autre serveur , et ce chaque fois qu’elles sont elles mêmes mise à jour..

    Avant de discuter de l’architecture même du Cluster MySQL à mettre en place , je voulais savoir avant : Quelle seraient selon vous l’architecture idéale pour répondre à ce besoin , et surtout quel mode de communication/Update privilégiez vous entre les 3 tables Sybase , sources des données , et la nouvelle table MySQL ?

    Je ne suis pas un DBA mais plutôt architecte et je vais me pencher sur ce problème, donc amis DBA et experts MySQL /Sybase toute aide serait la bienvenue, n’hésitez pas à poser vos questions surtout si quelque chose n’est pas claire.

    Merci d'avance

  2. #2
    Nouveau Membre du Club
    Inscrit en
    juin 2006
    Messages
    418
    Détails du profil
    Informations forums :
    Inscription : juin 2006
    Messages : 418
    Points : 34
    Points
    34

    Par défaut

    Espérons que quelqu’un finira par donner un coup de main

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro Frédéric BROUARD
    Expert SGBDR & SQL
    Inscrit en
    mai 2002
    Messages
    13 352
    Détails du profil
    Informations personnelles :
    Nom : Homme Frédéric BROUARD
    Localisation : France

    Informations professionnelles :
    Activité : Expert SGBDR & SQL
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 13 352
    Points : 27 434
    Points
    27 434

    Par défaut

    Il n'est pas étonnant que personne ne vous fournisse de réponse sur ce sujet tant il est stupide.
    MySQL st un veau dès que le nombre d'utilisateur augmente car il n'a jamais su gérer les transactions correctement.
    A lire sur le sujet : http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux
    De la à faire un cluster dans une architecture combinée avec en sus du Sybase qui est en voie de disparition....
    Bref, projet voué à l'échec ou alors il faudra y mettre les sous :
    consultant expert Sybase (par exemple Ballafeul à Nantes, mais 1200 € / jour) + Matériel hors norme....

    Personnellement je ferais un proposition plus raisonnable sur des technologies éprouvées (Oracle, SQL Server...) et si le changement ne se fait pas, alors je la fuirait.

    Poser vous la question du pourquoi votre prédécesseur est partit... Ne serait-ce pas parce que après avoir avancé un tel projet sur la papier il a préféré fuir parce que cela lui semblait infaisable ?

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
    http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
    * * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •