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
SQLpro
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up. Pourquoi ? 1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus de courant, de licence, d'admin que n machines Par exemple la moindre modif de structure de base nécessite l'arrêt de la réplication, la modif sur chaque serveur, la modification de la réplication et la remise en place de la réplication... Bref aun DBA à plein temps ! 2) il faut aussi répliquer les données sur l'ensemble des machines. cela occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10 machines, vos machine ne font plus que de la réplication entre elles ! 3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les limites de votre système ? Par exemple serveur avec 64 processeur, 256 Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions. Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc. quel solution avez vous choisi ? Avez vous connu des problème de fiabilité ?
merci A+ Etienne
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
De manière générale, au niveau des SGBDR, avant de faire du scale out,
il est préférable, à tous les niveaux de faire du scale up.
Pourquoi ?
1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus
de courant, de licence, d'admin que n machines
Par exemple la moindre modif de structure de base nécessite l'arrêt de
la réplication, la modif sur chaque serveur, la modification de la
réplication et la remise en place de la réplication... Bref aun DBA à
plein temps !
2) il faut aussi répliquer les données sur l'ensemble des machines. cela
occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10
machines, vos machine ne font plus que de la réplication entre elles !
3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les
limites de votre système ? Par exemple serveur avec 64 processeur, 256
Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en
vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions.
Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc.
quel solution avez vous choisi ?
Avez vous connu des problème de fiabilité ?
merci
A+ Etienne
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up. Pourquoi ? 1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus de courant, de licence, d'admin que n machines Par exemple la moindre modif de structure de base nécessite l'arrêt de la réplication, la modif sur chaque serveur, la modification de la réplication et la remise en place de la réplication... Bref aun DBA à plein temps ! 2) il faut aussi répliquer les données sur l'ensemble des machines. cela occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10 machines, vos machine ne font plus que de la réplication entre elles ! 3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les limites de votre système ? Par exemple serveur avec 64 processeur, 256 Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions. Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc. quel solution avez vous choisi ? Avez vous connu des problème de fiabilité ?
merci A+ Etienne
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
helios-services
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up. Pourquoi ? 1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus de courant, de licence, d'admin que n machines Par exemple la moindre modif de structure de base nécessite l'arrêt de la réplication, la modif sur chaque serveur, la modification de la réplication et la remise en place de la réplication... Bref aun DBA à plein temps ! 2) il faut aussi répliquer les données sur l'ensemble des machines. cela occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10 machines, vos machine ne font plus que de la réplication entre elles ! 3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les limites de votre système ? Par exemple serveur avec 64 processeur, 256 Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions. Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc. quel solution avez vous choisi ? Avez vous connu des problème de fiabilité ?
merci A+ Etienne
toujours aussi comique le Fred
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out,
il est préférable, à tous les niveaux de faire du scale up.
Pourquoi ?
1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus
de courant, de licence, d'admin que n machines
Par exemple la moindre modif de structure de base nécessite l'arrêt de
la réplication, la modif sur chaque serveur, la modification de la
réplication et la remise en place de la réplication... Bref aun DBA à
plein temps !
2) il faut aussi répliquer les données sur l'ensemble des machines. cela
occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10
machines, vos machine ne font plus que de la réplication entre elles !
3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les
limites de votre système ? Par exemple serveur avec 64 processeur, 256
Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en
vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions.
Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc.
quel solution avez vous choisi ?
Avez vous connu des problème de fiabilité ?
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up. Pourquoi ? 1) cela coûte intrinsèquement plus cher : chaque machine nécessite plus de courant, de licence, d'admin que n machines Par exemple la moindre modif de structure de base nécessite l'arrêt de la réplication, la modif sur chaque serveur, la modification de la réplication et la remise en place de la réplication... Bref aun DBA à plein temps ! 2) il faut aussi répliquer les données sur l'ensemble des machines. cela occupe entre 10 et 30 % de la charge, c'est à dire qu'en 3 et 10 machines, vos machine ne font plus que de la réplication entre elles ! 3) au niveau du MTBF, chaque machine ajoutée diminue le MTBF du système !
Bref, la question à vous poser est : avez-vous atteint actuellement les limites de votre système ? Par exemple serveur avec 64 processeur, 256 Go de RAM et plusieurs To de disque ?
A +
WebShaker a écrit :
Je suis prolifique aujourd'hui.
J'ai un peu cherché des infos sur la replication de base de données en vue de faire de la répartition de charge.
J'ai vu qu'il existe plusieurs solutions. Par contre il n'y a pas des masses de retour utilisateur sur internet.
Quelqu'un à il déjà mis en place ce genre de truc. quel solution avez vous choisi ? Avez vous connu des problème de fiabilité ?
merci A+ Etienne
toujours aussi comique le Fred
WebShaker
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX. Toute la salle serveur est tombé pendant 4 minutes la semaine dernière. Je me renseigne car plus de la répartition de charge c'est de la redondance qui m'interesse.
Voila pour les explication ;)
Merci Etienne
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out,
il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX.
Toute la salle serveur est tombé pendant 4 minutes la semaine dernière.
Je me renseigne car plus de la répartition de charge c'est de la
redondance qui m'interesse.
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX. Toute la salle serveur est tombé pendant 4 minutes la semaine dernière. Je me renseigne car plus de la répartition de charge c'est de la redondance qui m'interesse.
Voila pour les explication ;)
Merci Etienne
SQLpro
WebShaker a écrit :
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX. Toute la salle serveur est tombé pendant 4 minutes la semaine dernière. Je me renseigne car plus de la répartition de charge c'est de la redondance qui m'interesse.
Voila pour les explication ;)
Ce n'est donc pas de la réplication dont vous avez besoin mais d'un serveur en stand by "au cas ou". Cela s'appelle de la haute dispo. Ce n'est pas du tout la même chose. Par exemple vous pouvez opter pour du log shipping disponible sous postGreSQL.
A +
Merci Etienne
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************
WebShaker a écrit :
SQLpro a écrit :
De manière générale, au niveau des SGBDR, avant de faire du scale out,
il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX.
Toute la salle serveur est tombé pendant 4 minutes la semaine dernière.
Je me renseigne car plus de la répartition de charge c'est de la
redondance qui m'interesse.
Voila pour les explication ;)
Ce n'est donc pas de la réplication dont vous avez besoin mais d'un
serveur en stand by "au cas ou". Cela s'appelle de la haute dispo. Ce
n'est pas du tout la même chose.
Par exemple vous pouvez opter pour du log shipping disponible sous
postGreSQL.
A +
Merci
Etienne
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
De manière générale, au niveau des SGBDR, avant de faire du scale out, il est préférable, à tous les niveaux de faire du scale up.
Je suis hébergé des EQUINIX. Toute la salle serveur est tombé pendant 4 minutes la semaine dernière. Je me renseigne car plus de la répartition de charge c'est de la redondance qui m'interesse.
Voila pour les explication ;)
Ce n'est donc pas de la réplication dont vous avez besoin mais d'un serveur en stand by "au cas ou". Cela s'appelle de la haute dispo. Ce n'est pas du tout la même chose. Par exemple vous pouvez opter pour du log shipping disponible sous postGreSQL.
A +
Merci Etienne
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies *********************** http://www.sqlspot.com *************************