C'est une config full actif / full passif, donc il n'y a aucun risque, si les options MySQL précités dans le 1er mail sont bien activées, mais c'est valable pour n'importe quel moyen de HA.
Le principal défaut de ce mode, c'est le temps de démarrage à froid de l'instance MySQL de secours, mais il a d'autres avantages... J'ai monté une archi de tests sans DRBD et rencontre les mêmes problèmes à savoir le nombre d'IOPS avec ces options MySQL, obligatoire pour être ACID entre parenthèses. Mon problème ne vient pas de DRBD ;) Certaines versions récentes de MariaDB et MySQL proposent le Binlog Group Commit qui permet de baisser les IO, il faut peut-être que je regarde de ce coté là ! Le 5 août 2013 10:43, Olivier <o...@glou.fr> a écrit : > Hello, > > > On 05/08/13 10:22, Julien Escario wrote: > >> je dois remplacer 2 serveurs master MySQL redondés par DRBD. A >>> l'époque j'avais du diminuer les écritures en utilisant le protocole B >>> de DRBD, et en baissant le nombre de sync ... heureusement je n'ai >>> jamais eu de bascule foireuse :) >>> >> >> Euh, sans rentrer dans le détail, tu penses que DRBD pour du mysql >> dual-master est une bonne idée ? >> Par définition, il y a une latence réseau supérieur à la latence disque. >> Du coup, tu pourrais te retrouver avec deux écritures simultanées et >> concurrentes non ? >> >> Ou alors, tu n'écris que sur un seul MySQL et l'autre est en lecture >> seule ... Mais dans ce cas, pourquoi ne pas utiliser le système de >> réplication intégré de MySQL avec les logs binaires ? >> > > La réplication ne garantit pas d'avoir les mêmes données sur chacun des > nœuds (c'est du reste l'un des pbs à adresser quand on ne backup que les > réplicats pour ne pas avoir à stopper le master). > > Cela dit, entre 2 nœuds DRBD actif/actif (avec un OCFS2 ou équivalent) et > deux mysql en réplication circulaire avec une VIP, je n'hésiterais pas une > seconde et choisirais la deuxième solution. Les DSI n'aiment généralement > pas trop l'actif/passif (sentiment de mal utiliser les budgets) mais c'est > une fausse bonne idée de croire que le setup sera plus performant en > actif/actif : les mécanismes de lock d'un FS cluster entrainent trop de > latence. > > Niveau perfs, je partage le point de vue de Julien : DRBD va tuer les > perfs en écritures, et utiliser des disques SSD n'y changera rien. > > Concernant les SSD, je suis assez content des Intel DC s3700 que j'utilise > en cache de FS (sur un master/slave NFS+DRBD). > > -- > Olivier > > > ______________________________**_________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
