[FRsAG] Fonctions Haute Disponibilité et PRA sur les solutions de Bdd

Greg greg-frsag at duchatelet.net
Mar 20 Jan 13:33:01 CET 2015


C'est la même chose, Galera est une surcouche à MySQL/MariaDB.


Le 20 janvier 2015 13:30, <frsag at jack.fr.eu.org> a écrit :

> Quand vous parlez de mysql galera : est-ce que quelqu'un a de
> l'expérience concernant Mariadb Galera ?
>
> On 20/01/2015 13:25, Greg wrote:
> > Bonjour,
> >
> > je plussois les propos de Frédéric concernant MySQL, Galera cluster est
> > vraiment galère en conditions réels.
> > Par contre, une réplication simple sur le moteur InnoDB fonctionne juste
> > à merveille, et encore mieux avec les GTIDs (MariaDB 10 et MySQL 5.6).
> > Des scripts comme MHA (1) fonctionnent parfaitement tant qu'il n'y a pas
> > de réplication en cascade (master --> master/slave ---> slaves). Evites
> > MyISAM.
> > MHA te permet une bascule d'un ensemble master-slaves en moins d'une
> > minute, automatique ou à la demande.
> >
> > En solution confort (et donc €€) tu trouveras MySQL Cluster qui n'a rien
> > à voir avec MySQL mais qui est la solution number one si tu as le budget
> > ET si tes données tiennent toutes en RAM. Donc à oublier si ce sont les
> > mêmes données que pour Frédéric qui parle de tera-octets.
> >
> > Au cas où, la config qui va bien sur un master MySQL:
> >
> > innodb_flush_log_at_trx_commit  = 1
> > sync_binlog                     = 1
> >
> >
> > et la config pour un slave MySQL qui n'a pas les GTIDs (si la réplic est
> > en GTID, tu peux laisser les valeurs par défaut) :
> >
> > relay_log_recovery          = ON
> > sync_relay_log              = 1
> > sync_relay_log_info         = 1
> > sync_master_info            = 1
> >
> >
> > Je suis en plein dedans et c'est ce qui explique que je suis en train de
> > mettre à jour 10 masters et 30 slaves en MariaDB 10.0.
> >
> >
> > Greg
> >
> >
> > Le 20 janvier 2015 13:14, Frederic de Villamil <frederic at de-villamil.com
> > <mailto:frederic at de-villamil.com>> a écrit :
> >
> >     >
> >     > On 20 Jan 2015, at 13:02, Pierre DOLIDON <sn4ky at sn4ky.net <mailto:
> sn4ky at sn4ky.net>> wrote:
> >     >
> >     > En ce qui concerne du mysql-like, regarde du côté de galera
> cluster.
> >     >
> >     > Sinon, tu peux envisager une réplication mysql master-master, et
> faire pointer les appli sur une IP gérée par un keepalived ou quelque chose
> comme ça.
> >     >
> >     > évidemment, il faut supervision l'ensemble et vérifier que les
> synchros sont opérationnelles entre les 2 mysql.
> >
> >     Bonjour,
> >
> >     Je vais répondre pour MySQL.
> >
> >     Concernant Galera, j’en ai 3 clusters en prod dont un de 1T et un de
> >     18T (une seule base à chaque fois) et la solution porte
> >     particulièrement bien son nom. Le seul intérêt est la réplication
> >     synchrone et l’écriture sur n’importe quel node si tu en as vraiment
> >     besoin, pour tout le reste, c’est une horreur.
> >
> >     Concernant la réplication master / master, ce n’est pas forcément
> >     une idée géniale parce que ça appuie pas mal sur les I/O et tout le
> >     monde ne peut pas mettre 20T en SSD sur ses machines.
> >
> >     J’ai en revanche pas mal d’expérience avec de la réplication master
> >     / slave multi site, VIP et fail over automatique. Le truc est de
> >     trigger un script qui effectue un reset sur le slave pour le
> >     transformer en master quand la bascule se fait. Ça marche (bien), et
> >     j’ai tenu 6 ans avec ça (et des trucs bien plus exotiques, dont du
> >     master / multi slave derrière un haproxy, une IP de lecture, une
> >     d’écriture, retrait du pool dès que le seconds_behind_master > 0 et
> >     un fail over en lecture sur le master). Ça demande un peu de tuning,
> >     mais ça a pas mal d’avantages, le principal étant d’être gratuit.
> >
> >     Une fois encore ton problème en termes de PRA va être le transfert
> >     de données. Le problème n’est pas tant d’expérience la perte d’un
> >     noeud qu’un drop / delete malheureux ou une corruption de données.
> >     Et là, ça devient franchement compliqué d’avoir une GTR courte sur
> >     de gros volumes (on parle, une fois encore, de Tera de données). Et
> >     Xtrabackup est loin d’être parfait pour du backup / restore à chaud
> >     (j’ai perdu 20h y’a pas longtemps parce qu’il n’arrivait pas à
> >     prendre le lock exclusif sur la base qu’il dupliquait).
> >
> >     Mes deux cents,
> >     Fred
> >
> >     --
> >     Frederic de Villamil / @fdevillamil
> >     http://t37.net
> >
> >
> >     _______________________________________________
> >     Liste de diffusion du FRsAG
> >     http://www.frsag.org/
> >
> >
> >
> >
> > --
> > Greg
> >
> >
> > _______________________________________________
> > Liste de diffusion du FRsAG
> > http://www.frsag.org/
> >
>
>
> --
> "UNIX was not designed to stop its users from doing stupid things, as
> that would also stop them from doing clever things." – Doug Gwyn
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
>



-- 
Greg
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20150120/ec766012/attachment-0001.html>


Plus d'informations sur la liste de diffusion FRsAG