Serveurs MySQL, binlog, DRBD et perfs IO
Bonjour la liste, 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 :) Mais cette fois je voudrais que ça tienne avec la bonne config : sync_binlog=1 innodb_flush_log_at_trx_commit=1 et le protocole C de DRBD. Les serveurs actuels sont équipés de RAID10 6 disques SAS @15krpm et carte raid avec 512Mo de cache. Pour les remplacer, j'hésite entre 2 configs : - 2 RAID10 SAS : 1 pour les datas, 1 pour les binlogs - 1 RAID1 SAS pour les datas, 1 RAID1 SSD pour les binlogs (ou l'inverse...) C'est l'occasion d'utiliser du SSD en production, mais pour l'instant les tests que j'ai pu faire avec du SSD cheap ne sont pas concluants du tout. Avec du pro ça devrait être mieux mais je n'ai pas pu tester. Qu'en pensez vous ? -- Greg
Bonjour, Le 05/08/2013 10:10, Greg a écrit :
Bonjour la liste,
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 ? Julien
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
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 <olc@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
J'ai aussi rencontré ce problème pour une config Zarafa (messagerie avec backend MySQL). Le 05/08/2013 11:30, Greg a écrit :
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 ;)
J'avais aussi abandonné DRBD à l'époque pour du RAID logiciel entre deux LUN de notre SAN, mais le problème était toujours là... Au final, avec accord des décideurs, j'ai abandonné l'ACID, avec : innodb_flush_log_at_trx_commit=2 Ça a suffit à rendre très convenable les perfs, mais avec un risque de perdre 1 seconde de données commitées... Je n'ai jamais pu essayer de SSD avec MySQL, mais je serais intéressé du résultat, notamment de savoir s'ils sont plus utiles sur les binlog ou sur les datas. Évidement, je suis conscient que ça dépend de l'utilisation de la base (gros inserts = écriture sequentielle, pleins de petits updates ou inserts = écriture aléatoire, ou pas d'ailleurs, dans les logs...) J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer...
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à !
J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer... [...]
Pourquoi ne pas utiliser du MariaDB Galera Cluster pour du multimaster ? My 2cts... Le 05/08/2013 16:40, Gilles Mocellin a écrit :
J'ai aussi rencontré ce problème pour une config Zarafa (messagerie avec backend MySQL).
Le 05/08/2013 11:30, Greg a écrit :
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 ;)
J'avais aussi abandonné DRBD à l'époque pour du RAID logiciel entre deux LUN de notre SAN, mais le problème était toujours là...
Au final, avec accord des décideurs, j'ai abandonné l'ACID, avec : innodb_flush_log_at_trx_commit=2
Ça a suffit à rendre très convenable les perfs, mais avec un risque de perdre 1 seconde de données commitées...
Je n'ai jamais pu essayer de SSD avec MySQL, mais je serais intéressé du résultat, notamment de savoir s'ils sont plus utiles sur les binlog ou sur les datas. Évidement, je suis conscient que ça dépend de l'utilisation de la base (gros inserts = écriture sequentielle, pleins de petits updates ou inserts = écriture aléatoire, ou pas d'ailleurs, dans les logs...)
J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer...
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à !
J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer...
[...]
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 07/08/2013 19:01, Tristan Mahé a écrit :
Pourquoi ne pas utiliser du MariaDB Galera Cluster pour du multimaster ?
My 2cts...
C'est sur que ça fait partie des choses qu'il faut que je regarde de près. A l'époque, ça remonte à 3/4 ans, je ne connaissais pas MariaDB/Galera, et je ne sais même pas si ça existait. Cela dit, quand on ne maitrise pas l'application, il y a toujours des risques que certaines interactions avec la base ne se fasse pas comme il faut avec Galera. Notamment, lors de mises à jour où il y aurait des commandes de création, mise à jour de structures de tables. Il faut vraiment bien tout tester avant de se lancer. [...]
Hello, On 08/08/13 10:33, Gilles Mocellin wrote:
Le 07/08/2013 19:01, Tristan Mahé a écrit :
Pourquoi ne pas utiliser du MariaDB Galera Cluster pour du multimaster ?
My 2cts...
C'est sur que ça fait partie des choses qu'il faut que je regarde de près. A l'époque, ça remonte à 3/4 ans, je ne connaissais pas MariaDB/Galera, et je ne sais même pas si ça existait.
Cela dit, quand on ne maitrise pas l'application, il y a toujours des risques que certaines interactions avec la base ne se fasse pas comme il faut avec Galera.
Oui, bien vérifier les limitations. Genre l'absence de query_cache (qu'il est possible de forcer mais ce n'est officiellement pas supporté).
Notamment, lors de mises à jour où il y aurait des commandes de création, mise à jour de structures de tables. Il faut vraiment bien tout tester avant de se lancer.
Voilà. :) Cela dit, c'est une solution plutôt intéressante pour du (vrai) multimaster. -- Olivier
Bonjour, j'ai commandé ces 2 serveurs, avec cette config : RAID1 composé de 2 disques SAS 15krpm 300GB RAID1 composé de 2 SSD 200GB Je ferais les tests pour vous informer de ce qui va le mieux au niveau des perfs, tout en étant ACID. Greg Le 5 août 2013 16:40, Gilles Mocellin <gilles.mocellin@nuagelibre.org> a écrit :
J'ai aussi rencontré ce problème pour une config Zarafa (messagerie avec backend MySQL).
Le 05/08/2013 11:30, Greg a écrit :
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 ;)
J'avais aussi abandonné DRBD à l'époque pour du RAID logiciel entre deux LUN de notre SAN, mais le problème était toujours là...
Au final, avec accord des décideurs, j'ai abandonné l'ACID, avec : innodb_flush_log_at_trx_**commit=2
Ça a suffit à rendre très convenable les perfs, mais avec un risque de perdre 1 seconde de données commitées...
Je n'ai jamais pu essayer de SSD avec MySQL, mais je serais intéressé du résultat, notamment de savoir s'ils sont plus utiles sur les binlog ou sur les datas. Évidement, je suis conscient que ça dépend de l'utilisation de la base (gros inserts = écriture sequentielle, pleins de petits updates ou inserts = écriture aléatoire, ou pas d'ailleurs, dans les logs...)
J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer...
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à !
J'aimerais aussi bien savoir comment se débrouille postgreSQL dans la même configuration. Si quelqu'un a déjà pu comparer...
[...]
______________________________**_________________ Liste de diffusion du FRsAG http://www.frsag.org/
2013/8/5 Julien Escario <escario@azylog.net>:
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 ?
A priori non, ou alors tu fais de la réplication cross datacenter (est-ce le cas ici ?). Un disque SATA c'est ~10ms pour faire un seek, tu tombes à <1ms de round-trip en interne à un DC en général. -- Jérémie MARGUERIE
hello, on a beaucoup parlé io hardware et conf mysql, y a peut être aussi la partie File System qui a son importance.. non ?? tchuss 2013/8/5 Greg <greg-frsag@duchatelet.net>
Bonjour la liste,
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 :)
Mais cette fois je voudrais que ça tienne avec la bonne config :
sync_binlog=1 innodb_flush_log_at_trx_commit=1
et le protocole C de DRBD. Les serveurs actuels sont équipés de RAID10 6 disques SAS @15krpm et carte raid avec 512Mo de cache.
Pour les remplacer, j'hésite entre 2 configs : - 2 RAID10 SAS : 1 pour les datas, 1 pour les binlogs - 1 RAID1 SAS pour les datas, 1 RAID1 SSD pour les binlogs (ou l'inverse...)
C'est l'occasion d'utiliser du SSD en production, mais pour l'instant les tests que j'ai pu faire avec du SSD cheap ne sont pas concluants du tout. Avec du pro ça devrait être mieux mais je n'ai pas pu tester.
Qu'en pensez vous ? -- Greg
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (7)
-
Gilles Mocellin -
Greg -
Julien Escario -
Jérémie Marguerie -
noway private -
Olivier -
Tristan Mahé