ApsaraDB RDS:Utiliser le mode MGR

Pourquoi utiliser MGR

MGR s'appuie sur le protocole Paxos pour maintenir tous les nœuds synchronisés. Votre cluster RDS bénéficie ainsi de trois propriétés que la réplication asynchrone et semi-synchrone ne peuvent garantir :

• Cohérence forte des données : en cas de défaillance du nœud principal, le cluster le retire automatiquement et promeut un nœud secondaire. Les données sur le nouveau nœud principal sont cohérentes avec celles validées par le nœud défaillant.

• Fiabilité élevée des données : une transaction sur le nœud principal n'est validée qu'après confirmation par la majorité (plus de la moitié) des nœuds secondaires qu'ils ont bien reçu les données, évitant ainsi toute perte d'information.

• Cohérence transactionnelle globale configurable : le paramètre group_replication_consistency permet d'ajuster la cohérence en lecture et en écriture par session selon les besoins de votre charge de travail.

MGR offre un débit inférieur à celui de la réplication asynchrone et consomme plus de mémoire que les modes asynchrone et semi-synchrone. Testez les performances de vos charges de travail sensibles aux latences ou contraintes en mémoire avant de passer à MGR.

Prérequis

Avant de commencer, vérifiez que votre cluster RDS répond à toutes les exigences suivantes. Consultez l'édition RDS, la version majeure du moteur et le type d'instance sur la page Basic Information du cluster dans la console ApsaraDB RDS.

Pour migrer de l'édition High-availability de RDS vers l'édition Cluster de RDS, consultez Migrer l'édition RDS de RDS High-availability Edition vers RDS Cluster Edition . Pour mettre à jour la version mineure du moteur, consultez Mettre à jour la version mineure du moteur . Pour mettre à niveau la version du proxy de base de données, consultez Mettre à niveau la version du proxy de base de données . Pour modifier les spécifications de l'instance, consultez Modifier les spécifications de l'instance .

Limitations

Il est impossible d'activer MGR si le cluster contient des tables X-Engine ou des tables dépourvues de clé primaire. Exécutez les requêtes suivantes pour vérifier ces conditions.

Vérifier la présence de tables X-Engine : un résultat égal à 0 signifie qu'aucune table X-Engine n'existe :

SELECT
  COUNT(1)
FROM
  information_schema.TABLES
WHERE
  ENGINE = 'xengine'
  AND table_schema NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'test', 'sys', '__recycle_bin__'
  );

Vérifier l'absence de clés primaires : un résultat égal à 0 signifie que toutes les tables possèdent une clé primaire :

SELECT
  COUNT(1) AS count
FROM
  information_schema.TABLES t1
  LEFT OUTER JOIN information_schema.columns t2 ON t1.table_schema = t2.TABLE_SCHEMA
  AND t1.table_name = t2.TABLE_NAME
  AND t2.COLUMN_KEY = 'PRI'
WHERE
  t2.table_name IS NULL
  AND t1.table_type = 'BASE TABLE'
  AND t1.TABLE_SCHEMA NOT IN(
    'information_schema', 'performance_schema',
    'mysql', 'sys'
  );

Pour consulter la liste complète des exigences et limitations de MySQL Group Replication, reportez-vous à la section Requirements and Limitations de la documentation MySQL.

Impacts

Le passage d'une réplication asynchrone ou semi-synchrone à MGR déclenche un basculement d'instance. Effectuez cette opération pendant les heures creuses et assurez-vous que votre application est configurée pour se reconnecter automatiquement. Pour plus de détails sur les conséquences d'un basculement, consultez la rubrique Impacts d'un basculement d'instance.

Facturation

L'utilisation de MGR est gratuite.

Activer MGR

Notes d'utilisation

gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
binlog_format=ROW
binlog_transaction_dependency_tracking=WRITESET
transaction_write_set_extraction=XXHASH64
master_info_repository=TABLE
relay_log_info_repository=TABLE

slave_preserve_commit_order=ON
slave_parallel_type=LOGICAL_CLOCK
rpl_semi_sync_master_enabled=OFF
rpl_semi_sync_slave_enabled=OFF

disabled_storage_engines=MyISAM,BLACKHOLE,FEDERATED,ARCHIVE,MEMORY,XENGINE
replication_communication_stack=MYSQL
group_replication_single_primary_mode=ON
group_replication_paxos_single_leader=ON
group_replication_consistency=BEFORE_ON_PRIMARY_FAILOVER

FAQ

Puis-je revenir de MGR à une réplication asynchrone ou semi-synchrone ?

Oui. Sur la page Basic Information , cliquez sur Change Data Replication Mode dans la section Instance Topology Management , puis sélectionnez le mode cible. Le basculement est bidirectionnel entre les modes asynchrone, semi-synchrone et MGR.

Les nœuds secondaires peuvent-ils traiter les requêtes de lecture en mode MGR ?

Oui. Toutefois, si les nœuds secondaires sont surchargés, les performances d'écriture sur le nœud principal se dégradent. Activez la fonctionnalité de proxy de base de données avec répartition lecture/écriture pour distribuer les lectures sur les nœuds secondaires tout en contrôlant la latence de réplication et les pondérations de lecture. Cela évite que les nœuds secondaires ne deviennent un goulot d'étranglement.

MGR prend-il en charge le mode multi-principal ?

Non. MGR sur ApsaraDB RDS for MySQL prend uniquement en charge le mode mono-principal. Le mode multi-principal introduit une instabilité : une perturbation ou une panne sur n'importe quel nœud affecte la disponibilité de l'ensemble du cluster.

Pourquoi MGR nécessite-t-il au moins 8 Go de mémoire ?

MGR ajoute trois sources de surcoût mémoire par rapport à la réplication classique :

• La couche de communication XCom maintient un cache de messages d'environ 1 Go.

• Le module de certification des transactions conserve un tableau d'informations de certification en mémoire.

• Des threads d'arrière-plan supplémentaires s'exécutent pour les tâches de gestion de groupe.

Sur les instances disposant de moins de 8 Go de mémoire, des charges de travail intensives (telles que des pics de requêtes parallèles importantes) peuvent épuiser la mémoire disponible et provoquer une erreur d'épuisement de la mémoire (OOM).

Dois-je choisir un type d'instance à usage général ou dédié pour MGR ?

• Mémoire de 8 à 16 Go : utilisez une instance à usage général. Le partage des ressources physiques offre aux processus MGR plus de flexibilité pour utiliser la mémoire non consommée par les autres locataires.

• 32 Go ou plus : utilisez une instance dédiée pour une isolation des ressources plus stricte et des performances de pointe plus prévisibles.

Référence API

Étapes suivantes

• Présentation du mode MGR — fonctionnement interne de MGR

• Impacts d'un basculement d'instance — conséquences sur les connexions et les données lors d'un basculement