Ci-dessous, les différences entre deux révisions de la page.
wiki:cluster:sql [2018/06/20 15:16] insolentbacon [En cas de problème] |
wiki:cluster:sql [2020/06/27 18:16] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | ====== Cluster NDB (MySQL) ====== | ||
- | |||
- | ==== Introduction ==== | ||
- | |||
- | On a un cluster MySQL (appelé NDB cluster) qui nous permet d' | ||
- | 1/ De la redondance | ||
- | 2/ De la "haute disponibilité" | ||
- | |||
- | |||
- | === 1/ La redondance === | ||
- | |||
- | |||
- | Un NDB cluster est consisté de *Data Nodes*, noeuds qui | ||
- | permettent de stocker les tables et databases MySQL. De même, les | ||
- | utilisateurs et privilèges sont partagés entre tous les noeuds. | ||
- | |||
- | L' | ||
- | le cluster pour qu'il y ait autant de copies de la BDD que de | ||
- | noeuds de prod. On aurait donc une sauvegarde de notre BDD sur | ||
- | chaque noeud. | ||
- | |||
- | Ça ne remplacera bien évidemment pas les backups réguliers mais | ||
- | ça permettera de ne pas perdre toute une journée d' | ||
- | cas de défaillance du disque d'un noeud de prod. (à l' | ||
- | |||
- | === 2/ _La haute disponibilité_ === | ||
- | |||
- | Le cluster a aussi des *SQL Nodes*. C'est en quelque sorte des | ||
- | " | ||
- | comportent comme des serveurs MySQL qui vont aller interroger | ||
- | les *Data Nodes*. | ||
- | |||
- | Le SQL est critique à MiNET... sans lui pas de radius, donc pas | ||
- | de DHCP donc pas d' | ||
- | On peut configurer un système d'IP flottante pour qu'on ait en | ||
- | permanance l' | ||
- | des noeuds sont shutdown.) | ||
- | |||
- | |||
- | === 3/ Que foutre sur ce cluster ? === | ||
- | |||
- | Il faut savoir que chaque noeud de NDB consomme à peu près | ||
- | autant de RAM que la taille de la BDD qu'il traîte (si on fait 1 | ||
- | réplication par noeud). | ||
- | |||
- | Je pense qu'il n'est donc pas jusdicieux de mettre toutes les | ||
- | tables qu'on a actuellement sur le SQL. | ||
- | |||
- | Genre ostickets, base de donnée qui fait 0.5GiB, redondé en HA, | ||
- | je suis pas sûr que ça soit judicieux. Pareil pour | ||
- | etherpad/ | ||
- | gars). | ||
- | |||
- | Je propose donc de juste mettre la BDD adh5-prod qui fait | ||
- | ~200MiB sur tous les noeuds. | ||
- | En allouant 512MiB de mémoire pour chaque VM *Data Node* sur | ||
- | chaque noeud de prod' on est large. | ||
- | |||
- | Sachant qu'on a à peu près 150MiB de logs dedans qu'on pourrait | ||
- | élaguer un peu, je suis sûr qu'on peut stocker juste 100MiB | ||
- | d'ADH5 sur le cluster. | ||
- | |||
- | ==== La partie technique ==== | ||
- | |||
- | Le cluster est constitué de trois types de machines. | ||
- | Des noeuds de " | ||
- | Les noeuds SQL sont sur des VMs pour pouvoir un meilleur contrôle sur le réseau (notamment pouvoir faire des IP flottantes/ | ||
- | |||
- | |||
- | Pour gérer le cluster on peut utiliser ndb_mgm qui fait partie du package // | ||
- | |||
- | root@ndbmgmt1: | ||
- | -- NDB Cluster -- Management Client -- | ||
- | ndb_mgm> show | ||
- | Connected to Management Server at: localhost: | ||
- | Cluster Configuration | ||
- | --------------------- | ||
- | [ndbd(NDB)] 4 node(s) | ||
- | id=1 @192.168.102.38 | ||
- | id=2 @192.168.102.44 | ||
- | | ||
- | [...] | ||
- | | ||
- | | ||
- | Il ne faut pas oublier d' | ||
- | |||
- | === Le management === | ||
- | |||
- | <WRAP center round info 60%> | ||
- | Attention, le cluster n'a pas __besoin__ des noeuds de management pour tourner. Ils permettent juste de gérer le split brain et de lancer des autres noeuds | ||
- | </ | ||
- | |||
- | Pour lancer __après une modification du fichier config.init__ les processus de management il suffit de faire | ||
- | ndb_mgmd --initial -f / | ||
- | Sinon dans la plupart des cas vous pouvez utiliser le service **ndb_mgmd** | ||
- | | ||
- | Vous l' | ||
- | |||
- | === Le stockage === | ||
- | Sur ndbdata1, | ||
- | |||
- | Les noeuds utilisent 0.75GiB de RAM pour stocker les relations. Ne vous alarmez pas si vous voyez qu'ils utilisent 100% de la RAM du container, c'est normal. (Et même, si vous voulez vous amuser, vous pouvez augmenter la RAM du container et vous rendre compte qu'il utilisera quand même 100% de la RAM) | ||
- | |||
- | === Les noeuds d' | ||
- | Sur les noeuds d' | ||
- | |||
- | Leur disponibilité est cruciale. C'est pour ça qu'il y a un système d'IP virtuelle, mis en place grâce à keepalived qui s' | ||
- | |||
- | Pour permettre à MySQL de listen sur l'IP 192.168.102.52 même sur les machines qui n'ont pas cette ip, il faut juste faire: | ||
- | |||
- | echo 1 > / | ||
- | |||
- | ou ajouter dans / | ||
- | |||
- | net.ipv4.ip_nonlocal_bind = 1 | ||
- | |||
- | |||
- | <WRAP center round alert 60%> | ||
- | Attention ! Dans le cas où tous les noeuds seraient down, si vous les relancez tous avec comme option --initial, la table des privilèges MySQL sera perdue ! (voir [[https:// | ||
- | </ | ||
- | |||
- | ===En cas de problème=== | ||
- | |||
- | ==Le cluster n' | ||
- | Si le cluster n'a pas été éteint proprement, pour le redémarrer, | ||
- | |||
- | * Tout d' | ||
- | * **Si vous ne pouvez pas redémarrer tous les ndb_mgmd du cluster**, il va falloir lancer ceux que vous pouvez lancer en spécifiant l' | ||
- | > / | ||
- | |||
- | * Redémarrer __tous__ les ndbdata car le cluster ne redémarrera pas tant qu'il n'est pas sûr qu'il a bien la dernière version de la base de données. | ||
- | |||
- | *Si les ndbdata ne redémarrent pas: allez sur ndbmgmt et consultez les logs dans / | ||
- | |||
- | * Enfin, redémarrer au moins un ndbsql (note: les services sql sembleront down si les ndbdata ne sont pas up, c'est normal, il ne faut pas essayer de le redémarrer en boucle). | ||