IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Optimisations SGBD Discussion :

Disponibilité d'une base pendant la mise-à-jour


Sujet :

Optimisations SGBD

  1. #1
    Invité
    Invité(e)
    Par défaut Disponibilité d'une base pendant la mise-à-jour
    Bonjour à tous

    Je ne sais pas si ma discussion se trouve dans la bonne partie.

    J'ai la problématique suivante qui m'ait posé :

    L'équipe dans laquelle je suis effectue une mise-à-jour toutes les 6 semaines environ.
    La maj concerne la base de données, les web-services, les IHM et le serveur d'application java.

    L'application possède une architecture en miroir, ce qui fait qu'on peut basculer une partie du miroir sur la version N+1, vérifier que c'est ok puis la seconde partie. Cela permet de gagner du temps.

    Le problème qui se pose est que la base de données n'est pas dupliqué et que l'on souhaiterait que les modifications faites pendant la mep (mise en production) soit répercuté sur la deuxième base.

    On pensait conserver les enregistrements mais cela semble compliqué. Quelle solution avez-vous trouver pour gérer ce genre de problématique ?

    ps : l'idée de base peut paraître débile, autant attendre la fin de la mep mais le client est roi ....

    Merci d'avance

  2. #2
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 922
    Points : 51 715
    Points
    51 715
    Billets dans le blog
    6
    Par défaut
    Tout dépend du SGBDR choisit et des techniques intégrées qui lui sont propres.

    Par exemple avec Microsoft SQL Server, que ce soit en mirroring ou avec AlwaysOn, la propagation des modifications de la base est automatique et si l'on est en mode synchrone, instantanée....

    Si votre SGBDR ne dispose pas d'un tel mécanisme, il va falloir le faire à la main, et là c'est pas gagné !

    A +

  3. #3
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 172
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 172
    Points : 7 422
    Points
    7 422
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Tout dépend du SGBDR choisit et des techniques intégrées qui lui sont propres.

    Par exemple avec Microsoft SQL Server, que ce soit en mirroring ou avec AlwaysOn, la propagation des modifications de la base est automatique et si l'on est en mode synchrone, instantanée....

    Si votre SGBDR ne dispose pas d'un tel mécanisme, il va falloir le faire à la main, et là c'est pas gagné !

    A +
    J'ai l'impression surtout que le problème ne réside pas dans la propagation des données, mais leur "migration" d'une structure de version 1 à une version 2.

    Genre dans le lot 1, il y'a une table "produit (id, nom, prix)"
    Et dans le lot 2, la table produit perd la colonne "prix", et une nouvelle table apparaît avec une relation.
    Pendant la recette du lot 2, on crée des lignes dans la nouvelle structure et dans l'ancienne (chaque serveur vit sa vie). Et si on ne veut pas exploser le serveur en mirroir, on est obligé de désynchroniser.
    Du coup, quand tout est OK, ils savent pas trop comment récupérer soit sur le serveur "V2" les modifs du "V1" pendant la recette, soit l'inverse.

  4. #4
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 922
    Points : 51 715
    Points
    51 715
    Billets dans le blog
    6
    Par défaut
    Citation Envoyé par StringBuilder Voir le message
    J'ai l'impression surtout que le problème ne réside pas dans la propagation des données, mais leur "migration" d'une structure de version 1 à une version 2.

    Genre dans le lot 1, il y'a une table "produit (id, nom, prix)"
    Et dans le lot 2, la table produit perd la colonne "prix", et une nouvelle table apparaît avec une relation.
    Pendant la recette du lot 2, on crée des lignes dans la nouvelle structure et dans l'ancienne (chaque serveur vit sa vie). Et si on ne veut pas exploser le serveur en mirroir, on est obligé de désynchroniser.
    Du coup, quand tout est OK, ils savent pas trop comment récupérer soit sur le serveur "V2" les modifs du "V1" pendant la recette, soit l'inverse.
    Mais c'est exactement ce que fais le mirroring, ainsi que AlwaysOn !

    En effet et contrairement à Oracle qui ne respecte pas la norme SQL sur ce point, tout ordre DDL (CREATE, ALTER ou DROP) est transactionné dans SQL Server. Or comme le mirroring ou AlwaysOn propage les transactions, ces commandes sont envoyées aux réplicas....

    A +

  5. #5
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 172
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 172
    Points : 7 422
    Points
    7 422
    Billets dans le blog
    1
    Par défaut
    Euh...

    Oui, mais c'est justement ce qu'il ne veulent pas

    De ce que j'ai compris, ils mettent à jour le serveur 1 avec la nouvelle structure (+ migration des données concernées).

    Ensuite, ils font des tests, à priori, du réel (genre une équipe d'utilisateurs pilotes utilise la nouvelle version).

    Pendant ce temps, le serveur 2 conserve la structure actuelle : donc pas de modification de structure ni migration des données.

    Et la masse des gens continue à utiliser serveur 2 normalement.

    Ensuite, quand au bout d'une semaine, il s'avère que serveur 1 n'a pas planté, et que c'est tout bon pour migrer tout le monde, ils souhaitent fusionner les deux serveurs :
    - propager la nouvelle structure sur serveur 2
    - récupérer sur serveur 1 les données saisies avec l'ancienne structure
    - récupérer sur serveur 2 les données saisies avec la nouvelle structure

    Après, je connais pas Always On ni le Mirroring, jamais bossé avec ces techniques (petit pandawa qui n'arrive pas à passer à des projets plus gros que du Express :o)

    Mais je serais surpris que tout se passe bien (surtout récupérer sur serveur 1 les données saisies avec l'ancienne structure de serveur 2) ?

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 922
    Points : 51 715
    Points
    51 715
    Billets dans le blog
    6
    Par défaut
    Dans ce cas, il suffit de faire un mirroring ou un AlwaysOn asynchrone (ou de passer de synchrone à asynchrone) et de suspendre le service de propagation des transactions (c'est juste une commande SQL du genre ALTER DATABASE ... SET PARTNER SUSPEND.
    Une fois les tests passés, faire : ALTER DATABASE ... SET PARTNER RESUME.

    La seule chose est que le journal va se mettre à grossir entre les deux phases du fait de la rétention des transactions et qu'il faut, soit prévoir la place, soit minimiser le temps de test.

    A +

  7. #7
    Expert éminent
    Avatar de StringBuilder
    Homme Profil pro
    Chef de projets
    Inscrit en
    Février 2010
    Messages
    4 172
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Chef de projets
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Février 2010
    Messages : 4 172
    Points : 7 422
    Points
    7 422
    Billets dans le blog
    1
    Par défaut
    Ok, alors c'est plus magique que le magicien

    Vivement que je puisse travailler avec un jour !

  8. #8
    Invité
    Invité(e)
    Par défaut
    De ce que j'ai compris, ils mettent à jour le serveur 1 avec la nouvelle structure (+ migration des données concernées).

    Ensuite, ils font des tests, à priori, du réel (genre une équipe d'utilisateurs pilotes utilise la nouvelle version).

    Pendant ce temps, le serveur 2 conserve la structure actuelle : donc pas de modification de structure ni migration des données.

    Et la masse des gens continue à utiliser serveur 2 normalement.

    Ensuite, quand au bout d'une semaine, il s'avère que serveur 1 n'a pas planté, et que c'est tout bon pour migrer tout le monde, ils souhaitent fusionner les deux serveurs :
    - propager la nouvelle structure sur serveur 2
    - récupérer sur serveur 1 les données saisies avec l'ancienne structure
    - récupérer sur serveur 2 les données saisies avec la nouvelle structure
    C'est exactement ça sauf qu'il n'y a pas de tests mais ce système a été mis-en-place pour augmenter le délai de disponibilité de l'application.

    La base est une base Oracle.

  9. #9
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 922
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 922
    Points : 51 715
    Points
    51 715
    Billets dans le blog
    6
    Par défaut
    Voyez avec DataGuard.

    A +

Discussions similaires

  1. Réponses: 15
    Dernier message: 05/02/2012, 20h31
  2. Haute disponibilite d'une base de donnée
    Par mmoustachar dans le forum Débuter
    Réponses: 6
    Dernier message: 19/09/2007, 11h51
  3. Envoi email des qu'une page internet est mise à jour
    Par mamok dans le forum Balisage (X)HTML et validation W3C
    Réponses: 3
    Dernier message: 12/09/2007, 11h52
  4. Réponses: 7
    Dernier message: 15/01/2007, 19h18
  5. Réponses: 13
    Dernier message: 27/11/2006, 12h17

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo