Clusters supportés

Toute application utilisant n'importe quel cluster MySQL est soumises aux mêmes tâches:

• Identifier les noeuds capables d'exécuter une requête avec un niveau de service requis.
• Equilibrer et distribuer la requête parmi les candidats.
• Gestion automatique des pannes parmi les candidats, si nécessaire.

Le plugin est optimisé pour gérer ces tâches dans un contexte de réplication MySQL asynchrone classique, à savoir un seul maitre et plusieurs esclaves (copie primaire). Dans ce cas, toutes les tâches listées plus haut doivent être gérées coté client.

D'autres types de clusters MySQL ont moins d'implication coté client. Par exemple, si tous les noeuds du cluster peuvent répondre aux lectures et aux écritures, aucune séparation ne sera nécessaire (plusieurs maîtres, mise à jour total). Si tous les noeuds sont synchrones, ils sont tous éligibles avec le même poids, ce qui simplifie la tâche de selection. Dans de tels cas, le plugin doit être reconfiguré pour désactiver certaines logiques, comme la séparation des lectures/écritures.

Note: But de la documentation

La documentation décrit l'utilisation du plugin dans un cas classique de réplication asynchrone (copie primaire). C'est le cas de base, qui a inspiré l'écriture du plugin. D'autres types de clusters sont décrits brièvement ci-dessous, nous continuons à travailler dessus actuellement.

Copie primaire (Réplication MySQL)

C'est le but primaire de ce plugin. Suivez les astuces fournies dans les descriptions de chacune des fonctionalités.

• Configure un maître et un ou plusieurs esclaves. Les détails de la configuration du serveur sont fournis dans la section sur l'installation.
• Utilisez la politique de balance de charge aléatoire avec le flag sticky.
• Si vous ne prévoyez pas d'utiliser les appels API du niveau de service, ajoutez le flag d'écriture sur le maître.
• Soyez prudent sur les propriétés du failover automatique avant d'ajouter la directive failover.
• Vous devriez considérer l'utilisation du flag trx_stickiness pour exécuter les transactions uniquement sur le primaire. Veuillez lire attentivement son mode de fonctionnement avant de l'utiliser.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini

{
  "myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      }
    },
    "slave": {
      "slave_0": {
        "host": "127.0.0.1",
        "port": 3308
      },
      "slave_1": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "filters": {
      "random": {
        "sticky": "1"
      }
    }
  }
}

Copie primaire avec plusieurs primaires (MMM - MySQL Multi Master)

La réplication MySQL vous permet de créer des topologies de cluster avec plusieurs maîtres (primaires). Les conflits d'écriture ne sont pas gérées par le système de réplication. Aussi, les données doivent être partitionnées manuellement et les clients doivent être redirigés suivant les règles de partitionnement. La configuration recommandée est identique à la configuration de fragmentation ci-dessous.

Fragmentation manuelle, combinée éventuellement avec une copie primaire et plusieurs primaires

Utilisez les astuces SQL et le filtre de groupe du noeud pour les clusters qui utilisent le partitionnement des données, mais laissez au client la redirection de la requête. L'exemple de configuration montre une configuration de plusieurs maîtres avec deux fragmentations.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini
mysqlnd_ms.multi_master=1

{
  "myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      }
      "master_2": {
        "host": "192.168.2.27",
        "socket": "3306"
      }
    },
    "slave": {
      "slave_1": {
        "host": "127.0.0.1",
        "port": 3308
      },
      "slave_2": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "filters": {
      "node_groups": {
        "Partition_A" : {
          "master": ["master_1"],
          "slave": ["slave_1"]
        },
        "Partition_B" : {
          "master": ["master_2"],
          "slave": ["slave_2"]
        }
      },
      "roundrobin": []
    }
  }
}

Le plugin peut également être utilisé avec une collection mouvante de morceaux indépendants. Pour un tel cluster, configurez les maîtres uniquement et désactivez la séparation des lectures/écritures. Les noeuds d'un tel cluster sont appelés maîtres dans la configuration du plugin vu qu'ils acceptent à la fois les lectures et les écritures pour leur partition.

Using synchronous update everywhere clusters such as MySQL Cluster

MySQL Cluster est une solution de cluster synchrone. Tous les noeuds acceptent des lectures et des écritures. D'un point de vue du plugin, tous les noeuds devraient alors être considérés comme des maitres.

Utilisez les fonctionnalités d'équilibre de charge et de reprise sur panne seulement.

• Désactivez le support de la séparation des lectures et écritures.
• Ne configurez que les maitres.
• Considerant la strategy "random once" (cas par défaut), seuls les maitres sont configurés et aucune astuce SQL n'est requise, aucune bascule de connexion n'arrivera durant la requête web. Ainsi, aucune directive particulière n'est requise en ce qui concerne les transactions, le plugin selectionnera un maitre au début du script PHP et l'utilisera jusqu'à la fin.
• Ne précisez pas la qualité de service. Tous les noeuds possèdent toutes les données. Ceci vous fournit la consistence maximale (consistence forte).
• N'activez pas l'injection d'identifiant de transaction coté client. Ceci ne sera d'aucune aide.

Désactiver la répartition des lectures/écritures.

• Mettez mysqlnd_ms.disable_rw_split=1
• N'utilisez pas d'astuces SQL pour forcer l'utilisation d'un noeud.

Ne configurez que les maitres.

• Mettez mysqlnd_ms.multi_master=1.
• Ne configurez aucun esclave.
• Mettez failover=loop_before_master dans le fichier de configuration du plugin, pour éviter les messages d'avertissement concernant une liste d'esclave vide et pour permettre à la logique de boucle du failover de parcourir tous les maîtres configurés avant d'émettre une erreur. Notez les alertes fournies à propos du failover automatique dans les précédentes sections.

mysqlnd_ms.enable=1
mysqlnd_ms.config_file=/path/to/mysqlnd_ms_plugin.ini
mysqlnd_ms.multi_master=1
mysqlnd_ms.disable_rw_split=1

"myapp": {
    "master": {
      "master_1": {
        "host": "localhost",
        "socket": "\/tmp\/mysql57.sock"
      },
      "master_2": {
        "host": "192.168.2.28",
        "port": 3306
      }
    },
    "slave": {
    },
    "filters": {
      "roundrobin": {
      }
    },
    "failover": {
      "strategy": "loop_before_master",
      "remember_failed": true
    }
  }
}

Si vous exécutez une mise à jour dans n'importe quel cluster qui ne supporte pas le partitionnement afin d'éviter les points chauds et les collisions, vous devriez considérer l'utilisation du filtre sur les groupes de noeuds pour conserver les mises à jour sur les tables fréquemment utilisées sur un de ces noeuds. Ceci peut aider à réduire les collisions, et donc, améliorer les performances.