Dans l'un des blogs précédents, nous avons couvert les nouvelles fonctionnalités qui sortent dans MariaDB 10.4. Nous y avons mentionné qu'une nouvelle version de Galera Cluster sera incluse dans cette version. Dans cet article de blog, nous passerons en revue les fonctionnalités de Galera Cluster 26.4.0 (ou Galera 4), les examinerons rapidement et explorerons comment elles affecteront votre configuration lorsque vous travaillerez avec MariaDB Galera Cluster.
Réplication en continu
Galera Cluster n'est en aucun cas un remplacement direct de MySQL autonome. La façon dont la certification du jeu d'écriture fonctionne a introduit plusieurs limitations et cas extrêmes qui peuvent sérieusement limiter la capacité de migrer vers Galera Cluster. Les trois limitations les plus courantes sont...
- Problèmes avec des transactions longues
- Problèmes avec des transactions importantes
- Problèmes avec les points chauds dans les tableaux
Ce qui est formidable à voir, c'est que Galera 4 introduit la réplication en continu, ce qui peut aider à réduire ces limitations. Passons en revue l'état actuel un peu plus en détail.
Transactions de longue durée
Dans ce cas, nous parlons de temps, ce qui est définitivement problématique dans Galera. La principale chose à comprendre est que Galera réplique les transactions en tant qu'ensembles d'écriture. Ces jeux d'écriture sont certifiés sur les membres du cluster, garantissant que tous les nœuds peuvent appliquer un jeu d'écriture donné. Le problème est que des verrous sont créés sur le nœud local, ils ne sont pas répliqués dans le cluster. Par conséquent, si votre transaction prend plusieurs minutes et si vous écrivez sur plusieurs nœuds Galera, avec le temps, il est de plus en plus probable que sur l'un des nœuds restants, certaines transactions modifieront certaines des lignes mises à jour dans votre transaction de longue durée. Cela entraînera l'échec de la certification et la transaction de longue durée devra être annulée. En bref, étant donné que vous envoyez des écritures à plusieurs nœuds du cluster, plus la transaction est longue, plus il est probable qu'elle échoue à la certification en raison d'un conflit.
Points d'accès
Nous entendons par là les lignes, qui sont fréquemment mises à jour. En règle générale, il s'agit d'une sorte de compteur qui est mis à jour encore et encore. Le coupable du problème est le même que dans les transactions longues - les lignes ne sont verrouillées que localement. Encore une fois, si vous envoyez des écritures à plusieurs nœuds, il est probable que le même compteur soit modifié en même temps sur plusieurs nœuds, provoquant des conflits et faisant échouer la certification.
Pour ces deux problèmes, il existe une solution :vous pouvez envoyer vos écritures à un seul nœud au lieu de les répartir sur l'ensemble du cluster. Vous pouvez utiliser des proxys pour cela - ClusterControl déploie HAProxy et ProxySQL, les deux peuvent être configurés pour que les écritures soient envoyées à un seul nœud. Si vous ne pouvez pas envoyer d'écritures à un seul nœud, vous devez accepter que vous verrez de temps en temps des conflits de certification et des annulations. En général, l'application doit être capable de gérer les restaurations à partir de la base de données - il n'y a pas moyen de contourner cela, mais c'est encore plus important lorsque l'application fonctionne avec Galera Cluster.
Pourtant, envoyer le trafic à un nœud n'est pas suffisant pour gérer le troisième problème.
Transactions importantes
Il est important de garder à l'esprit que le jeu d'écriture est envoyé pour certification uniquement lorsque la transaction est terminée. Ensuite, le jeu d'écriture est envoyé à tous les nœuds et le processus de certification a lieu. Cela induit des limites sur la taille de la transaction unique car Galera, lors de la préparation du jeu d'écriture, la stocke dans un tampon en mémoire. Des transactions trop volumineuses réduiront les performances du cluster. Par conséquent, deux variables ont été introduites :wsrep_max_ws_rows, qui limite le nombre de lignes par transaction (bien qu'il puisse être défini sur 0 - illimité) et, plus important :wsrep_max_ws_size, qui peut être défini jusqu'à 2 Go. Ainsi, la plus grande transaction que vous pouvez exécuter avec Galera Cluster peut atteindre 2 Go. De plus, vous devez garder à l'esprit que la certification et l'application de la grande transaction prennent également du temps, créant un «décalage» - lecture après écriture, ce nœud atteint autre que celui où vous avez initialement validé la transaction, entraînera très probablement des données incorrectes car le la transaction est toujours en cours d'application.
Galera 4 est livré avec Streaming Replication, qui peut être utilisé pour atténuer tous ces problèmes. La principale différence sera que le jeu d'écritures peut maintenant être divisé en parties - il ne sera plus nécessaire d'attendre que la transaction entière se termine avant que les données ne soient répliquées. Cela peut vous amener à vous demander - à quoi ressemble la certification dans un tel cas ? En bref, la certification est à la volée - chaque fragment est certifié et toutes les lignes impliquées sont verrouillées sur tous les nœuds du cluster. Il s'agit d'un changement sérieux dans le fonctionnement de Galera - jusqu'à présent, les verrous étaient créés localement, avec des verrous de réplication en continu qui seront créés sur tous les nœuds. Cela aide dans les cas dont nous avons discuté ci-dessus - le verrouillage des lignes lorsque des fragments de transaction arrivent, aide à réduire la probabilité que la transaction doive être annulée. Les transactions en conflit exécutées localement ne pourront pas obtenir les verrous dont elles ont besoin et devront attendre que la transaction de réplication se termine et libère les verrous de ligne.
Dans le cas des hotspots, avec la réplication en streaming, il est possible d'obtenir les verrous sur tous les nœuds lors de la mise à jour de la ligne. Les autres requêtes qui souhaitent mettre à jour la même ligne devront attendre que le verrou soit libéré avant d'exécuter leurs modifications.
Les transactions volumineuses bénéficieront de la réplication en continu car il ne sera plus nécessaire d'attendre la fin de l'ensemble de la transaction et elles ne seront plus limitées par la taille de la transaction - les transactions volumineuses seront divisées en fragments. Cela aide également à mieux utiliser le réseau - au lieu d'envoyer 2 Go de données à la fois, les mêmes 2 Go de données peuvent être divisés en fragments et envoyés sur une plus longue période.
Il existe deux options de configuration pour la réplication en continu :wsrep_trx_fragment_size, qui indique la taille d'un fragment (par défaut, il est défini sur 0, ce qui signifie que la réplication en continu est désactivée) et wsrep_trx_fragment_unit, qui indique ce qu'est réellement le fragment. Par défaut, il s'agit d'octets, mais il peut également s'agir d'une "instruction" ou d'une "ligne". Ces variables peuvent (et doivent) être définies au niveau de la session, ce qui permet à l'utilisateur de décider quelle requête particulière doit être répliquée à l'aide de la réplication en continu. Définir l'unité sur "instructions" et la taille sur 1 permet, par exemple, d'utiliser la réplication en continu uniquement pour une seule requête qui, par exemple, met à jour un point d'accès.
Bien sûr, l'exécution de la réplication en continu présente des inconvénients, principalement dus au fait que des verrous sont désormais pris sur tous les nœuds du cluster. Si vous avez vu de grosses transactions annulées depuis des lustres, une telle transaction devra maintenant être annulée sur tous les nœuds. De toute évidence, la meilleure pratique consiste à réduire autant que possible la taille d'une transaction pour éviter que les retours en arrière ne prennent des heures. Un autre inconvénient est que, pour des raisons de récupération sur incident, les jeux d'écriture créés à partir de chaque fragment sont stockés dans la table wsrep_schema.SR sur tous les nœuds, ce qui, en quelque sorte, implémente un tampon à double écriture, augmentant la charge sur le cluster. Par conséquent, vous devez décider avec soin quelle transaction doit être répliquée à l'aide de la réplication en continu et, tant que cela est possible, vous devez toujours vous en tenir aux meilleures pratiques consistant à avoir de petites transactions courtes ou à diviser la grande transaction en lots plus petits.
Verrouillages de sauvegarde
Enfin, les utilisateurs de MariaDB pourront bénéficier de verrous de sauvegarde pour SST. L'idée derrière SST exécuté à l'aide (pour MariaDB) mariabackup est que l'ensemble de données doit être transféré, à la volée, avec des journaux redo collectés en arrière-plan. Ensuite, un verrou global doit être acquis, garantissant qu'aucune écriture ne se produira, la position finale du journal de rétablissement doit être collectée et stockée. Historiquement, pour MariaDB, la partie verrouillage était réalisée à l'aide de FLUSH TABLES WITH READ LOCK qui faisait son travail mais sous forte charge c'était assez difficile à acquérir. C'est aussi assez lourd - non seulement les transactions doivent attendre que le verrou soit libéré, mais aussi les données doivent être vidées sur le disque. Désormais, avec MariaDB 10.4, il sera possible d'utiliser BACKUP LOCK moins intrusif, qui ne nécessitera pas de vidage des données, seuls les commits seront bloqués pendant la durée du verrouillage. Cela devrait signifier des opérations SST moins intrusives, ce qui est certainement agréable à entendre. Tous ceux qui ont dû exécuter leur cluster Galera en mode d'urgence, sur un nœud, en croisant les doigts pour que SST n'affecte pas les opérations du cluster devraient être plus qu'heureux d'entendre parler de cette amélioration.
Lectures causales à partir de l'application
Galera 4 a introduit trois nouvelles fonctions destinées à aider à ajouter la prise en charge des lectures causales dans les applications - WSREP_LAST_WRITTEN_GTID(), qui renvoie le GTID de la dernière écriture effectuée par le client, WSREP_LAST_SEEN_GTID(), qui renvoie le GTID de la dernière transaction d'écriture observée par le client et WSREP_SYNC_WAIT_UPTO_GTID(), qui bloquera le client jusqu'à ce que le GTID transmis à la fonction soit validé sur le nœud. Bien sûr, vous pouvez déjà appliquer des lectures causales dans Galera, mais en utilisant ces fonctions, il sera possible d'implémenter une lecture après écriture sécurisée dans les parties de l'application où cela est nécessaire, sans avoir à modifier la configuration de Galera. /P>
Mettre à niveau vers MariaDB Galera 10.4
Si vous souhaitez essayer Galera 4, il est disponible dans la dernière version candidate pour MariaDB 10.4. Selon la documentation MariaDB, pour le moment, il n'y a aucun moyen de faire une mise à niveau en direct de 10.3 Galera vers 10.4. Vous devez arrêter l'ensemble du cluster 10.3, le mettre à niveau vers 10.4, puis le redémarrer. C'est un blocage sérieux et nous espérons que cette limitation sera supprimée dans l'une des prochaines versions. Il est de la plus haute importance d'avoir l'option d'une mise à niveau en direct et pour cela, MariaDB 10.3 et MariaDB 10.4 devront coexister dans le même cluster Galera. Une autre option, qui peut également convenir, consiste à configurer une réplication asynchrone entre l'ancien et le nouveau cluster Galera.
Nous espérons vraiment que vous avez apprécié cette courte revue des fonctionnalités de MariaDB 10.4 Galera Cluster, nous sommes impatients de voir la réplication en streaming dans de vrais environnements de production en direct. Nous espérons également que ces changements contribueront à accroître encore l'adoption de Galera. Après tout, la réplication en streaming résout de nombreux problèmes qui peuvent empêcher les gens de migrer vers Galera.
