Analyse de l'instance de récupération distribuée MySQL

1. Présentation

Chaque fois qu'un serveur MySQL rejoint ou rejoint un cluster MGR, il doit rattraper les différentes transactions du cluster pour garantir que les données de ce nœud sont synchronisées avec les dernières données du cluster. Le processus par lequel le nœud nouvellement ajouté rattrape les données du cluster ou le nœud qui rejoint le cluster rattrape les données de transaction qui ont différé depuis le moment où il a quitté le cluster jusqu'à présent est appelé récupération distribuée.

Le nœud qui demande à rejoindre le cluster vérifie d'abord le journal de relais dans le canal groupreplicationapplier pour vérifier les données de transaction du nœud qui n'a pas encore été synchronisé à partir du cluster. S'il s'agit d'un nœud qui rejoint le cluster, le nœud trouvera les données de transaction qui n'ont pas été rejouées depuis sa sortie du cluster et les dernières données du cluster. Dans ce cas, le nœud appliquera d'abord ces transactions non synchronisées. Pour les nœuds nouvellement ajoutés au cluster, la récupération complète des données peut être effectuée directement à partir d'un nœud de démarrage.

Ensuite, le nœud nouvellement ajouté établit une connexion avec le nœud en ligne existant (nœud de démarrage) dans le cluster pour le transfert d'état. Le nœud nouvellement ajouté synchronise les données qui n'ont pas été synchronisées avant de rejoindre le cluster ou après avoir quitté le cluster à partir du nœud de démarrage dans le cluster. Ces différentes transactions sont fournies par le nœud de démarrage dans le cluster. Ensuite, le nœud nouvellement ajouté applique les transactions non appliquées synchronisées à partir du nœud d'amorçage dans le cluster. À ce stade, le nœud demandant à rejoindre le cluster appliquera les données écrites par la nouvelle transaction dans le cluster pendant le processus de transfert d'état. (À ce stade, les données écrites par les nouveaux éléments du cluster sont temporairement stockées dans la file d'attente du cache et les données ne sont pas écrites sur le disque.) Une fois ce processus terminé, les données des nœuds nouvellement ajoutés sont à un niveau comparé avec les données de l'état du cluster entier et le nœud est défini sur l'état en ligne.

Remarque : Les nouveaux nœuds qui rejoignent le cluster, qu'ils aient déjà été dans ce cluster ou non, sélectionneront d'abord au hasard un nœud en ligne pour synchroniser les différentes transactions entre le nœud et le cluster.

La réplication de groupe utilise la méthode suivante pour implémenter le transfert d'état lors de la récupération distribuée :

Utilisez la fonction du plug-in de clonage pour effectuer des opérations de clonage à distance, qui peuvent être prises en charge à partir de MySQL 8.0.17. Pour utiliser cette méthode, le plug-in de clonage doit être installé au préalable sur le nœud de démarrage et sur le nœud nouvellement rejoint. La réplication de groupe configure automatiquement les paramètres requis du plug-in de clonage et gère les opérations de clonage à distance.

Copiez les données du journal binaire du nœud de démarrage et appliquez ces transactions sur le nœud nouvellement rejoint. Cette méthode nécessite un canal de réplication asynchrone standard appelé groupreplicationrecovery établi entre le nœud de démarrage et le nœud de jointure.

Après avoir exécuté STARTGROUP_REPLICATION sur le nœud de jointure, la réplication de groupe sélectionnera automatiquement la meilleure combinaison des méthodes ci-dessus pour le transfert d'état. Pour ce faire, la réplication de groupe vérifiera quels nœuds existants dans le cluster peuvent être utilisés comme nœuds de démarrage, combien de transactions le nœud qui rejoint nécessitera du nœud de démarrage et si des transactions ne sont plus présentes dans les fichiers journaux binaires de n’importe quel nœud du cluster. S'il existe un écart de transaction important entre le nœud de jointure et le nœud de démarrage, ou si certaines des transactions requises ne figurent pas dans les fichiers journaux binaires du nœud de démarrage, la réplication de groupe lancera une récupération distribuée via une opération de clonage à distance. S'il n'y a pas d'intervalles de transaction importants ou si le plug-in de clonage n'est pas installé, la réplication de groupe transférera l'état directement à partir du journal binaire du nœud de démarrage.

Lors d'une opération de clonage à distance, les données existantes sur le nœud rejoint seront supprimées et remplacées par une copie des données du nœud de démarrage. Lorsque l'opération de clonage à distance est terminée et que le nœud nouvellement rejoint a été redémarré, le transfert d'état à partir du journal binaire du nœud de démarrage continuera à obtenir les données incrémentielles écrites par le cluster pendant l'opération de clonage à distance.

Pendant le transfert d'état à partir du journal binaire du nœud de démarrage, le nœud nouvellement rejoint copie et applique les transactions requises à partir du journal binaire du nœud de démarrage et applique les transactions au fur et à mesure de leur réception jusqu'à ce que le journal binaire enregistre que le nœud nouvellement rejoint a rejoint le cluster. (Lorsque le nœud joignant rejoint avec succès le cluster, l'événement de changement de vue correspondant sera enregistré dans le journal binaire.) Au cours de ce processus, le nœud joignant mettra en mémoire tampon les nouvelles données de transaction appliquées au cluster. Une fois le transfert d'état depuis le journal binaire terminé, le nœud nouvellement rejoint appliquera les transactions mises en mémoire tampon.

Lorsque le nœud qui rejoint est à jour avec toutes les transactions du cluster, le nœud sera mis en ligne et pourra rejoindre le cluster en tant que nœud normal, et la récupération distribuée sera terminée.

ps : Le transfert d'état à partir du journal binaire est le mécanisme de base pour la récupération distribuée avec réplication de groupe, et si le nœud de démarrage et le nœud de jonction dans le groupe de réplication ne sont pas configurés pour prendre en charge le clonage. Étant donné que le transfert d'état à partir du journal binaire est basé sur une réplication asynchrone classique, si le serveur MySQL rejoignant le cluster ne dispose pas du tout de données pour le cluster, ou si les données sont obtenues à partir d'une très ancienne sauvegarde, la récupération peut prendre beaucoup de temps. . Dernières données. Par conséquent, dans ce cas, il est recommandé, avant d'ajouter le serveur MySQL au cluster, de le configurer avec les données du cluster en transférant un instantané assez récent des nœuds déjà présents dans le cluster. Cela minimise le temps requis pour la récupération distribuée et réduit l'impact sur le nœud de démarrage, qui doit conserver et transmettre moins de fichiers journaux binaires.

2. Connexion pour la récupération distribuée

Lorsque le nœud joignant se connecte au nœud d'amorçage dans le nœud existant pour le transfert d'état pendant la récupération distribuée, le nœud joignant agit en tant que client et le nœud d'amorçage agit en tant que serveur. Lorsque le transfert d'état se produit à partir du journal binaire du nœud de démarrage via cette connexion (à l'aide du canal de réplication asynchrone GroupReplicationRecovery), le nœud joignant agit en tant que réplica et le nœud de démarrage agit en tant que source. Lors de l'exécution d'une opération de clonage à distance via cette connexion, le nœud nouvellement ajouté agit comme un récepteur de données complet et le nœud de démarrage agit comme un fournisseur de données complet. Les paramètres de configuration qui s'appliquent aux rôles en dehors du contexte de la réplication de groupe s'appliquent également à la réplication de groupe, sauf s'ils sont remplacés par des paramètres ou des comportements de configuration spécifiques à la réplication de groupe.

Les connexions fournies par les nœuds existants aux nœuds nouvellement rejoints pour la récupération distribuée sont différentes des connexions utilisées par la réplication de groupe pour la communication entre les nœuds au sein du cluster.

Le moteur de communication de groupe est utilisé pour la réplication de groupe (XCom, variante Paxos), la connexion utilisée pour la communication TCP entre les instances XCom distantes est spécifiée par la variable système groupreplicationlocal_address. Cette connexion est utilisée pour la messagerie TCP/IP entre les nœuds en ligne au sein du cluster. La communication avec l'instance locale s'effectue via l'utilisation d'un canal de transport partagé en mémoire.

Pour la récupération distribuée, jusqu'à MySQL8.0.20, les nœuds du cluster fournissaient leurs connexions client SQL standard au nœud joignant, qui était spécifié par les variables système de nom d'hôte et de port du serveur MySQL. Si la variable système report_port spécifie un autre numéro de port, ce numéro de port est utilisé à la place.

À partir de MySQL 8.0.21, les membres du groupe peuvent utiliser une liste alternative de points de terminaison de récupération distribuée comme connexion client privée du membre rejoignant, permettant ainsi d'utiliser des connexions indépendantes des utilisateurs clients réguliers du membre pour contrôler la récupération distribuée. Cette liste peut être spécifiée à l'aide de la variable système groupReplicationAdvertiseRecoveryEndpoints, et les membres transfèrent leur liste de points de terminaison de récupération distribuée au groupe lorsqu'ils rejoignent le groupe. Par défaut, les membres continuent de fournir les mêmes connexions client SQL standard que dans les versions antérieures.

PS :

La récupération distribuée peut échouer si le nœud qui rejoint ne peut pas identifier correctement les autres nœuds à l'aide du nom d'hôte défini par les variables système de MySQLServer. Il est recommandé que le système d'exploitation exécutant MySQL dispose d'un nom d'hôte unique correctement configuré à l'aide du DNS ou des paramètres locaux. Le nom d'hôte utilisé par le serveur pour les connexions client SQL peut être vérifié dans la colonne Memberhost de la table ReplicationgroupMembers sous la bibliothèque « performancesschema ». Si plusieurs membres du groupe externalisent le nom d'hôte par défaut défini par le système d'exploitation, il est possible que le nœud qui le rejoint ne le résolve pas à l'adresse correcte et ne puisse pas se connecter pour une récupération distribuée. Dans ce cas, la variable système report_host du serveur MySQL peut être utilisée pour configurer un nom d'hôte unique externalisé par chaque serveur.

Les étapes pour rejoindre un nœud afin d'établir une connexion pour une récupération distribuée sont les suivantes :

Lorsqu'un nœud rejoint le cluster, il se connecte en utilisant l'un des nœuds seed contenus dans la liste dans la variable système groupreplicationgroupseeds, en se connectant initialement en utilisant l'adresse groupreplicationlocaladdress spécifiée dans cette liste. Le nœud source peut être un sous-ensemble des données de cluster.

Grâce à cette connexion, le nœud d'amorçage utilise le service d'adhésion de Group Replication pour fournir au nœud joignant une liste de tous les nœuds en ligne du cluster sous la forme d'une vue. Les informations d'adhésion incluent des détails sur le point de terminaison de récupération distribuée ou la connexion client SQL standard fournie par chaque membre pour la récupération distribuée.

Le nœud de jointure sélectionne un nœud en ligne approprié dans cette liste comme nœud de démarrage pour la récupération distribuée.

Le nœud de jointure tente de se connecter au nœud de démarrage à l'aide du point de terminaison de récupération distribuée du nœud de démarrage et tente de se connecter à chaque nœud tour à tour dans l'ordre spécifié. dans le point de terminaison de la liste. Si le nœud de démarrage ne fournit pas de point de terminaison, le nœud de jointure tentera de se connecter à l'aide de la connexion client SQL standard du nœud de démarrage. Les exigences SSL pour la connexion sont spécifiées par les options groupreplicationrecoveryssl*.

Si le nœud joignant ne peut pas se connecter au nœud d'amorçage spécifié, il réessayera la connexion avec d'autres nœuds d'amorçage appropriés. Si le nœud qui rejoint épuise la liste de diffusion du point de terminaison sans établir de connexion, il ne revient pas à la connexion client SQL standard du nœud de démarrage, mais passe à la place à un autre nœud de démarrage pour tenter de rétablir la connexion.

Lorsque le nœud joignant établit une connexion de récupération distribuée avec le nœud de démarrage, il utilisera la connexion pour le transfert d'état. Le journal du nœud joignant indique l'hôte et le port de la connexion utilisée. Si une opération de clonage à distance est utilisée, lorsque le nœud joignant est redémarré à la fin de l'opération, il établira une connexion avec le nouveau nœud de démarrage, effectuant un transfert d'état à partir du journal binaire du nœud de démarrage. Il peut s'agir d'une connexion différente de celle du nœud de démarrage utilisé pour l'opération de clonage à distance, ou de la même connexion que le nœud de démarrage. Quoi qu'il en soit, la récupération distribuée établira une connexion au nœud de démarrage de la même manière.

2.1 Recherche de l'adresse du point de terminaison de récupération distribuée

La variable système groupreplicationadvertiserecoveryendpoints sert d'adresse IP fournie par le point de terminaison de récupération distribuée et n'a pas besoin d'être configurée pour le serveur MySQL (c'est-à-dire qu'elle n'a pas besoin d'être spécifiée par le système d'adresse d'administration variable ou dans la liste des variables système bindaddress).

Configurez le port fourni pour l'extrémité de récupération distribuée pour MySQL Server, qui doit être spécifié par les variables système port, reportport ou adminport. Les connexions TCP/IP doivent être écoutées sur ces ports. Si adminport est spécifié, l'utilisateur de réplication utilisé pour la récupération distribuée nécessite l'autorisation SERVICECONNECTIONADMIN pour se connecter. La sélection du port d'administration permet de séparer les connexions de récupération distribuée des connexions client MySQL classiques.

Les nœuds de jointure essaient chaque point de terminaison tour à tour dans l'ordre spécifié dans la liste. Si groupreplicationadvertiserecoveryendpoints est défini sur DEFAULT au lieu d’une liste de points de terminaison, des connexions client SQL standard seront fournies. Les connexions client SQL standard ne sont pas automatiquement incluses dans la liste des points de terminaison de récupération distribuée et ne seront pas utilisées comme sauvegarde si la liste des points de terminaison du nœud de démarrage est épuisée sans connexions. Si vous souhaitez fournir une connexion client SQL standard comme l'un des multiples points de terminaison de récupération distribuée, vous devez l'inclure explicitement dans la liste spécifiée par groupreplicationadvertiseadvertiserecovery_endpoints. Vous pouvez mettre cela à la fin comme connexion de dernier recours.

Il n'est pas nécessaire d'ajouter le point de terminaison de récupération distribuée du membre du groupe (ou la connexion client SQL standard si aucun point de terminaison n'est fourni) à la liste autorisée de réplication de groupe spécifiée par groupreplicationipallowlist (à partir de MySQL 8.0.22) ou la variable système groupreplicationipwhitelist. La liste d'autorisations s'applique uniquement aux adresses spécifiées par groupreplicationlocal_address pour chaque nœud. Le nœud qui rejoint doit disposer d'une connexion initiale au cluster autorisée par la liste verte afin de récupérer une ou plusieurs adresses pour la récupération distribuée.

Après avoir défini les variables système et exécuté l'instruction STARTGROUP_REPLICATION, les points de terminaison de récupération distribuée répertoriés seront vérifiés. Si la liste ne peut pas être analysée correctement ou si aucun point de terminaison ne peut être atteint sur l'hôte parce que le service n'écoute pas sur la liste, la réplication de groupe enregistrera une erreur et ne pourra pas démarrer.

2.2 Compression de récupération distribuée

Dans MySQL 8.0.18, il existe une option pour configurer la compression pour la récupération distribuée à l'aide de la méthode de transfert d'état dans le journal binaire du nœud de démarrage. La compression peut bénéficier d'une récupération distribuée dans les situations où la bande passante du réseau est limitée et où le nœud leader doit transférer de nombreuses transactions vers les nœuds joignants. Les variables système groupreplicationrecoverycompressionalgorithm et groupreplicationrecoveryzstdcompression_level configurent les algorithmes de compression autorisés et les niveaux de compression zstd utilisés lors du transfert d'état à partir du journal binaire du nœud de démarrage.

Ces paramètres de compression ne s'appliquent pas aux opérations de clonage à distance. Lorsqu'une opération de clonage à distance est utilisée pour une récupération distribuée, le paramètre cloneenablecompression du plug-in de clonage est appliqué.

2.3 Utilisateurs pour la récupération distribuée

La récupération distribuée nécessite un utilisateur de réplication disposant des autorisations appropriées afin que la réplication de groupe puisse établir des canaux de réplication directs de nœud à nœud. L'utilisateur de réplication doit également disposer des autorisations appropriées. S'il agit également en tant qu'utilisateur clone dans une opération de clonage à distance, l'utilisateur de réplication doit également disposer des autorisations liées au clonage à distance (autorisations BACKUP_ADMIN) sur le nœud de démarrage pour agir en tant qu'utilisateur clone. sur le nœud de démarrage. Clonez les utilisateurs pour les opérations de clonage à distance. De plus, le même utilisateur de réplication doit être utilisé pour la récupération distribuée sur chaque nœud du cluster.

2.4 Récupération distribuée et authentification SSL

Le SSL utilisé pour la récupération distribuée est configuré séparément du SSL utilisé pour la communication de groupe normale, qui est déterminé par les paramètres SSL du serveur et la variable système groupreplicationssl_mode. Pour les connexions de récupération distribuée, vous pouvez utiliser la variable système SSL de récupération distribuée de réplication de groupe dédiée pour configurer l'utilisation de certificats et de clés spécifiquement pour la récupération distribuée.

Par défaut, SSL n'est pas utilisé pour les connexions de récupération distribuée. Définissez groupreplicationrecoveryusessl= ON pour l'activer, puis configurez la variable système SSL de récupération distribuée de réplication de groupe et configurez l'utilisateur de réplication pour qu'il utilise SSL.

Lorsque vous configurez la récupération distribuée pour utiliser SSL, la réplication de groupe applique ce paramètre aux opérations de clonage à distance et aux transferts d'état à partir du journal binaire du nœud de démarrage. La réplication de groupe configure automatiquement les options de clonage SSL (clonesslca, clonesslcert et clonesslkey) pour qu'elles correspondent aux paramètres des options de récupération distribuée de réplication de groupe correspondantes (groupreplicationrecoverysslca, groupreplicationrecoverysslcert et groupreplicationrecoverysslkey).

Si SSL n'est pas utilisé pour la récupération distribuée (groupreplicationrecoveryusessl est défini sur OFF) et que le compte utilisateur de réplication pour la réplication de groupe est authentifié à l'aide du plugin cachingsha2password (par défaut dans MySQL 8.0) ou du plugin sha256password, la paire de clés RSA est utilisée. Mot de passe échange. Dans ce cas, utilisez la variable système groupreplicationrecoverypublickeypath pour spécifier le fichier de clé publique RSA, ou utilisez la variable système groupreplicationrecoverygetpublic_key pour demander la clé publique. Sinon, l'intégralité de la réponse distribuée échouera en raison du rapport d'erreurs.

3. Utilisez le plug-in de clonage pour la récupération distribuée

Le plug-in de clonage pour MySQLServer est disponible à partir de MySQL8.0.17. Si vous souhaitez utiliser des opérations de clonage à distance pour la récupération distribuée dans un cluster, les nœuds existants et joignants doivent être pré-provisionnés pour prendre en charge cette fonctionnalité. Ne configurez pas cela si vous ne souhaitez pas utiliser cette fonctionnalité dans votre cluster, auquel cas la réplication de groupe utilise uniquement le transfert d'état dans le journal binaire.

Pour utiliser le plugin de clonage, au moins un nœud de cluster existant et un nœud de jointure doivent être prédéfinis pour prendre en charge les opérations de clonage à distance. Au minimum, le plug-in de clonage doit être installé sur les nœuds de démarrage et de connexion, les autorisations BACKUPADMIN doivent être accordées à l'utilisateur de réplication pour la récupération distribuée et la variable système groupreplicationclonethreshold doit être définie au niveau approprié. (Par défaut, il s'agit de la valeur maximale autorisée par la séquence GTID, ce qui signifie que dans des circonstances normales, la transmission du statut basée sur le journal binaire est toujours préférée, sauf si la transaction demandée par le nœud joiner n'existe dans aucun membre du groupe. À ce stade, si elle est définie. Si la fonction de clonage est désactivée, quelle que soit la valeur définie pour la variable système, la récupération distribuée par clonage sera déclenchée. Par exemple, lorsqu'un serveur nouvellement initialisé demande à rejoindre le groupe, faites-le. ne l'installez pas si vous ne souhaitez pas utiliser la fonction de clonage et la configuration) Pour garantir une disponibilité maximale du nœud de démarrage, il est recommandé de configurer tous les nœuds de cluster actuels et futurs pour prendre en charge les opérations de clonage à distance. Ainsi, lorsqu'un serveur rejoint le cluster ultérieurement, l'opération de clonage à distance peut être utilisée pour rattraper rapidement les dernières données du cluster.

L'opération de clonage à distance supprime les tablespaces et les données créés par l'utilisateur dans le nœud de jointure avant de transférer les données du nœud de démarrage vers le nœud de jointure. Si l'opération se termine de manière inattendue à mi-chemin, le nœud qui rejoint peut avoir des données partielles ou inexistantes. Ce problème peut être résolu en réexécutant l'opération de clonage à distance effectuée automatiquement par la réplication de groupe.

C'est principalement pour le cas où un chemin de sauvegarde des données est spécifié à l'aide de la sous-option DATADIRECTORY lors du clonage à distance. Lorsque le chemin est spécifié, les données seront enregistrées dans le répertoire spécifié, c'est-à-dire que les données après le clonage ne le seront pas. lié à l'instance où le clone est utilisé et doit être démarré manuellement et spécifiez datadir dans le répertoire où les données de clonage sont enregistrées pour démarrer. Bien entendu, le plug-in MGR peut effectuer automatiquement l'opération de nouvelle tentative du clone distant. (vous devez vous assurer que l'opération de clonage ne spécifie pas la sous-option DATA DIRECTORY. Dans ce cas, les données du clone distant seront écrasées. Après avoir exploité les données du serveur cloné à distance, le serveur cloné à distance redémarrera automatiquement en fonction des données clonées. données après avoir terminé l’opération de clonage à distance.) De plus, bien que le plug-in de clonage soit utilisé conjointement avec la réplication de groupe pour automatiser la gestion et la maintenance de la réplication de groupe, le plug-in de clonage ne nécessite pas son exécution dans le cluster (mais le plug-in MGR doit être installé).

3.1 Conditions de base pour le clonage

Pour la réplication de groupe, vous devez faire attention aux points et différences suivants lors de l'utilisation du plug-in de clonage pour la récupération distribuée :

Le nœud de cluster existant et le nœud de jointure doivent avoir le plug-in de clonage installé et activé.

Le nœud de démarrage et le nœud de jonction doivent fonctionner sur le même système d'exploitation et doivent avoir la même version du serveur MySQL (il doit s'agir de MySQL 8.0.17 ou supérieur pour prendre en charge le plugin de clonage). Par conséquent, le clonage ne fonctionne pas pour les clusters dont les membres exécutent différentes versions de MySQL.

Le nœud de démarrage et le nœud de jonction doivent avoir le plugin "Group Replication" installé et activé, et tous les autres plugins activés sur le nœud de démarrage (par exemple les plugins de trousseau) doivent également être actifs sur le nœud de jonction.

Si la récupération distribuée est configurée pour utiliser SSL (groupreplicationrecoveryusessl=ON), la réplication de groupe applique ce paramètre aux opérations de clonage à distance. La réplication de groupe configure automatiquement les paramètres des options de clonage SSL (clonesslca, clonesslcert et clonesslkey) pour qu'ils correspondent aux paramètres des options de récupération distribuée de réplication de groupe correspondantes (groupreplicationrecoverysslca, groupreplicationrecoverysslcert et groupreplicationrecoverysslkey).

Il n'est pas nécessaire de définir la liste des nœuds de démarrage valides dans la variable système clonevaliddonor_list sur le nœud joignant afin de rejoindre le cluster. La réplication de groupe configure automatiquement ce paramètre une fois que MGR a automatiquement sélectionné le nœud de démarrage parmi les nœuds de cluster existants. Notez que l'opération de clonage à distance utilise le nom d'hôte et le port du protocole SQL du serveur, et non l'adresse et le port pour la communication interne entre les membres du cluster.

Le plugin de clonage dispose d'un certain nombre de variables système pour gérer la charge du réseau et l'impact sur les performances des opérations de clonage à distance. Ces paramètres ne sont pas configurés avec la réplication de groupe, vous pouvez donc les afficher et les définir si nécessaire, ou vous pouvez les définir par défaut. Lors de l'utilisation d'une opération de clonage à distance pour la récupération distribuée, le paramètre cloneenablecompression du plug-in de clonage sera appliqué au fichier. à la place. Affecte les paramètres de compression de réplication de groupe configurés existants.

Afin d'invoquer des opérations de clonage à distance sur les nœuds joints, la réplication de groupe utilise l'utilisateur interne mysql.session, qui dispose déjà des privilèges CLONE_ADMIN, donc aucune configuration spéciale n'est requise.

En tant qu'utilisateur clone sur le nœud de démarrage pour une opération de clonage à distance, Group Replication utilise l'utilisateur de réplication configuré pour la récupération distribuée. Par conséquent, cet utilisateur de réplication doit disposer des privilèges BACKUP_ADMIN sur tous les nœuds de cluster compatibles avec le clonage. Lors de la configuration d'un nœud pour la réplication de groupe, s'il existe un nœud joignant, vous devez également accorder cette autorisation à l'utilisateur de réplication sur ce nœud, car une fois que le nœud joignant a rejoint le cluster, il peut agir comme nœud de démarrage pour d'autres nœuds joignants. Le même utilisateur de réplication est utilisé pour la récupération distribuée sur chaque nœud de cluster. Pour accorder cette autorisation à un utilisateur de réplication sur un nœud existant, exécutez cette instruction individuellement sur chaque nœud de cluster avec la journalisation binaire désactivée, ou sur le nœud principal d'un cluster avec la journalisation binaire activée :

Les phrases suivantes :

GRANT BACKUP_ADMIN ON *.* TO *rpl_user*@'%';

Si vous avez utilisé CHANGE MASTER TO pour spécifier les informations d'identification de l'utilisateur de réplication sur le serveur qui a fourni les informations d'identification de l'utilisateur avant d'utiliser STARTGROUPREPLICATION, assurez-vous de supprimer les informations d'identification de l'utilisateur du référentiel de métadonnées de réplication avant d'effectuer toute opération de clonage à distance. Assurez-vous également que groupreplicationstartonboot=OFF est défini sur le membre qui rejoint. Si les informations d'identification de l'utilisateur ne sont pas supprimées, elles sont transférées au membre qui rejoint le groupe lors de l'opération de clonage à distance. Un canal GroupReplicationRecovery peut alors être accidentellement démarré à l'aide des informations d'identification stockées sur le membre d'origine ou sur un membre cloné à partir de celui-ci. Le démarrage automatique de la réplication de groupe au démarrage du serveur (y compris après une opération de clonage à distance) utilisera les informations d'identification de l'utilisateur stockées, ainsi que les informations d'identification de récupération distribuée si elles ne sont pas spécifiées dans la commande START GROUPREPLICATION.

3.2 Seuil de clonage

Après avoir défini les membres du groupe pour prendre en charge le clonage, la variable système groupreplicationclonethreshold spécifiera un seuil exprimé en nombre de transactions pour utiliser les opérations de clonage à distance dans la récupération distribuée. Si le nombre de transactions entre le nœud d'amorçage et le nœud joignant est supérieur à ce nombre, une opération de clonage à distance sera utilisée pour transférer l'état au nœud joignant lorsque cela est techniquement possible. La réplication de groupe calcule si le seuil a été dépassé en fonction de l'ensemble gtidexecuted de membres du groupe existants. En utilisant des opérations de clonage à distance lorsque les écarts de transaction sont importants, de nouveaux membres peuvent être ajoutés au cluster sans avoir à transférer manuellement les données du cluster vers le serveur au préalable, et cela peut également permettre aux nœuds en retard de rattraper les données plus efficacement.

Le paramètre par défaut de la variable système de réplication de groupe groupreplicationclone_threshold est très élevé (nombre de séquence maximum autorisé de transactions dans GTID), il désactive donc efficacement le clonage chaque fois qu'il est possible de transférer l'état à partir du journal binaire. Pour permettre à la réplication de groupe de sélectionner une opération de clonage distant plus adaptée au transfert d'état, définissez une variable système qui spécifie le nombre de transactions à utiliser comme intervalle de transaction pour le clonage.

PS :

N'utilisez pas de paramètres inférieurs pour groupreplicationclone_threshold dans un cluster actif. Si plus d'un seuil de transaction se produit dans le cluster alors qu'une opération de clonage à distance est en cours, le membre joignant déclenche à nouveau l'opération de clonage à distance après un redémarrage et peut continuer indéfiniment. Pour éviter cela, veillez à définir le seuil sur un nombre fiable supérieur au nombre de transactions attendues dans le cluster pendant la période que prend l'opération de clonage à distance.

Lorsque le transfert d'état ne peut pas être effectué à partir du journal binaire du nœud de démarrage, la réplication de groupe tente d'effectuer une opération de clonage à distance quel que soit le seuil à ce moment-là, par exemple parce que les transactions requises pour rejoindre un membre se trouvent dans le journal binaire de n'importe quel membre. membre du groupe existant Aucun n'est disponible. La réplication de groupe l'identifie en fonction de l'ensemble gtidpurged de membres du groupe existants. La variable système groupreplicationclonethreshold ne peut pas être utilisée pour désactiver le clonage lorsque les transactions requises ne sont pas disponibles dans les fichiers journaux binaires d'un membre, car dans ce cas, le clonage est la seule option pour transférer manuellement les données vers le nœud qui rejoint

3.3 Opération de clonage

Après avoir configuré les nœuds du cluster et rejoint les nœuds pour le clonage, Group Replication gérera les opérations de clonage à distance. L’opération de clonage à distance prend un certain temps, en fonction de la taille des données.

La table performanceschema.cloneprogress enregistre chaque étape de l'ensemble de l'opération de clonage et les informations d'étape correspondantes. Chaque étape générera une ligne d'enregistrements (notez que cette table n'enregistre que les informations de processus d'une opération de clonage. La prochaine fois, l'opération de clonage est effectué, les dernières informations seront écrasées)

select * from clone_progress;
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+-------- 
----+------------+------------+---------------+
| ID | STAGE | STATE | BEGIN_TIME | END_TIME | THREADS | 
ESTIMATE | DATA | NETWORK | DATA_SPEED | NETWORK_SPEED |
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+------- 
-----+------------+------------+---------------+
| 1 | DROP DATA | Completed | 2019-10-08 16:46:58.757964 | 
2019-10-08 16:46:59.128436 | 1 | 0 | 0 | 0 | 0 | 0 |
| 1 | FILE COPY | Completed | 2019-10-08 16:46:59.128766 | 
 2019-10-08 16:47:16.857536 | 8 | 8429731840 | 8429731840 | 
 8430190882 | 0 | 0 |
| 1 | PAGE COPY | Completed | 2019-10-08 16:47:16.857737 | 
 2019-10-08 16:47:17.159531 | 8 | 0 | 0 | 785 | 0 | 0 |
| 1 | REDO COPY | Completed | 2019-10-08 16:47:17.159748 | 
2019-10-08 16:47:17.460516 | 8 | 2560 | 2560 | 3717 | 0 | 0 
|
| 1 | FILE SYNC | Completed | 2019-10-08 16:47:17.460788 | 
2019-10-08 16:47:20.926184 | 8 | 0 | 0 | 0 | 0 | 0 |
| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 |

| 1 | RESTART | Completed | 2019-10-08 16:47:20.926184 | 
2019-10-08 16:47:28.623732 | 0 | 0 | 0 | 0 | 0 | 0 |
| 1 | RECOVERY | Completed | 2019-10-08 16:47:28.623732 | 
2019-10-08 16:47:34.898453 | 0 | 0 | 0 | 0 | 0 | 0 |
+------+-----------+-----------+---------------------------- 
+----------------------------+---------+------------+------- 
-----+------------+------------+---------------+
7 rows in set (0.00 sec)
select * from clone_status\G
*************************** 1. row ***************************
ID: 1
PID: 0
STATE: Completed
BEGIN_TIME: 2019-10-08 16:46:58.758
END_TIME: 2019-10-08 16:47:34.898
SOURCE: 10.10.30.162:3306
DESTINATION: LOCAL INSTANCE
ERROR_NO: 0
ERROR_MESSAGE:
BINLOG_FILE: mysql-bin.000022
BINLOG_POSITION: 222104704
GTID_EXECUTED: 320675e6-de7b-11e9-b3a9-5254002a54f2:1-4,
aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa:1-2771494
1 row in set (0.01 sec)

PS :

Une fois le transfert d'état terminé, la réplication de groupe redémarrera le nœud de connexion pour terminer le processus. Si groupreplicationstartonboot=OFF est défini sur le nœud de jointure, par exemple parce que les informations d'identification de l'utilisateur de réplication ont été spécifiées dans l'instruction START GROUPREPLICATION, START GROUPREPLICATION doit être à nouveau publié manuellement après un redémarrage. Si groupreplicationstartonboot=ON et d'autres paramètres requis pour démarrer la réplication de groupe sont définis dans le fichier de configuration ou à l'aide de l'instruction SET PERSIST, aucune intervention n'est requise et le processus se poursuit automatiquement avec la définition du nœud de jonction à l'état en ligne.

L'opération de clonage à distance clonera divers fichiers de données du répertoire de données du nœud de démarrage vers le nœud de jointure (la table peut contenir des informations de configuration et des données utilisateur, etc.). Cependant, les paramètres d'adhésion à la réplication de groupe enregistrés dans les fichiers de configuration (tels que la configuration de l'adresse locale de réplication de groupe, etc.) ne seront pas clonés et aucune modification ne sera apportée au nœud de jonction. Autrement dit, la configuration liée à la réplication de groupe doit être configurée par vous-même et ne peut pas entrer en conflit avec les membres existants du cluster. L'opération de clonage à distance est uniquement responsable du clonage des fichiers de données et ne clonera pas les informations de configuration (bien sûr, si certaines informations de configuration). est enregistré dans le tableau, pour les opérations de clonage, il sera également cloné en tant que données).

如果远程克隆过程花费很长时间，则在MySQL 8.0.22之前的发行版中，在该时间段内为该集群累积的一组认证信息可能会变得太大而无法传输给加入成员。在这种情况下，加入成员会记录一条错误消息，并且不会加入该集群。从MySQL 8.0.22开始，组复制以不同的方式管理应用事务的垃圾收集过程，以避免发生这种情况。在早期版本中，如果确实看到此错误，则在远程克隆操作完成之后，请等待两分钟，以允许进行一轮垃圾收集，以减小集群的认证信息的大小。然后在加入成员上发出以下声明，以使其停止尝试应用先前的认证信息集：

RESET SLAVE FORCHANNEL group_replication_recovery;
RESET REPLICA FOR CHANNEL group_replication_recovery;（从8.0.22开始）

引导节点中用于组复制专用通道groupreplicationrecovery的用户凭证（复制用户和密码），在克隆操作完成之后，会被新成员使用，所以，该用户和密码及其权限必须在新成员中也有效。因此，所有组成员才能够使用相同的复制用户和密码通过远程克隆操作接收状态传输进行分布式恢复。但是，组复制会保留与使用SSL相关的组复制通道设置，这些设置对单个成员来说可以是惟一的（即，每个组成员使用不同的复制用户和密码）。如果使用了PRIVILEGECHECKSUSER帐户来帮助保护复制应用线程（从MySQL8.0.18开始，可以创建一个具有特定权限的用户账号，然后将其指定为PRIVILEGECHECKSUSER帐户，这样可以防止将未经授权或意外将具有特权的账号用于组复制通道），则在克隆操作完成之后新加入成员不会使用该用户帐户作为组复制通道的用户。此时必须为组复制通道手工指定合适的复制用户。

如果引导节点用于groupreplicationrecovery复制通道的复制用户凭据已使用CHANGE MASTER TO语句存储在复制元数据存储库中，则在克隆后将它们转移到加入成员并由其使用，并且它们在此处必须有效。因此，使用存储的凭据，所有通过远程克隆操作接收状态转移的组成员都会自动接收复制用户和密码，进行分布式恢复。如果在START GROUPREPLICATION语句上指定了复制用户凭据，则这些凭据将用于启动远程克隆操作，但是在克隆后它们不会传输到加入节点并由其使用。如果不希望将凭据转移到新的server上并记录在那里，确保在进行远程克隆操作之前取消设置它们，并使用START GROUPREPLICATION代替提供它们。

ps:如果已使用PRIVILEGECHECKSUSER帐户来帮助保护复制应用程序，则从MySQL 8.0.19开始，会将PRIVILEGECHECKSUSER帐户以及来自引导节点的相关设置克隆出来。如果将加入节点设置为在启动时启动组复制，它将自动使用该帐户在相应的复制通道上进行权限检查。（在MySQL 8.0.18中，由于许多限制，建议不要将PRIVILEGECHECKSUSER帐户用于组复制通道。）

3.4克隆的其他用处

组复制启动并管理用于分布式恢复的克隆操作。设置为支持克隆的组成员也可以参与用户手动启动的克隆操作。例如，可能希望通过从组成员作为引导节点来进行克隆来创建新的MySQL实例，但是不希望新的服务器实例立即加入或可能永远不会加入该集群。

在所有支持克隆的发行版中，可以手动启动涉及停止了组复制的组成员的克隆操作。由于克隆要求引导节点和接收数据的节点上的克隆插件必须匹配，因此即使不希望该实例加入集群，也必须在另一个实例上安装并激活组复制插件。可以通过发出以下语句来安装插件：

INSTALL PLUGIN group_replication SONAME'group_replication.so';

在MySQL 8.0.20之前的发行版中，如果操作涉及正在运行“组复制”的组成员，则无法手动启动克隆操作。从MySQL8.0.20开始，只要克隆操作不会删除和替换接收者上的数据，就可以执行此操作。因此，如果正在运行组复制，则用于启动克隆操作的语句必须包含DATA DIRECTORY子句。

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!