Discussion :

[garkhan]

Bonjour,

je dispose de l'infrastructure suivante:
- 1 serveur SQL Server 2012 Standard Edition (Win Server 2012) que l'on nommera SrvRepl
- 2 serveur SQL Server 2012 Express (Win Server 2012) que l'on nommera SrvLiveA et SrvLiveB
- 10 clients (Win 7)

La structure de la base de données du serveur SrvLiveA et du serveur SrvLiveB sont identique.

SrvLiveA ou SrvLiveB est dit "actif". C'est à dire que un OU l'autre, pas les deux sont susceptible de recevoir des clients. Le serveur qui n'est pas actif, ne fait rien, aucun accès en lecture/écriture de la part des clients. Je précise que le changement de serveur "actif" n'est pas fréquent (moins d'une fois par jour)

Selon se principe, certaine données seront sur SrvLiveA et d'autre sur SrvLiveB.

Je veux rassembler ces données sur SrvRepl afin de les centraliser et de les historiser.

Je veux également que les données qui ont été écrites sur le serveur SrvLiveA soient également disponible sur le SrvLiveB et vice versa.

Finalement, je veux :
- 2 serveurs "Live" ayant une base de données "répliqué" comportant les données SrvLiveA et SrvLiveB mais uniquement les 5000 dernières lignes(pour donner un exemple)
- 1 serveur historique/publieur ayant la totalité des données(une purge sera effectué pour limiter la taille de la base de données)

Mon idée est de mettre en place, sur le serveur SrvRepl, une base de données de publication mettant en commun les données de SrvLiveA et SrvLiveB et de leur renvoyer les données nécessaires.


Voilà voilà, ça n'a pas été facile d'écrire cela de manière claire, Et j'imagine que c'est pas claire du tout ^^ alors je suis la pour répondre à toute vos questions.

Je vous remercie d'avance pour vos réponses.

[mikedavem]

Hello,

SrvLiveA ou SrvLiveB est dit "actif". C'est à dire que un OU l'autre, pas les deux sont susceptible de recevoir des clients. Le serveur qui n'est pas actif, ne fait rien, aucun accès en lecture/écriture de la part des clients. Je précise que le changement de serveur "actif" n'est pas fréquent (moins d'une fois par jour)

Quel est le besoin derrière tout cela ? Disponibilité en cas de crash ? Peux-ton se permettre de perdre des données ? L'application peut être indisponible pendant combien de temps ? Décharge de l'activité sur un des serveurs suivant les horaires de production ? Est-ce que les données à répliquer concernant tous les objets de la base ou uniquement quelques tables ? ... Ce que je comprends (corrige moi si je fais erreur) c'est qu'un seul server est actif à la fois mais pas les 2 en même temps. Sans avoir plus d'élément je dirais que la solution la plus simple sera d'avoir une architecture de type mirroring par exemple (en asynchrone ou synchrone avec basculement automatique c'est une autre histoire en fonction du contexte). La réplication se fait automatiquement d'un serveur à un autre et en cas de basculement le sens de réplication est inversé .. ce qui me parait plus simple que l'architecture que tu as en place ... Mais je dis cela avec beaucoup de recul car je ne possède pas les tenants et aboutissants liés à ton contexte

++

[garkhan]

Hello,
Quel est le besoin derrière tout cela ?

Le but est de pouvoir accéder aux données "live" rapidement depuis tout client et ce 24/24. Les données "historiques" peuvent être indisponible occasionnellement.
C'est une application tiers qui décide quel est le serveur "actif".

Disponibilité en cas de crash ?

L'idée est en cas de crash du serveur "actif", c'est l'autre serveur qui doit prendre la main, tout doit se faire automatiquement.
Au moins un des 2 deux serveurs "live" doit être disponible à 100%. Quand je parle de 100%, une indisponibilité de l'ordre de la minute, occasionnellement, est acceptable.
On doit pouvoir travailler, à court terme(moins d'un jour) sans le serveur historique.

Peux-ton se permettre de perdre des données ?

C'est un système de supervision d'entreprise qui gère essentiellement des informations d'alarmes et d'état de fonctionnement. Donc la perte de données n'est pas dramatique(critique) mais cela doit être évité.

L'application peut être indisponible pendant combien de temps ?

La base de données doit être disponible 24/24.

Décharge de l'activité sur un des serveurs suivant les horaires de production ?

Je ne comprends pas très bien la question, que veux-tu savoir?
Certain jour ne sont pas travaillé et la nuit est plus calme.

Est-ce que les données à répliquer concernant tous les objets de la base ou uniquement quelques tables ? ...

Toute la base de données doit être répliquer. Celle-ci consiste en 2 tables de "travail" ou les informations sont inséré, 1 table d'état de fonctionnement(pour la signalisation du serveur actif notemment) et des tables de configuration qui ne sont modifié que manuellement.

Ce que je comprends (corrige moi si je fais erreur) c'est qu'un seul server est actif à la fois mais pas les 2 en même temps.

C'est exacte. Ils sont allumé les 2 en permanence mais il n'y en a qu'un ou des données sont écrites.

Sans avoir plus d'élément je dirais que la solution la plus simple sera d'avoir une architecture de type mirroring par exemple (en asynchrone ou synchrone avec basculement automatique c'est une autre histoire en fonction du contexte). La réplication se fait automatiquement d'un serveur à un autre et en cas de basculement le sens de réplication est inversé .. ce qui me parait plus simple que l'architecture que tu as en place ... Mais je dis cela avec beaucoup de recul car je ne possède pas les tenants et aboutissants liés à ton contexte
++

Tu parle ici de cluster, j'imagine. J'y avais pensé mais malheureusement, l'infrastructure déjà existante ne le permet pas (SQL server Express et application tiers)

[mikedavem]

Tu parle ici de cluster, j'imagine. J'y avais pensé mais malheureusement, l'infrastructure déjà existante ne le permet pas (SQL server Express et application tiers)

Aurais-tu envisagé de passer ton application sur une édition qui le permettrait (standard ou entreprise par exemple) ? En général le passage d'une application vers une architecture cluster SQL est assez transparente. On change la source de la chaîne de connexion ou on utilise un alias SQL éventuellement ou autre ... sauf exception applicative bien entendue ... que je ne connaisse pas :-)

++

[garkhan]

Il n'est pas envisageable de passer de SQL Express à une version payante.

Ce que je cherchais en créant ce topic, c'est savoir si il est possible d'utiliser la réplication pour synchroniser mes 3 serveurs, si ce n'est pas possible de le faire avec le synchronisation, je le ferai en utilisant les job et éventuellement les déclencheurs.

[mikedavem]

Avec une édition Express les possibilités de réplication restent faible.

++

[garkhan]

Oui, j'ai remarqué mais un SQL express peut être abonné à une réplication.

Je me demande donc si il existe un type de réplication qui fait ce que je veux.

[mikedavem]

La réplication transactionnelle bidirectionnelle ou la réplication de fusion pourraient faire l'affaire.

Cependant il faudrait que les serveurs sql en express (si je relis bien le premier post) puissent être publicateurs et abonnés.

++

[garkhan]

Cependant il faudrait que les serveurs sql en express (si je relis bien le premier post) puissent être publicateurs et abonnés.

Si je comprends bien ce que tu dis, dans les 2 sortes de réplications disponible, si les serveurs SQL Express sont uniquement abonnées(SQL Express ne peut être que abonné sauf erreur). Les écritures dans leur base de données seront perdu à chaque publications car le serveur SQL standard (publicateur) ne peut pas récupérer les données sur les abonnés?


Si ce que j'ai écrit ci-dessus est correcte, serait-il encore possible que, avant chaque publication, j’exécute un job qui va récupérer les données sur les abonnés pour mettre à jour la base de données du serveur publicateur et que a la fin de job, la publication est effectué? Cela ne fait-il pas un peu trop usine à gaz? Est-ce que ça en vaut la peine?

[mikedavem]

Si je comprends bien ce que tu dis, dans les 2 sortes de réplications disponible, si les serveurs SQL Express sont uniquement abonnées(SQL Express ne peut être que abonné sauf erreur). Les écritures dans leur base de données seront perdu à chaque publications car le serveur SQL standard (publicateur) ne peut pas récupérer les données sur les abonnés?

Oui ton serveur SQL Server standard est le seuil qui puisse être publicateur. Hors tes données viennent de tes instances SQL Server Express. Tu n'as donc aucun intérêt à avoir une topologie en réplication SQL Server ici. Autant que tu crées toi même tes jobs de réplication. Le seul publicateur que tu peux avoir c'est ton serveur en SQL Standard. Hors les données sont mis à jour depuis tes instances SQL Server Express. La il ne te reste plus qu'à créer toi même tes procédures de mise à jour depuis SQL Express --> SQL Server standard

++

[garkhan]

Oui ton serveur SQL Server standard est le seuil qui puisse être publicateur. Hors tes données viennent de tes instances SQL Server Express. Tu n'as donc aucun intérêt à avoir une topologie en réplication SQL Server ici. Autant que tu crées toi même tes jobs de réplication. Le seul publicateur que tu peux avoir c'est ton serveur en SQL Standard. Hors les données sont mis à jour depuis tes instances SQL Server Express. La il ne te reste plus qu'à créer toi même tes procédures de mise à jour depuis SQL Express --> SQL Server standard

++

C'est bien ce que je pensais. Du travaille en perspective.
Merci beaucoup pour ton aide rapide et efficace.

Maintenant, pour cette réplication, j'imaginais faire un job sur le serveur SrvRepl, avec plusieurs étapes, effectuant la réplication complète. Ceci me semble une bien meilleure solution que de travailler avec des triggers sur chaque tables, on est d'accord?

Je pensais créer des serveurs liés sur mon serveur standard pour me connecter aux deux serveurs Express, est-ce la meilleure solution? Ou il existe une meilleure manière?

Merci encore.

[mikedavem]

Maintenant, pour cette réplication, j'imaginais faire un job sur le serveur SrvRepl, avec plusieurs étapes, effectuant la réplication complète. Ceci me semble une bien meilleure solution que de travailler avec des triggers sur chaque tables, on est d'accord?

Je dirais qu'effectivement la solution à bases de trigger doit être réfléchi car elle a forcément un impact sur l'évolution du schéma (que se passe-t-il en cas de mise à jour par exemple ... faut-il avoir une phase d'étude avant mise à jour .... certainement) et sur les performances.

Je pensais créer des serveurs liés sur mon serveur standard pour me connecter aux deux serveurs Express, est-ce la meilleure solution? Ou il existe une meilleure manière?

Difficile à dire en connaissant pas le travail à effectuer. Tu peux effectuer passer par des serveurs liés + job SQL sur le serveur standard. Tu as aussi SSIS qui te permet de faire cela .. à voir les avantages / inconvénients de chaque solution dans ton contexte.

++

[SQLpro]

... elle a forcément un impact sur l'évolution du schéma (que se passe-t-il en cas de mise à jour par exemple ...

Tun veut sans doute dire mise à jour de la structure des tables - ALTER - et non mise à jour des données (UPDATE).

A +

[garkhan]

Re,

Après un peu de réflexion sur le problème, j'ai décidé de faire un job sur mon SQL Standard en utilisant des serveurs liés, c'est le plus simple à mettre en place et le code du job n'est pas si compliqué.

Merci beaucoup à tous pour votre aide, surtout mikedavem.