Discussion :

[Herlece]

Bonsoir,

Je rencontre un souci. Je fais de la réplication sur une base SQL Server 2000. Lorsque mon server de prod tombe le server de réplication prend le relais. Mon souci c'est que les données qui sont insérées dans les bases de réplication ne sont pas présentes dans les tables concernées et lorsque je remet en route le server de prod, toutes les données manipulées sur le server de secours sont perdus.

donc il y a un paramètre que je ne maîtrise pas dans la réplication, mais lequel ?

Merci pour votre aide.

[SQLpro]

La réplication n'est pas une solution de haute disponibilité mais un pis allé. Vous confondez un usage avec un autre.
Répliquer l'intégralité des données d'une base n'a aucun intérêt, c'est même cata en terme de perf.
Si vous voulez de la haute dispo il faut soit utiliser un cluster, soit utiliser le log shipping.
En version 2005 et suivantes, vous pouvez en sus utiliser le mirroring.
Lisez l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/s...disponibilite/

[Herlece]

J'ai lu votre article avant de poster mais je ne suis pas a l'origine de cette solution je dois la gérer
Donc c'est quoi que j'ai loupe dans cette réplication qui fait que les données du serveur de backup ne sont pas reproduit sur le serveur de prod

[kagemaru]

c'est que les données qui sont insérées dans les bases de réplication ne sont pas présentes dans les tables concernées

Etes-vous sur que votre répli fonctionne ? Est-ce que vous réinitialisez la réplication une fois retourné sur le serveur principal ?

[Herlece]

Non je n'ai pas reinitialiser la réplication lors du retour sur le serveur de prod. Afin de voir si j'ai bien compris :
Lorsque je remet le serveur de prod en fonctionnement je dois, sur le serveur de réplication (la ou j'ai mes abonnements souscrits) faire un clic droit et selectionner "Reinitialiser".
Ai-je bien compris ou suis-je à côté ?

[SQLpro]

Non je n'ai pas reinitialiser la réplication lors du retour sur le serveur de prod. Afin de voir si j'ai bien compris :
Lorsque je remet le serveur de prod en fonctionnement je dois, sur le serveur de réplication (la ou j'ai mes abonnements souscrits) faire un clic droit et selectionner "Reinitialiser".
Ai-je bien compris ou suis-je à côté ?

Encore une fois commeil ne s'agit pas d'une solution de haute dispo, il n'y a pas de retour en arrière possible. La réplication n'étant pas la haute dispo, il n'y a pas de "reverse" possible sauf à faire une solution de réplication de fusion, mais là, ce sera pire encore, pour d'autres raisons (conflits de réplication, administration, ressources...) !

Si vous voulez une haute dispo réversible, il faut opter soit pour la mise en cluster, soit pour le mirroring.
L'utilisation qui a été faite de tenter d'utiliser la réplication comme technique des haute dispo est une stupidité monumentale !

A +

[kagemaru]

@sqlpro : je crois qu'Herlece demande comment marche la réplication et qu'on lui résolve ses problèmes ; je suis d'accord avec toi qu'il est parfois rageant de voir de telles situations dues à des mauvais choix ou à un manque d'information.

@Herlece : il faut vraiment détailler le problème, car c'est vraiment trop vague :

- Si j'ai bien compris, c'est une base A répliquée sur une base B, chacune étant hébergée sur un serveur distinct. Quelle est la taille de la base A ?
- S'il s'agit d'une réplication transactionnelle, est-ce qu'elle fonctionne ? Quand vous mettez à jour une table de la base A, est-ce que cette màj est reportée sur la base B ? Sinon, il y a un problème.
- Regardez les jobs dans la partie SQL Agent et consultez l'historique des jobs de type Distribution et Log Reader. S'il y a des erreurs postez-les.

Dans votre cas, j'aurais tendance à supprimer le flux de réplication et de repartir de zéro. Avec les infos dont on dispose, il n'est pas sûr que le fait de réinitialiser suffise.

Après il faudrait nous décrire le besoin pour cette application et vos contraintes (temps de reprise max pour les utilisateurs, perte de données tolérée, ...) . La réplication n'est peut-être pas la solution la mieux adaptée.

Comme le dit sqlpro, il pourrait être sage d'opter pour un logshipping par exemple, en particulier si vous êtes contraint de reste avec SQL Server 2000, c'est plus simple à gérer.

Référez-vous à ce lien pour bien comprendre le fonctionnement d'une réplication sous SQL Server 2000 : http://msdn.microsoft.com/en-us/libr...6(SQL.80).aspx

[Herlece]

- Si j'ai bien compris, c'est une base A répliquée sur une base B, chacune étant hébergée sur un serveur distinct. Quelle est la taille de la base A ?

oui c'est bien ça

- S'il s'agit d'une réplication transactionnelle, est-ce qu'elle fonctionne ? Quand vous mettez à jour une table de la base A, est-ce que cette màj est reportée sur la base B ?

oui elle fonctionne. Lorsque je mets à jour la base A j'ai bien la réplication dans la base B.

Après il faudrait nous décrire le besoin pour cette application et vos contraintes (temps de reprise max pour les utilisateurs, perte de données tolérée, ...) . La réplication n'est peut-être pas la solution la mieux adaptée.

Cette réplication est mise en place dans le cas d'une défaillance du serveur de prod. Je ne peux pas faire de mirroring car je suis obligé de rester sous SQL Server 2000.

Mon souci c'est que lorsque j'arrête le serveur de prod l'appli n'écrit pas dans la base B, celle de réplication, et je n'ai aucun message d'erreur. Donc j'essaie de comprendre le pourquoi. Est-ce que c'est la réplication transactionnelle qui est à l'origine de ce souci ou alors est-ce autre chose ?

@SQLpro : j'aime bien ton franc parler mais "stupidité monumentale" tu y vas fort (tu me fais mal je vais le dire à Pascale). Je n'ai pas toujours le choix des solutions en place et je ne peux pas dire à un client que je vais tout changer si je ne suis pas capable de lui expliquer pourquoi sa solution ne fonctionne pas.

[kagemaru]

Mon souci c'est que lorsque j'arrête le serveur de prod l'appli n'écrit pas dans la base B, celle de réplication, et je n'ai aucun message d'erreur. Donc j'essaie de comprendre le pourquoi. Est-ce que c'est la réplication transactionnelle qui est à l'origine de ce souci ou alors est-ce autre chose ?

C'est normal, à moins de reconfigurer votre appli pour atteindre la base B... Mais une fois que les utilisateurs auront commencé à utiliser la base B, le seul moyen de revenir sur la base A sera de faire un backup de B et de le recharger sur A.

[Herlece]

Ok Merci.

le seul moyen de revenir sur la base A sera de faire un backup de B et de le recharger sur A.

Bon maintenant je vais pouvoir expliquer pourquoi cette solution n'est pas la meilleure (merci SQLPro et Kagemaru pour votre patience et vos explications) et mettre en place soit un cluster ou un log shipping. Reste à voir comment on implémente tout ça.

Encore merci la communauté.

[SQLpro]

Autre solution, à mon avis la meilleure :
passer à SQL Server 2005 ou 2008 et utiliser le mirroring avec une base en retrocompatibilité 2000.

N'oubliez pas que le support de la version 2000 est terminé et que si votre serveur est HS il n'est pas impossible que vous ne puissiez pas réinstaller un SQL Server 2000 sur une machine plus moderne !
Sachez aussi que vous pouvez tester une telle solution pendant 180 jours.
Enfin, sachez que les serveurs redondants (Windows et SQL Server) ne sont pas payant.

A +

[Herlece]

Je leur avait déjà parler de faire un upgrade vers 2005, mais pour le moment ils ne sont vraiment pas chaud. Et leur souhait est à priori de faire "le moins mauvais" possible si je peut m'exprimer ainsi.

En effet le mirroring j'ai déjà fait, et c'est assez simple à mettre en place. J'ai suivi vos scriptes sur votre blog.

le support de la version 2000 est terminé et que si votre serveur est HS il n'est pas impossible que vous ne puissiez pas réinstaller un SQL Server 2000 sur une machine plus moderne !

En revanche ça c'est surement un argument qui pourrai bien les aider à repenser la question.