Différences

Ci-dessous, les différences entre deux révisions de la page.

--- wiki:cluster:sql [2018/05/19 02:45]
abracastoral [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'avoir:
-/ De la redondance
-/ 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'idée serait d'en avoir un par noeud de prod' et de configurer
-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'écritures en
-cas de défaillance du disque de spirit (pas de raid).
-=== 2/ _La haute disponibilité_ ===
-Le cluster a aussi des *SQL Nodes*. C'est en quelque sorte des
-"portes d'entrées" pour accéder à la base de donnée. Ils se
-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'internet.
-On peut configurer un système d'IP flottante pour qu'on ait en
-permanance l'accès au serveur MySQL de disponible (même si 3/4
-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/piwik qui font ~100MiB (faut arrêter les pad kebab les
-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 "data" (ndbdata1,2,3,4), des noeuds sql (ndbsql1,2), des noeuds de management (ndbmgmt1).
-Les noeuds SQL sont sur des VMs pour pouvoir un meilleur contrôle sur le réseau (notamment pouvoir faire des IP flottantes/load balancing potentiel)
-Pour gérer le cluster on peut utiliser ndb_mgm qui fait partie du package //mysql-cluster-community-client//. (il est installé sur les noeuds de management)
-  root@ndbmgmt1:~# ndb_mgm
-  -- NDB Cluster -- Management Client --
-  ndb_mgm> show
-  Connected to Management Server at: localhost:1186
-  Cluster Configuration
-  ---------------------
-  [ndbd(NDB)]	4 node(s)
-  id=1	@192.168.102.38  (mysql-5.7.18 ndb-7.6.2, Nodegroup: 0, *)
-  id=2	@192.168.102.44  (mysql-5.7.18 ndb-7.6.2, Nodegroup: 0)
-  [...]
-Il ne faut pas oublier d'éditer /etc/my.cnf pour dire aux différents noeuds qui sont ceux de management.
-=== 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
-</WRAP>
-Pour lancer __après une modification du fichier config.init__ les processus de management il suffit de faire
-  ndb_mgmd --initial -f /usr/mysql-cluster/config.ini
-Sinon dans la plupart des cas vous pouvez utiliser le service **ndb_mgmd**
-Vous l'aurez compris le fichier de conf du cluster est dans //config.ini//
-=== Le stockage ===
-Sur ndbdata1,2,3,4 il faut lancer les processus (ndbd) en lançant le service **ndbd**
-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'accès ===
-Sur les noeuds d'accès (ndbsql1,2), il suffit de lancer le service mysql pour qu'il rejoignent le cluster.
-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'assure qu'il y ait toujours une machine qui ait l'IP 192.168.102.52.
-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 > /proc/sys/net/ipv4/ip_nonlocal_bind
-ou ajouter dans /etc/sysctl.conf:
-  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://dev.mysql.com/doc/refman/5.7/en/mysql-cluster-privilege-distribution.html]])
-</WRAP>
-===En cas de problème===
-==Le cluster n'arrive plus à redémarrer==
-Si le cluster n'a pas été éteint proprement, pour le redémarrer, il faut :
-  * Tout d'abord, redémarrer au moins un ndbmgmt. En effet, celui-ci gère les entrées et sorties des noeuds ndb dans le cluster.
-  * 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 /usr/mysql_cluster/. Il est très probable que l'un des noeuds ne veuille pas se lancer avec une erreur du genre INTERNAL_ERROR. Si on est certain que ce noeud n'est pas le seul à contenir la version la plus mise à jour de la base de données, alors on peut dire alors dire au cluster de redémarrer sans l'attendre. Pour cela, démarrer les __autres__ ndbdata avec la commande //ndbd --nowait-node X// avec X le numéro du noeud que l'on souhaite ne pas attendre.
-  * 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).

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page