Quels sont les inconvénients de l'utilisation de Galera Cluster au lieu de la réplication maître / esclave?

Quels sont les inconvénients de l'utilisation de Galera Cluster au lieu de la réplication maître / esclave régulière? Le temps de latence de 0 esclave de Galera, la réplication synchrone et aucun point de défaillance unique ne semblent très attrayants, alors pourquoi le cluster Galera n'est-il pas commun?

— Sam
source

Réponses:

Parce que, comme toute autre optimisation, elle ne convient pas à toutes les charges de travail.

Galera peut être submergé par un taux élevé de transactions ou lorsque les transactions mettent à jour de nombreuses lignes. Cela peut également entraîner des retards dans vos applications sur COMMIT lorsque le cluster est synchronisé.

Galera ne met pas non plus à jour les autres nœuds de manière synchrone. Il transmet simplement les sous-projets de manière synchrone. De cette façon, c'est un peu comme la réplication standard en mode semi-synchrone. Par conséquent, il y a encore une petite chance de lire les données périmées d'un autre nœud de cluster. Il existe une option que vous pouvez définir pour forcer SELECT à attendre que la file d'attente des sous-projets ait mis à jour la base de données, mais cela signifie que vous avez des retards sur SELECT. Et même une chance d'obtenir une impasse sur SELECT, ce qui semble contre-intuitif.

Galera est génial, mais pas une technologie universelle. Il existe encore de bonnes raisons d'utiliser la réplication asynchrone.

— Bill Karwin
source

Merci Bill, btw J'ai lu vos présentations Percona pendant un certain temps.

— Sam

Un autre inconvénient est d'avoir un nœud donneur hors de lui-même et d'être utilisé pour copier (via xtrabackup, rsync, mysqldump) vers n'importe quel nœud introduit dans le cluster, laissant les nœuds restants dans le cluster faire le gros du travail jusqu'à ce que le nouveau nœud soit synchronisé. Ce n'est pas un tel inconvénient pour les petites ou moyennes DB.

— RolandoMySQLDBA

@RolandoMySQLDBA Les méthodes SST comme xtrabackup évitent précisément de verrouiller le donneur. Bien qu'il soit vrai que dans tous les cas, le donateur aura des performances dégradées si la base de données est volumineuse.

— jynus

@jynus, le problème ne se verrouille pas sur le nœud donneur , mais le fait que le nœud récepteur est hors ligne et indisponible pour toutes les requêtes pendant que le SST est en cours. Par conséquent, si vous utilisez le cluster pour l'équilibrage de charge des requêtes, les requêtes qui auraient été envoyées au nœud de réception doivent être envoyées à d'autres nœuds jusqu'à ce que le SST soit terminé.

— Bill Karwin

Dans le cas où quelqu'un d'autre regarde, l'option à laquelle Bill fait référence est wsrep_causal_reads... réglée sur ON avec SET GLOBAL wsrep_causal_reads = 'ON';pour que les sélections attendent jusqu'à ce que tous les jeux d'écriture soient terminés.

— Luke Cousins

Certains inconvénients de Galera comprennent:

Support du moteur de stockage: limité à InnoDB / XtraDB (plus support expérimental pour MyISAM)
Prise en charge du système d'exploitation: uniquement Oses de type Linux / Unix

Il y a aussi quelques limitations qui doivent être notées, mais qui peuvent peut-être être contournées:

Par défaut (Total Order Isolation), les opérations DDL bloquent l'intégralité du cluster jusqu'à ce qu'elles se terminent
Chaque table doit avoir une clé primaire explicite, simple ou multi-colonne
Verrouillage: certains types de verrouillage explicite ne sont pas pris en charge.

Pour plus d'informations, consultez les détails sur Codership (et ici sur le blocage de DDL), MariaDB et Percona .

EDIT: Notez également que certains soutiennent que les grappes de bases de données étroitement couplées, telles que Galera, ne devraient pas avoir de nœuds géo-distribués en raison des problèmes découlant de la non-fiabilité inhérente de la couche réseau. Au lieu de cela, des solutions asynchrones doivent être utilisées dans ces cas. Voir: Comment ne pas effectuer la haute disponibilité MySQL: distribution des nœuds géographiques avec mauvaise utilisation de la réplication basée sur Galera . Néanmoins, le blog Galera déclare que (2015):

Les arguments en faveur de la création de clusters de bases de données géo-distribués sont solides. L'approche de la réplication Galera et les fonctionnalités spécifiques du produit rendent pratique la création de clusters Galera qui s'étendent sur plusieurs centres de données et plusieurs utilisateurs ont déjà de tels clusters en production.

— dbdemon
source