Différences

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

--- wiki:cluster:sql [2017/06/27 22:40]
insolentbacon
+++ wiki:cluster:sql [2020/06/27 18:16]
@@ Ligne 1: / Ligne 1: @@
-====== Cluster NDB (MySQL) ======
-==== Introduction ====
-Actuellement nous avons le SQL (avec MySQL en backend) sur
-spirit. Il est stocké directement sur le disque en local.
-Des sauvegardes sont faites régulièrement sur les NAS, ils sont
-dump dans un fichier "gité" (mis sur gitlab).
-L'idée serait de faire un cluster MySQL (appelé NDB cluster) ce
-qui nous permetterait 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.
-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)
-Il ne faut pas oublier d'éditer /etc/my.cnf pour dire aux différents noeuds qui sont ceux de management.
-=== Le management ===
-**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 les processus de management il suffit de faire
-  ndb_mgmd --initial -f /usr/mysql-cluster/config.ini
-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 en tapant juste
-  ndbd
-=== 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.

WikiMiNET

Outils pour utilisateurs

Outils du site

Différences

Outils de la page