Choix BDD pour réplication

[poumon]

Bonjour
Nous souhaitons modifier notre serveur pour un système entièrement redondant.
L'idée est d'avoir 2 serveurs chez des hébergeurs différents et que si 1 des 2 est hs, l'autre prend le relai.
Concernant la réplication de base, mysql semble très contraignant.
Quelle serait selon vous le meilleur choix en bdd?

Merci d'avance

[StringBuilder]

Bonjour,

Je doute un peu que la contrainte de la réplication soit la seule contrainte que vous ayez sur votre système, pas plus que ce soit la plus importante.

Il nous faudrait donc plus d'informations sur ce qui vous a conduit jusqu'à présent à retenir MySQL par exemple.

Microsoft SQL Server et Oracle disposent d'outils pour répliquer les données, de façon synchrone, avec ou sans load balancing.

Selon les éditions (à des prix très différents), toutes les fonctionalités ne sont pas disponibles.

Je doute que ce soient les seuls SGBD à proposer ce genre de fonctions.

Il faut garder en tête aussi que :
- La "réplication" est un mot vague qui contient un peu tout et n'importe quoi. Recopier un DUMP de la base toutes les nuit, c'est autant de la réplication que d'avoir un service de load balancing qui fait du mirroring en temps réel.

Les diverses solutions ont des avantages et des inconvénients.

Il faut savoir que tout ce qui est "temps réel" aura un impact sur la vitesse de votre système : si vous avez trop de mouvements, alors la base sera ralentie, car la bande passante entre les deux serveurs ne suivra pas (puisque vous comptez prendre deux hébergeurs).

Outre les capacités des SGBD à faire de la réplication/sauvegarde à chaud, etc., des outils permettent de faire la même chose au niveau FS. Ceci a pour avantage de mettre à jour aussi la configuration logicielle, pas seulement les données. Dans le cadre d'une procédure de reprise après incident, c'est même plutôt conseillé : le serveur repart à l'identique d'un point de vue logiciel. Les données, mais aussi les statistiques, les logs, les correctifs, tout est à jour.

Bref, votre demande est trop vague, et le manque de réponse semble venir de là : il y a énormément de solutions envisageables, qui permettent tout à fait de conserver MySQL si ce SGBD est celui qu'il vous faut.

[Jester]

Je viens juste d'avoir cela dans mes flux, c'est une conférence sur le sujet de la disponibilité (MySQL uniquement) :

Keep your MySQL backend online no matter what

As a real world example I will demonstrate how this solution was applied for a payment processor website behind an alexa top50 website, where data consistency was important. In addition I will show an example for another alexa top 500 website, where downtime and customer satisfactory was the numer 1 priority.

On peut donc dire que MySQL doit pouvoir gérer vos besoin.

[SQLpro]

Pour une vue de synthèses des concepts sous SQL Server qui offre de multiples manière d'effectuer cela : http://sqlpro.developpez.com/cours/s...disponibilite/
Cela vous donnera des idées quelques soit le SGBDR choisit.

A +

[Waldar]

Envoyé par Jester

On peut donc dire que MySQL doit pouvoir gérer vos besoin.

Extrait :

This architecture is built on MMM, HeartBeat, LVS, ldirectord and some custom scripts.

[SQLpro]

J'aime toujours beaucoup les commentaires de Jester !!!

A +

[Jester]

Il faut bien un bouffon pour divertir le roi.

Waldar > Ca n'en reste pas moins une solution vu que les autres logiciels de cette solution sont standard? Vu le coût de changer d'infrastructure, il peut être préférable de réfléchir un peu avant pour voir si on ne pas juste la mettre jour.

[SQLpro]

Sauf que par exemple avec SQL Server il n'y a besoin de rien d'autres que SQL Server pour faire une solution de haute dispo, même avec des distances gigantesques via http.

Lisez par exemple le script de mise en œuvre d'un mirroring de bases de données sous SQL Server pour vous convaincre que l'on a besoin de rien et pas de 36 modules abscons du genre de MMM, HeartBeat, LVS, ldirectord... et j'en passe !
http://blog.developpez.com/sqlpro/p7...-base-de-donn/

Et pour les idiots qui ne savent même pas copier une ligne de script SQL, Microsoft à penser pour eux en fournissant un assistant de mise en œuvre du mirroring !
http://www.developpez.net/forums/att...1&d=1318287949

Bref, quelqu'un qui sait utiliser une souris y arrive !

A +

[StringBuilder]

Même si c'est limite hors sujet, je maintiens qu'en terme de mirroring, il existe aussi des solutions basées sur des snapshot de la FS, qui permettent de passer n'importe quel SGBD ou application en mode mirroring, en utilisant toujours le même outils.

Et cela a pour avantage de ne nécessiter l'administration que d'un serveur serveur, l'autre étant la réplique exacte du premier, logiciels compris.

Ceci peut donc être une piste sérieuse pour les personnes qui utilisent un SGBD qui ne dispose pas de ce genre de fonctionnalités.

A noter aussi que ce genre d'outils (Symantec en fait un) proposent aussi des outils pour faire la bascule automatiquement d'un serveur à l'autre, ou de toute une ferme de serveurs à l'autre, ce qui peut être intéressant en cas de gros pépin (infrastructure réseau touchée par exemple).

[Waldar]

Envoyé par Jester

Waldar > Ca n'en reste pas moins une solution vu que les autres logiciels de cette solution sont standard? Vu le coût de changer d'infrastructure, il peut être préférable de réfléchir un peu avant pour voir si on ne pas juste la mettre jour.

Attention, je ne remets pas en cause l'efficacité de la solution de haute dispo pour MySQL - l'auteur a l'air de savoir de quoi il parle - je mets juste en avant qu'il faut peut-être acheter, appréhender et maîtriser une pléthore d'outils hors MySQL.

[SQLpro]

Envoyé par StringBuilder

Même si c'est limite hors sujet, je maintiens qu'en terme de mirroring, il existe aussi des solutions basées sur des snapshot de la FS, qui permettent de passer n'importe quel SGBD ou application en mode mirroring, en utilisant toujours le même outils.

Et cela a pour avantage de ne nécessiter l'administration que d'un serveur serveur, l'autre étant la réplique exacte du premier, logiciels compris.

Ceci peut donc être une piste sérieuse pour les personnes qui utilisent un SGBD qui ne dispose pas de ce genre de fonctionnalités.

A noter aussi que ce genre d'outils (Symantec en fait un) proposent aussi des outils pour faire la bascule automatiquement d'un serveur à l'autre, ou de toute une ferme de serveurs à l'autre, ce qui peut être intéressant en cas de gros pépin (infrastructure réseau touchée par exemple).

Sauf que cela ne marche ABSOLUMENT PAS !
En effet aucun de ces logiciel ne garantira la reprise correcte d'un SGBDR. Par exemple les snapshot des VM de VMWare comme de Hyper V ne sont pas garantis sauf à "arrêter" le service des données en intimant au serveur de le faire (et donc, si la chose n'est pas prévue, la perte des mise en cahce...). En effet le snapshot des fichiers consiste à copier des fichiers... mais un SGBDR écrit de manière asynchrone et non ordonné des données dans différents fichier (au moins deux : journal des transactions + données des tables). Ce qui fait qu'en cas de copie successive des fichiers (comme c'est le cas d'un snapshot) vous arriverez tôt ou tard au fait que les fichiers ne seront plus synchrone et la base sera considérée comme corrompue....

A lire :
http://community.obilogic.co.uk/blog...-snapshot.aspx
http://communities.vmware.com/thread/123564
http://software.ivertech.com/_iverte...dSnapshots.htm

Seul un mécanisme INTERNE au SGBDR ou bien l'arrêt du SGBDR peut garantir une telle solution de haute dispo.
Or arrêter un serveur pour gérer une solution de haute dispo me parait totalement débile, puisque la haute dispo vise à ce que le serveur ne s'arrête jamais !!!

A +

[Jester]

Oui c'est évident que ce n'est pas une méthode facile (les outils sont gratuits par contre) et qu'il faut y réfléchir à 2 fois. Il peut être utile de faire une migration vers une base de données plus avancée. De même que je ne doutes pas que SQL Server soit parmi les plus simples.

[StringBuilder]

Envoyé par SQLpro

Sauf que cela ne marche ABSOLUMENT PAS !

Es-tu bien sûr de cela ?

En effet, lors de la mise en place chez un client de l'outils de Symantec (pas Backup Exec, l'autre, la grosse version) il était bien stipulé que c'était compatible Oracle et SQL Server, et un assistant demandait justement où se situait l'installation et les fichiers de ces deux SGBD, justement, j'imagine, pour être capable de surveiller convenablement les écritures des fichiers de log et transaction (pour Oracle, il y a aussi un fichier à la con qui bloque tout s'il n'est pas synchro avec la base, je ne me souviens plus duquel).

Par contre, je parle d'un outils "physique", pas d'un plugin pourri sur une VM, mais bel et bien sur un serveur physique.

[SQLpro]

NON, aucun des fabricants de ce genre de chose ne peut garantir la reprise de la base...

La plupart des gens qui font de l'admin système et qui en général ne connaisse rien au métier de DBA tombent dans le panneau.. En ce moment j'ai comme client une grosse banque qui est victime de cela...

A lire :
http://support.microsoft.com/kb/956893/en-us

"Q6: What is the support policy for SQL Server when using a SVVP vendor virtualization feature such as snapshots or migration?

A6: Snapshots for any virtualization vendor are not supported with SQL Server. Any other virtualization additional functionality of a SVVP vendor such as migration must be supported by the SVVP vendor. This includes any problems that might occur with SQL Server when using these features. Please read this resource for more information about the support policy for additional functionality of a virtualization product:
http://www.windowsservercatalog.com/...vvpsupport.htm) "

Même chose pour Oracle et toutes les bases de données qui ont un journal de transaction....

A +

[StringBuilder]

D'accord, j'insiste pas, pas taper

[fadace]

Les providers de stockage commencent cependant à livrer des solutions interfacées avec les bases afin de tirer le meilleur parti des 2 technologies

Exemple : http://www.netapp.com/fr/solutions/a...covery-fr.html

Il faut en effet que les checkpoints et la sauvegarde binaire soient synchrones sans quoi le risque de corruption est, comme l'a dit Frédéric, quasi certain.

[mikedavem]

Netapp, IPStore, EMC et compagnie permettent de répliquer les bases de données au niveau FS sans trop de problème maintenant.

On peut passer soit en réplication synchrone bloc à bloc soit en asynchrone avec l'utilisation des snapshots par exemple.

Les snapshots (Je précise au niveau du storage) par exemple effectuent un freeze des IO sur les fichiers SQL Server (mdf, ndf, ldf ...) ce qui garantit une cohérence des fichiers à un instant T. Il y a bien sûr certains inconvénients comme la performance (surtout si la création du snapshot prend du temps et que les IO s'empilent dans la file d'attente prévue à cet effet) ou la perte potentielle de données si le serveur tombe pendant le snapshot (Les IO en attente seront perdus).

La réplication FS est beaucoup utilisée avec les serveurs de bases de donnés dans les topologies GEO CLUSTER par exemple.

++

[poumon]

à tous pour vos précieuses réponses.

[nelem75]

Bonjour,

Il est clair qu'Informix (IBM) n'a pas d'équivalent sur le marché en ce qui concerne les différents types de réplication et cela en prenant en compte l'architecture Mach11 en plus de qui était déjà présent depuis les débuts du moteur IDS (Informix Dynamic Server) : HDR et ER. Sans compter la facilité de mise en place...

Un redbook complet sur le sujet à télécharger sur cette page:

http://www.redbooks.ibm.com/abstracts/sg247488.html


Hope this help.

[nelem75]

Bonjour,

Suite à mon message précédent, voici un autre redbook récent et très complet sur la réplication standard avec Informix et surtout les possibilités de réplication Mach11.

http://www.redbooks.ibm.com/abstracts/sg247937.html


Hope this help.