Encore une fois Arthemus vous supposez beaucoup de chose sur moi, alors que visiblement vous ne savez pas de quoi vous parlez...
Je vous ais déjà invité à lire mon ouvrage sur SQL et vous n'avez pas voulu...
Je vous ais aussi indiqué que je pouvais vous l'envoyer par la poste et vous avez refusé car vous voulez préservez votre anonymat...
Et vous avez mêle décliné la poste restante !
Et certains de vos posts montrent à quel point vos croyances sont fondés sur une certaine expérience qui est loin d'être la réalité....
Un peu d'ouverture et d'humilité serait bienvennue !
Ben voyons.....Envoyé par Artemus24
La demande porte sur la sauvegarde et vous lui balancez la haute dispo et vous m'accusez d'entretenir la confusion alors que c'est vous qui l'avez introduite et moi qui ait pointé que vos dires n’avariant rien à voir avec la demande initiale !
Quelle mauvaise foi !La doc que vous donnez montre un serveur NEC qui existe chez la plupart des autres constructeurs depuis des lustres (HP, IBM, DELL...) Mais il existe toujours un SPOF qui peut être l'onduleur ou le réseau....
Il n'y a pas de basculement à faire. La tolérance de panne consiste à doubler le matériel (pas uniquement les disques) pour éviter la panne physique.
De ce fait, le serveur ne tombe jamais en panne car tout est doublé. On se retrouve dans de la disponibilité en continue.
http://fr.nec.com/fr_FR/emea/product...ervers/ft.html
Même le basculement d'un CPU pour isolation suite à défaut provoquera une légère interruption. En effet, certains processus système devront être redémarré sur l'autre nœud... Ce qui provoque automatiquement une attente....Non, il est vrai que je n'ai écrit aucun article sur le sujet.... Comme par exemple :
Il n'y a pas d'interruption en cas de panne. Justement la tolérance de panne est faite pour éviter ce genre de problèmes matériels.
La tolérance de panne concerne la disponibilité physique du matériel. Cela n'a rien à voir avec un backup et cela n'empêche pas de temps en temps d'en faire un.
J'ai surtout l'impression que tu ne sais pas ce que c'est la tolérance de panne !
http://sqlpro.developpez.com/cours/s...disponibilite/
écrit en 2006... Sans doute je ne sais pas de quoi je parle.....
En sus je n'ai jamais travaillé dans le domaine de la base de données, domaines dans lequel je n'ai jamais écrit de livre... Comme par exemple :
En 2001
De même je n'ai pas d'entreprise spécialisée dans le conseil en matière de SGBD...
http://www.societe.com/societe/sql-spot-495059123.html
Et enfin, je ne suis pas considéré comme expert par Microsoft sur les technologies SQL Server :
https://mvp.microsoft.com/zh-tw/Publ...eric%20Brouard
Ce qui fait que jamais au grand jamais je ne me suis posé des questions sur la haute disponibilité des bases de données.... Même pas pour mes clients....
Dis, par hasard.... Tu me prendrais pas pour un con ?
Parce que si c'était ça, alors je pourrais devenir méchant !
Ça c'est de la théorie. La pratique (et je pense que tu n'as pas dû pratiquer souvent !) montre que c'est bien plus courant que cela. Comme je suis en congrès chez Microsoft à Redmond (MVP Summit 2015) - 3000 participants - j'ai posé la question à mon proche entourage à l'instant et la réponse est unanime... tous ont eu un client qui a effacé des tables un jour ou l'autre. J'ai moi même vu cela à deux reprises...
Ce que tu me décris n'est qu'une mauvaise pratique qu'il faut interdire ! Quand on est en production, on ne vient jamais bidouiller sur les bases de données.
Ça c'est encore la théorie.... Quand il y a urgence à rectifier sur un site Web sinon on perd du fric.... Ça se passe en direct... !Si tu as des tests à faire, tu dupliques ce site, par un backup qui ne pénalise en aucune façon l’accessibilité des bases de la production.
Ainsi, avec ce site dupliqué, tu es seul à travailler et si cela t'amuse à droper une table, tu seras le seul à en être pénalisée.
Si tu dois intervenir en production pour corriger un bug, tu dois le faire par l'intermédiaire d'un script qui aura été mis au point sur ton site de test.
Dans le creux de la journée, tu peux rendre ton site indisponible durant cette correction, à la condition que cela prend peu de temps.
Personnellement j'étais là en tant que chef de projet quand nous avons eu un gros plantage sur le site ooshop en 2000... Bref, 3 h d'indispo à rectifier la chose avec remontage de la sauvegarde....N'importe quoi...
Si le temps nécessaire à cette correction est beaucoup trop long, la solution consistant à recopier la nouvelle base de données vers le second disque qui est en mirroring.
On a tous beaucoup rigolé à la lecture de cette dernière phrase prouvant la bétise de tes propos.
Pour ce faire, il faut rendre indisponible le second disque durant cette manœuvre, puis remettre en activité le mirroring après la manœuvre, en indiquant que le premier disque est le clone du second.
Ce basculement dure très peu de temps, et ne nécessite même pas l'arrêt du serveur.
On peut toujours envisager le pire, comme le fait skuatamad :
Mais dans ce cas là, il n'existe aucune solution possible !
Oui, je suis au courant de cette pratique exigée par le fisc. On fait aussi un backup de la base de données au 31 décembre.
Et si des experts comptables, sur la demande du fisc, ont besoin de vérifier quelque chose, on crée un site de test par restauration de ce backup.
Le problème est que tu mélanges deux notions différentes :
--> la tolérance de panne afin d'avoir une disponibilité physique du matériel en continue.
--> le backup qui sert à dupliquer une base de données et dont on se sert pour recréer un site en vue de faire des tests.
Et s'il te plait, arrête de parler de sauvegardes car tu crées la confusion avec le backup.
Pour ton information, le terme BACKUP est un mot anglais dont la traduction est sauvegarde !
J'en pisse encore de rire !
Il est vrai que Arthemus était le rigolo du duo des "Mystères de l'ouest" !!!!
Allez vas y, mets moi un '-1' puisque je viens de te contredire !
@+
A +
Partager