C'est la même chose, Galera est une surcouche à MySQL/MariaDB.
Le 20 janvier 2015 13:30, <fr...@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 <frede...@de-villamil.com > > <mailto:frede...@de-villamil.com>> a écrit : > > > > > > > > On 20 Jan 2015, at 13:02, Pierre DOLIDON <sn...@sn4ky.net <mailto: > sn...@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
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
