FAQ Webinar MySQL Group Replication

mars 3, 2017

Mise-à-jour: 7 Mars 2017

Le 1er mars dernier, j’ai présenté lors d’un webinar, la technologie de haute disponibilité MySQL Group Replication. On a explosé notre record d’affluence et j’ai été inondé de questions, preuve s’il en faut de votre intérêt, toujours plus important, pour la base de données Open Source la plus populaire au monde.

Je n’ai malheureusement pas été en mesure de répondre à toutes les questions, ce qui me permet aujourd’hui de les centraliser dans cette FAQ. Cette dernière pourra être mise à jour de temps à autres, en fonctions des questions que je récupérerai du terrain.

En complément de cette FAQ

 


  • Sur quels OS peut on utiliser MySQL Group Replication ?

MySQL Group Replication est un plugin du serveur MySQL. Il est donc présent sur toutes les plateformes où MySQL 5.7 est disponible :

  • Linux
  • Windows
  • Solaris
  • OSX
  • FreeBSD

Liste complete

 

  • Est ce que la feature de multi-master nécessitera un update du driver MySQL ou cela sera vu comme un master « standard » d’un point de vu client ? 

L’architecture classique MySQL Group Replication est la suivante :

Client + MySQL Router      |      MySQL Group Replication

Client      |      ProxySQL      |      MySQL Group Replication

C’est du moins le cas en mode Single Primary car il faut pouvoir identifier le nœud primaire.

Cette architecture est valable également en mode multi-master (ou multi-Primaire), cependant dans ce cas, vu que tout les membres sont master, il suffit simplement que le driver contiennent la liste des membres.

 

  • Est-ce que l’on a une contrainte sur le nombre de nœuds minimum ?

Pas de contraintes par « design ».  Cependant, pour qu’un system distribué puisse fournir du failover automatique, il faut minimum 3 nœuds. Cela permet d’éviter le split brain.

A noter qu’il est possible de mettre en place un cluster MySQL Group Replication avec seulement 2 nœuds. Mais en cas d’arrêt non prévu (crash) d’un des membres, l’autre membre n’acceptera pas de nouvelles requêtes. On se trouve alors dans un cas de Network Partitioning,  et la partition doit être débloquée selon la procedure inscrite dans la doc.

Par contre si l’un des 2 membres est arrêté « gracieusement » (STOP GROUP_REPLICATION;), l’autre continue de fonctionner normalement.

 

  • Dans le cas d’une utilisation multi-master, est-ce que l’on peut ajouter/retirer des nœuds dynamiquement ?

Oui, dans les 2 modes (Single Primary ou multi-master) il est possible d’ajouter et/ou de retirer des nœuds dynamiquement.

 

  • Au sein d’un cluster MySQL Group Replication, l’élection d’un nœud master R/W est-il automatique ou manuel ?
  • Dans le mode Single Primary, lorsque le primaire tombe, comment est choisi le nouveau nœud primaire ?

Le process d’election est automatique et transparent pour le client. Alors pas mal de process se passent « behind the scene » !

Il faut notamment que les autres membres identifient le fait que le nœud ne fasse plus partie du cluster et puis ensuite enclencher le process d’élection du nouveau nœud primaire (le prochain dans la liste ordonnée en fonction de l’UUID de instances du cluster) et aussi désactiver le mode read-only.

Identifier le nœud primaire : https://dev.mysql.com/doc/refman/5.7/en/group-replication-find-primary.html

Exemples:

L’information qui permet de savoir quel nœud est primaire est disponible dans la table performance_schema.global_status :

mysql>
SELECT * 
FROM performance_schema.global_status 
WHERE VARIABLE_NAME='group_replication_primary_member'\G
*************************** 1. row ***************************
VARIABLE_NAME: group_replication_primary_member
VARIABLE_VALUE: 00014115-1111-1111-1111-111111111111

En la joignant avec la table performance_schema.replication_group_members ont obtient un peu plus d’infos:

mysql>
SELECT MEMBER_ID, MEMBER_HOST, MEMBER_STATE
FROM performance_schema.replication_group_members
INNER JOIN performance_schema.global_status ON (MEMBER_ID = VARIABLE_VALUE)
WHERE VARIABLE_NAME='group_replication_primary_member'\G
*************************** 1. row ***************************
MEMBER_ID: 00014115-1111-1111-1111-111111111111
MEMBER_HOST: 192.168.1.11
MEMBER_STATE: ONLINE

 

  • Est-ce que l’on a des limites en terme de taille de base de données pour MySQL Group Replication ?

Le moteur de stockage utilisé avec MySQL Group Replication est InnoDB. Les limites sont donc celles imposées par InnoDB.

 

  • Est-ce que l’on peut utiliser MySQL Router avec une replication asynchrone classique ?

MySQL Router 2.0, peut être utilisé avec MySQL Replication : https://dev.mysql.com/doc/mysql-router/2.0/en/

Le plugin Connection Routing fournit 2 modes de « routage »:

  • Le mode Read-Only : route les requêtes en mode round-robin sur une liste d’instances MySQL.
    => Cela a du sens pour router les requêtes de lectures sur les slaves.
  • Le mode Read-Write : route les requêtes sur le premier serveur de la liste, si celui si n’est plus accessible, les requêtes sont alors routées sur le suivant de la liste et ainsi de suite jusqu’au dernier.
    => Perso, je ne suis pas trop fan de ce mode pour MySQL Replication.

 

  • Sur une configuration multi-master, est il toujours conseillé de mettre en place un offset sur les ID pour chaque node pour éviter les conflits ?

Avec la réplication classique (asynchrone) de MySQL,  pour une architecture multi-master en actif/actif (que je ne conseille toujours pas), il est nécessaire de mettre en place différents offsets pour prévenir les conflits liés aux clés primaire en auto increment (details).

Dans le cas de MySQL Group Replication, ce problème se pose également en mode multi-master. C’est pour cela qu’il est géré automatiquement par le cluster. Il est cependant possible de modifier les paramètres manuellement (details).

 

  • La modification d’une table est-elle automatiquement répliquée ?

Toutes les modifications certifiées d’un nœud vont être répliquées sur les autres. Cela concerne évidemment les DDL.

A noter que certaines précautions doivent être prisent lorsque vous exécutez des DDL en mode multi-master (details).

 

  • Avec 3 nœuds, si on perd 1 nœud et que les 2 autres ne se voient plus, pas de quorum donc plus d’écriture ?

Avec une architecture MySQL Group Replication de 3 nœuds, l’arrêt non prévu (crash) d’1 membre génère la recomposition automatique du cluster avec 2 nœuds ie aucune intervention n’est nécessaire.

Par contre vous vous trouvez dans une situation « inconfortable » et il faut donc re-provisionner un 3ème nœuds ASAP. Parce qu’avec ce cluster de 2 membres, en cas de crash d’un des 2 ou en cas de split-brain, la recomposition automatique du cluster ne peut plus se faire.

On se trouve alors dans le cas du Network Partitioning (les membres n’acceptent plus d’écriture), et la partition doit être débloquée « manuellement ».

 

  • A quel format le log binaire doit être positionné ?

Seul le format ROW est valide (binlog-format=ROW)

 

  • Peut on contrôler les délais de réplication ?

Le Flow-control permet de maintenir les membres du groupe raisonnablement proches les uns des autres.

A noter que d’autres approches pour contrôler les délais de réplication seront disponibles dans le futur.

Je vous conseille la lecture de cet article qui traite du sujet des performances de MySQL group Replication.

 

  • Pourquoi 9 nœuds maximum ?

Selon les résultats de nos tests, jusqu’à 9 membres les performances restent très satisfaisantes. De plus ce nombre assure une très bonne disponibilité car le cluster peut alors gérer automatiquement jusqu’à 4 pertes de nœuds simultanément !

A noter qu’il est toujours possible de rajouter des slaves au cluster MySQL Group Replication.

 

  • Est-il possible d’avoir une configuration multi OS par exemple un membre sur Linux et un autre membre sur du Windows ?

Tout à fait !

Je peux par exemple avoir l’architecture MySQL Group Replication suivante :

Nœud A sur Linux
Nœud B sur Windows
Nœud C sur OSX

 


Quelques liens utiles

 

 

Thanks for using MySQL!

One Response to “FAQ Webinar MySQL Group Replication”

  1. […] FAQ Webinar MySQL Group Replication […]