j'ai une question fonctionnelle par rapport à la réplication sous SQL2000.
J'ai utilisé l'assistant de réplication pour mettre en place une réplication
de type transactionnelle (chaque modification de table est répliquée sur le
deuxième serveur en temps réel) entre 2 serveursSql2000 Enterprise Edition
(sous Windows2000Serveur) .
Ma première question est la suivante :
Serveur1 = Serveur Principale
Serveur2 = Serveur Secondaire
La réplication fonctionne trés bien . Mais admettons que Serveur1 tombe en
panne, mes applications sont prévues pour fonctionner vers le Serveur2, donc
pas de problème. Le Serveur1 est réparé . Il est placé sur le réseau, va t il
essayer de resynchroniser la base de données avec le Serveur2 et donc
d'écraser le contenu de la base du Serveur2 avec les données antérieures
(datant du crash du serveur1) ?
Ma deuxième question est la suivante :
Comment doit je faire pour remettre à jour le Serveur1 ? Est ce qu'une
sauvegarde de la base de données concernée du Serveur2, puis une restauration
sur le Serveur1 est la solution ? En sachant que le fait de mettre en place
la réplication cela crée des tables utiles à la réplication dans le serveur1
qui ne se trouvent pas dans le serveur2. Du fait de la restauration, elle
vont s'y trouvée . Est ce que cela pose un problème ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
bruno reiter [MVP]
Si j'ai bien compris, le log shipping serait beaucoup plus adapté que la réplication dans ton cas.
Dans le cas de la réplication, le changement de serveur, et surtout le retour à la config d'origine, sera complexe. Alors qu'avec le log shipping, il ne s'agit que de backup et restore.
br
"Guillemin Gabriel" wrote in message news:
Bonjour et Bonne Année 2005
j'ai une question fonctionnelle par rapport à la réplication sous SQL2000. J'ai utilisé l'assistant de réplication pour mettre en place une
réplication
de type transactionnelle (chaque modification de table est répliquée sur
le
deuxième serveur en temps réel) entre 2 serveursSql2000 Enterprise Edition (sous Windows2000Serveur) .
Ma première question est la suivante : Serveur1 = Serveur Principale Serveur2 = Serveur Secondaire La réplication fonctionne trés bien . Mais admettons que Serveur1 tombe en panne, mes applications sont prévues pour fonctionner vers le Serveur2,
donc
pas de problème. Le Serveur1 est réparé . Il est placé sur le réseau, va t
il
essayer de resynchroniser la base de données avec le Serveur2 et donc d'écraser le contenu de la base du Serveur2 avec les données antérieures (datant du crash du serveur1) ?
Ma deuxième question est la suivante : Comment doit je faire pour remettre à jour le Serveur1 ? Est ce qu'une sauvegarde de la base de données concernée du Serveur2, puis une
restauration
sur le Serveur1 est la solution ? En sachant que le fait de mettre en
place
la réplication cela crée des tables utiles à la réplication dans le
serveur1
qui ne se trouvent pas dans le serveur2. Du fait de la restauration, elle vont s'y trouvée . Est ce que cela pose un problème ?
Existe t -il un document sur le sujet ?
Merci d'avance
-- Gabriel
Si j'ai bien compris, le log shipping serait beaucoup plus adapté que la
réplication dans ton cas.
Dans le cas de la réplication, le changement de serveur, et surtout le
retour à la config d'origine, sera complexe. Alors qu'avec le log shipping,
il ne s'agit que de backup et restore.
br
"Guillemin Gabriel" <GuilleminGabriel@discussions.microsoft.com> wrote in
message news:7DB48B83-C1D4-4C2F-8CC6-D58A0A7362AD@microsoft.com...
Bonjour et Bonne Année 2005
j'ai une question fonctionnelle par rapport à la réplication sous SQL2000.
J'ai utilisé l'assistant de réplication pour mettre en place une
réplication
de type transactionnelle (chaque modification de table est répliquée sur
le
deuxième serveur en temps réel) entre 2 serveursSql2000 Enterprise Edition
(sous Windows2000Serveur) .
Ma première question est la suivante :
Serveur1 = Serveur Principale
Serveur2 = Serveur Secondaire
La réplication fonctionne trés bien . Mais admettons que Serveur1 tombe en
panne, mes applications sont prévues pour fonctionner vers le Serveur2,
donc
pas de problème. Le Serveur1 est réparé . Il est placé sur le réseau, va t
il
essayer de resynchroniser la base de données avec le Serveur2 et donc
d'écraser le contenu de la base du Serveur2 avec les données antérieures
(datant du crash du serveur1) ?
Ma deuxième question est la suivante :
Comment doit je faire pour remettre à jour le Serveur1 ? Est ce qu'une
sauvegarde de la base de données concernée du Serveur2, puis une
restauration
sur le Serveur1 est la solution ? En sachant que le fait de mettre en
place
la réplication cela crée des tables utiles à la réplication dans le
serveur1
qui ne se trouvent pas dans le serveur2. Du fait de la restauration, elle
vont s'y trouvée . Est ce que cela pose un problème ?
Si j'ai bien compris, le log shipping serait beaucoup plus adapté que la réplication dans ton cas.
Dans le cas de la réplication, le changement de serveur, et surtout le retour à la config d'origine, sera complexe. Alors qu'avec le log shipping, il ne s'agit que de backup et restore.
br
"Guillemin Gabriel" wrote in message news:
Bonjour et Bonne Année 2005
j'ai une question fonctionnelle par rapport à la réplication sous SQL2000. J'ai utilisé l'assistant de réplication pour mettre en place une
réplication
de type transactionnelle (chaque modification de table est répliquée sur
le
deuxième serveur en temps réel) entre 2 serveursSql2000 Enterprise Edition (sous Windows2000Serveur) .
Ma première question est la suivante : Serveur1 = Serveur Principale Serveur2 = Serveur Secondaire La réplication fonctionne trés bien . Mais admettons que Serveur1 tombe en panne, mes applications sont prévues pour fonctionner vers le Serveur2,
donc
pas de problème. Le Serveur1 est réparé . Il est placé sur le réseau, va t
il
essayer de resynchroniser la base de données avec le Serveur2 et donc d'écraser le contenu de la base du Serveur2 avec les données antérieures (datant du crash du serveur1) ?
Ma deuxième question est la suivante : Comment doit je faire pour remettre à jour le Serveur1 ? Est ce qu'une sauvegarde de la base de données concernée du Serveur2, puis une
restauration
sur le Serveur1 est la solution ? En sachant que le fait de mettre en
place
la réplication cela crée des tables utiles à la réplication dans le
serveur1
qui ne se trouvent pas dans le serveur2. Du fait de la restauration, elle vont s'y trouvée . Est ce que cela pose un problème ?
Existe t -il un document sur le sujet ?
Merci d'avance
-- Gabriel
Guillemin Gabriel
Merci pour votre réponse ...
Oui mais il faut que je rentre quand même dans un système de réplication car les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au niveau des ateliers de productions avec la seule contrainte en cas de perte du Serveur1 pour les electriciens : changer de serveur en passant sur le Serveur2 au niveau du paramètrage applicatif. L'applicatif bascule sur le Serveur2 , c'est transparent pour la production puisqu'avec la réplication les mises à jour de table sont faites quasi instentanement sur les 2 serveurs .
Merci pour votre réponse ...
Oui mais il faut que je rentre quand même dans un système de réplication car
les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au
niveau des ateliers de productions avec la seule contrainte en cas de perte
du Serveur1 pour les electriciens : changer de serveur en passant sur le
Serveur2 au niveau du paramètrage applicatif.
L'applicatif bascule sur le Serveur2 , c'est transparent pour la production
puisqu'avec la réplication les mises à jour de table sont faites quasi
instentanement sur les 2 serveurs .
Oui mais il faut que je rentre quand même dans un système de réplication car les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au niveau des ateliers de productions avec la seule contrainte en cas de perte du Serveur1 pour les electriciens : changer de serveur en passant sur le Serveur2 au niveau du paramètrage applicatif. L'applicatif bascule sur le Serveur2 , c'est transparent pour la production puisqu'avec la réplication les mises à jour de table sont faites quasi instentanement sur les 2 serveurs .
bruno reiter [MVP]
c'est extremement dangereux pour l'intégrité car rien ne garanti que les transactions sont passées
dans ce cas, un cluster est indiqué.
si tu veux réellement passer par de la répli transactionelle, je ne vois que des scenerii complexes : passer par une base intermédiaire à la bascule, mettre des trriggers, enlever la répli, backup/restore, remettre la répli ...
un log shipping à intervalle d'une minute est certainement plus viable.
br
"Guillemin Gabriel" wrote in message news:
Merci pour votre réponse ...
Oui mais il faut que je rentre quand même dans un système de réplication
car
les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au niveau des ateliers de productions avec la seule contrainte en cas de
perte
du Serveur1 pour les electriciens : changer de serveur en passant sur le Serveur2 au niveau du paramètrage applicatif. L'applicatif bascule sur le Serveur2 , c'est transparent pour la
production
puisqu'avec la réplication les mises à jour de table sont faites quasi instentanement sur les 2 serveurs .
c'est extremement dangereux pour l'intégrité car rien ne garanti que les
transactions sont passées
dans ce cas, un cluster est indiqué.
si tu veux réellement passer par de la répli transactionelle, je ne vois que
des scenerii complexes : passer par une base intermédiaire à la bascule,
mettre des trriggers, enlever la répli, backup/restore, remettre la répli
...
un log shipping à intervalle d'une minute est certainement plus viable.
br
"Guillemin Gabriel" <GuilleminGabriel@discussions.microsoft.com> wrote in
message news:94F77D3E-D7E5-436F-977D-AC70CFBA53E3@microsoft.com...
Merci pour votre réponse ...
Oui mais il faut que je rentre quand même dans un système de réplication
car
les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au
niveau des ateliers de productions avec la seule contrainte en cas de
perte
du Serveur1 pour les electriciens : changer de serveur en passant sur le
Serveur2 au niveau du paramètrage applicatif.
L'applicatif bascule sur le Serveur2 , c'est transparent pour la
production
puisqu'avec la réplication les mises à jour de table sont faites quasi
instentanement sur les 2 serveurs .
c'est extremement dangereux pour l'intégrité car rien ne garanti que les transactions sont passées
dans ce cas, un cluster est indiqué.
si tu veux réellement passer par de la répli transactionelle, je ne vois que des scenerii complexes : passer par une base intermédiaire à la bascule, mettre des trriggers, enlever la répli, backup/restore, remettre la répli ...
un log shipping à intervalle d'une minute est certainement plus viable.
br
"Guillemin Gabriel" wrote in message news:
Merci pour votre réponse ...
Oui mais il faut que je rentre quand même dans un système de réplication
car
les applications doivent être fonctionnelles 24h sur 24 h sans arrêts au niveau des ateliers de productions avec la seule contrainte en cas de
perte
du Serveur1 pour les electriciens : changer de serveur en passant sur le Serveur2 au niveau du paramètrage applicatif. L'applicatif bascule sur le Serveur2 , c'est transparent pour la
production
puisqu'avec la réplication les mises à jour de table sont faites quasi instentanement sur les 2 serveurs .
