Discussion :

[Invité]

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

[SQLpro]

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 +

[StringBuilder]

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.

[SQLpro]

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 +

[StringBuilder]

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) ?

[SQLpro]

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 +

[StringBuilder]

Ok, alors c'est plus magique que le magicien

Vivement que je puisse travailler avec un jour !

[Invité]

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.

[SQLpro]

Voyez avec DataGuard.

A +