Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
wiki:cluster:sql [2017/08/05 11:26] insolentbacon |
wiki:cluster:sql [2018/08/01 17:35] simtrami [En cas de problème] |
||
---|---|---|---|
Ligne 3: | Ligne 3: | ||
==== Introduction ==== | ==== Introduction ==== | ||
- | Actuellement nous avons le SQL (avec MySQL en backend) sur | + | On a un cluster MySQL (appelé NDB cluster) qui nous permet |
- | 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 " | + | |
- | + | ||
- | L' | + | |
- | qui nous permetterait | + | |
1/ De la redondance | 1/ De la redondance | ||
2/ De la "haute disponibilité" | 2/ De la "haute disponibilité" | ||
Ligne 18: | Ligne 12: | ||
Un NDB cluster est consisté de *Data Nodes*, noeuds qui | Un NDB cluster est consisté de *Data Nodes*, noeuds qui | ||
- | permettent de stocker les tables et databases MySQL. | + | permettent de stocker les tables et databases MySQL. De même, les |
+ | utilisateurs et privilèges sont partagés entre tous les noeuds. | ||
L' | L' | ||
Ligne 27: | Ligne 22: | ||
Ça ne remplacera bien évidemment pas les backups réguliers mais | Ça ne remplacera bien évidemment pas les backups réguliers mais | ||
ça permettera de ne pas perdre toute une journée d' | ça permettera de ne pas perdre toute une journée d' | ||
- | cas de défaillance du disque de spirit | + | cas de défaillance du disque |
=== 2/ _La haute disponibilité_ === | === 2/ _La haute disponibilité_ === | ||
Ligne 92: | Ligne 87: | ||
=== Le 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 | + | <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 | Pour lancer __après une modification du fichier config.init__ les processus de management il suffit de faire | ||
Ligne 123: | Ligne 120: | ||
</ | </ | ||
+ | ===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 & ndbmgmd ne sont pas up, c'est normal, il ne faut pas essayer de le redémarrer en boucle). | ||