MySQL Replication White Paper FR

Rplication MySQL
Amlioration de l'volutivit et de la disponibilit avec MySQL 5.5
Livre blanc technique MySQL par Oracle Octobre 2010
Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.
Page 1 sur 32
TABLE DES MATIRES

1 INTRODUCTION ...............................................................................................................................5 2 PRINCIPES FONDAMENTAUX DE LA RPLICATION ...................................................................5 RPLICATION ASYNCHRONE ..........................................................................................................6 RPLICATION SYNCHRONE .............................................................................................................7 RPLICATION SEMI-SYNCHRONE ...................................................................................................7 RPLICATION PAR INSTRUCTION...................................................................................................7 RPLICATION PAR LIGNE ................................................................................................................8 RPLICATION EN FORMAT MIXTE ..................................................................................................8 3 LISTE DES MODIFICATIONS APPORTES LA RPLICATION DANS MYSQL 5.5 ..................8 4 CAS D'UTILISATION DE LA RPLICATION ...................................................................................9 DPLOIEMENT HORIZONTAL ..........................................................................................................9 HAUTE DISPONIBILIT ..................................................................................................................10 RPLICATION GOGRAPHIQUE ....................................................................................................10 SAUVEGARDE DE BASE DE DONNES ........................................................................................11 ANALYSES .......................................................................................................................................11 5 TOPOLOGIES DE RPLICATION ..................................................................................................12 MATRE VERS ESCLAVE ................................................................................................................13 MATRE VERS PLUSIEURS ESCLAVES.........................................................................................13 MATRE VERS ESCLAVE(S) VERS ESCLAVE(S) ..........................................................................13 MATRE VERS MATRE (PLUSIEURS MATRES)...........................................................................13 MATRES MULTIPLES VERS ESCLAVE (SOURCE MULTIPLE) ...................................................14
Page 2 sur 32
6 RPLICATION DE FLUX DE TRAVAIL INTERNE .........................................................................14 THREADS DE RPLICATION ..........................................................................................................14 THREAD BINLOG DUMP .................................................................................................................15 THREAD I/O ESCLAVE ....................................................................................................................15 THREAD SQL ESCLAVE ..................................................................................................................15 RPLICATION DE FICHIERS JOURNAUX ......................................................................................15 LE JOURNAL DE RELAIS ................................................................................................................15 MASTER.INFO ..................................................................................................................................15 RELAY-LOG.INFO ............................................................................................................................15 7 CONFIGURATION DE LA RPLICATION MYSQL ........................................................................16 TAPE 1: CONFIGURER LES FICHIERS CNF DU MATRE ET DE L'ESCLAVE ...........................16 TAPE 2: CRER UN UTILISATEUR DE RPLICATION ................................................................17 TAPE 3: VERROUILLER LE MATRE, NOTER LA POSITION DU BINLOG ET SAUVEGARDER LA BASE DE DONNES MATRE ......................................................................................................18 TAPE 4: CHARGER LE FICHIER DE VIDAGE SUR L'ESCLAVE .................................................18 TAPE 5: INITIALISER LA RPLICATION .......................................................................................19 TAPE 6: VRIFICATIONS DE BASE ..............................................................................................19 8 MIGRATION VERS UNE RPLICATION SEMI-SYNCHRONE ......................................................19 TAPE 1: INSTALLER LES PLUG-INS SUR LE MATRE ET L'ESCLAVE .....................................20 TAPE 2: ACTIVER LA RPLICATION SEMI-SYNCHRONE ..........................................................20 A. CONFIRMER QUE LA RPLICATION EST EXCUTE EN MODE SEMI-SYNCHRONE ..........20 9 ADMINISTRATION ET DPANNAGE DE LA RPLICATION ......................................................21 VRIFICATION DE L'TAT DE LA RPLICATION .........................................................................21
Page 3 sur 32
SUSPENSION DE LA RPLICATION ..............................................................................................22 AFFICHAGE DES JOURNAUX BINAIRES ......................................................................................22 10 REPRISE APRS CHEC ET RCUPRATION ........................................................................23 TAPE 1: CONDITIONS PRALABLES ...........................................................................................23 TAPE 2: DTECTER SI LE MATRE A CHOU ...........................................................................25 A. SUSPENDRE LES CRITURES VERS LE MATRE ....................................................................25 B. PROMOUVOIR L'ESCLAVE EN MATRE .....................................................................................26 C. REDIRIGER LES CRITURES VERS LE NOUVEAU MATRE UNE FOIS LE JOURNAL DE RELAIS APPLIQU ............................................................................................................................27 D. SYNCHRONISER LE MATRE CHOU AVEC LE NOUVEAU MATRE ...................................27 11 DIFFRENCES LORS D'UNE RPLICATION AVEC MYSQL CLUSTER..................................28 12 SURVEILLANCE DE LA RPLICATION AVEC MYSQL ENTERPRISE MONITOR ...........................................................................................................................................30 13 CONCLUSION ..............................................................................................................................32 14 RESSOURCES .............................................................................................................................32
Page 4 sur 32
1 Introduction
La rplication MySQL a t largement dploye par certains sites internet leader sur le Web et dans les entreprises pour fournir des niveaux extrmes d'volutivit de base de donnes. Les utilisateurs peuvent crer aisment et rapidement plusieurs rpliques de leur base de donnes afin d'effectuer un dploiement horizontal souple et s'manciper des contraintes en capacit d'une instance unique. Ils peuvent ainsi rpondre rapidement aux charges de travail croissantes de base de donnes. La rplication sert galement de point de dpart pour offrir des services de base de donnes hautement disponibles, en offrant un moyen de mettre en miroir les donnes sur plusieurs htes pour rpondre aux dfaillances de systmes individuels. De plus, de nombreux utilisateurs rpliquent des donnes dans des systmes ddis aux fonctions de sauvegarde ou d'analyse de donnes afin d'utiliser les ressources plus efficacement en dchargeant ces tches de leurs serveurs de production. Avec la publication de MySQL 5.5, plusieurs amliorations ont t apportes la rplication MySQL, qui offrent des niveaux suprieurs d'intgrit des donnes, de performance et de flexibilit dans les applications. Nous prsentons ces amliorations dans le livre blanc (au moment de la rdaction de ces lignes, MySQL 5.5 est disponible uniquement en version Candidate). Nous examinons galement les avantages du dploiement de la rplication MySQL d'un point de vue commercial et technique, nous prsentons les principes fondamentaux de la technologie sur laquelle repose la rplication et nous fournissons un simple guide pas--pas d'installation et de configuration d'une topologie matre/esclave, et de gestion des vnements de reprise aprs chec. En conclusion, ce livre souligne les principales essentielles de l'utilisation de la rplication avec la base de donnes MySQL Cluster.
2 Principes fondamentaux de la rplication

Pour les besoins de ce livre, nous dfinissons rplication comme la duplication des donnes vers un ou plusieurs emplacements. Dans les sections suivantes, nous prsentons ce qui diffrencie les diffrents types de rplication les plus populaires. La rplication permet une base de donnes de copier ou de dupliquer des changements d'un emplacement physique ou d'un systme vers un autre (gnralement depuis un systme matre vers un systme esclave ). Elle permet gnralement d'accrotre la disponibilit et l'volutivit d'une base de donnes, bien que souvent les utilisateurs excutent aussi des oprations de sauvegarde ou des requtes d'analyse sur les systmes esclaves, dchargeant ainsi ces fonctions des systmes matres. MySQL prend en charge en natif la rplication en tant que fonctionnalit standard de la base de donnes. Selon la configuration, vous pouvez rpliquer toutes les bases de donnes, une slection de bases de donnes ou mme des tables slectionnes dans une base de donnes. La rplication MySQL fonctionne simplement avec un serveur agissant en tant que matre et un ou plusieurs serveurs agissant en tant qu'esclaves. Le serveur matre consigne les changements dans la base de donnes. Une fois ces modifications consignes, elles sont envoyes vers le ou les esclaves, puis appliques immdiatement ou aprs un dlai dfini.
Page 5 sur 32
Figure 1 La rplication MySQL prend en charge la haute disponibilit et l'volutivit en lecture prtes l'emploi L'utilisation de la rplication MySQL permet de dployer horizontalement d'importantes fermes de serveurs Web dans lesquelles les lectures (SELECTs) reprsentent la majeure partie des oprations effectues dans la base de donnes. Les esclaves reprsentent une charge de travail infime sur les serveurs matres (gnralement 1 % de charge de travail par esclave). Il n'est pas rare d'avoir 30 esclaves dploys par matre dans les sites Web importants1.
Rplication asynchrone
MySQL prend en charge en natif la rplication sens unique, asynchrone. La rplication asynchrone signifie que les donnes sont copies d'une machine une autre, entranant un dlai dans la copie des modifications de donnes. Les donnes risquent surtout de ne pas tre copies vers / appliques l'esclave, lorsque la validation de la transaction est confirme l'application. Ce dlai dpend souvent de la bande passante rseau, de la disponibilit des ressources et de la charge du systme. Cependant, avec les composants et un rglage appropris, la rplication ellemme peut sembler presque instantane pour de nombreuses applications.
Figure 2 Rplication asynchrone et synchrone
Pour consulter un exemple de topologies de rplication MySQL complexes, reportez-vous la documentation relative Ticketmaster dans la section Ressources
Page 6 sur 32
Rplication synchrone
La rplication synchrone correspond la validation simultanment des donnes sur une ou plusieurs machines, gnralement connue sous le nom validation deux phases . Cette rplication permet d'optimiser la cohrence entre plusieurs systmes, mais l'augmentation des messages pnalise les performances. Avec les moteurs de stockage InnoDB ou MyISAM, MySQL ne prend pas en charge en natif la rplication synchrone. Il existe toutefois des technologies, telles que Distributed Replicated Block Device ou DRBD, qui fournissent une rplication synchrone du systme de fichiers sous-jacent permettant un deuxime serveur MySQL de prendre le relais ( l'aide de cette deuxime copie) en cas de perte de la copie/du serveur initial. Pour plus d'informations, reportez-vous : http://www.drbd.org/ Si vous utilisez MySQL Cluster, les donnes sont rpliques de faon synchrone entre les nuds de donnes dans le Cluster (site), puis de faon asynchrone entre des Clusters gographiquement spars.
Rplication semi-synchrone
La rplication semi-synchrone est une nouvelle fonctionnalit de MySQL 5.5 (au moment de la rdaction de ces lignes, MySQL 5.5 est une version Candidate). Cela signifie que si la rplication semi-synchrone est active sur le matre et qu'un esclave semi-synchrone au moins est configur, un thread excute une validation de transaction sur les blocs matres une fois la validation applique localement et attend jusqu' ce qu'un esclave semi-synchrone au moins renvoie au matre la confirmation de rception de tous les vnements associs la transaction, ou jusqu' une expiration. En cas d'expiration, le matre valide transaction mais rtablit le mode asynchrone. En utilisant la rplication asynchrone, si le matre tombe en panne, il n'est pas possible de savoir immdiatement si les transactions valides par le matre ont t rpliques sur l'esclave. Par consquent, une reprise d'un matre vers un esclave peut entraner une reprise partir d'un serveur qui ne contient pas toutes les transactions relatives au matre. La rplication semisynchrone rduit le risque de transactions orphelines sur le serveur matre, car toutes les transactions valides ont t reues par l'esclave. En d'autres termes, pour tout client thread, les modifications effectues sur le matre lors de sa transaction en cours sont perdues (le client doit ressayer), mais toutes les modifications de transactions, dont la validation a t confirme, sont prserves. La rplication semi-synchrone a un impact sur les performances car les validations sont plus lentes en raison de la ncessit d'attendre les esclaves. Il s'agit de la contrepartie de l'augmentation de l'intgrit des donnes. Le ralentissement correspond au moins au dlai TCP/IP aller-retour d'envoi de la validation l'esclave, d'enregistrement par l'esclave dans son journal de relais et d'attente de l'accus de rception de l'esclave. Par consquent, la rplication semi-synchrone est plus efficace avec des serveurs physiquement colocaliss qui communiquent via des rseaux rapides. La rplication semi-synchrone n'est pas disponible actuellement pour les tables utilisant le moteur de stockage MySQL Cluster.
Rplication par instruction

Par dfaut, MySQL exploite la rplication par instruction lorsque les instructions SQL (pas les modifications de donnes) sont rpliques partir du matre vers le ou les esclaves. La rplication par instruction est incluse dans MySQL server depuis la version 3.23. L'un des avantages de la rplication par instruction est la rduction, dans certains cas, de la quantit des donnes crites dans les fichiers journaux, par exemple lorsque des mises jour ou
Page 7 sur 32
des suppressions affectent de nombreuses lignes. Pour des instructions simples qui affectent quelques lignes seulement, la rplication par ligne peut occuper moins d'espace. La rplication par instruction prsente toutefois quelques inconvnients, notamment l'absence de prise en charge des instructions au comportement non dterministe, par exemple une fonction d'heure actuelle.
Rplication par ligne

Introduite par la version MySQL 5.1, la rplication par ligne consigne les modifications dans des lignes de table individuelles, contrairement aux instructions. Avec la rplication par ligne, le matre crit des messages, galement connus en tant qu'vnements dans le journal binaire, qui indiquent comment les lignes de table individuelles ont t modifies. Elle s'apparente aux formes plus traditionnelles de rplication incluses dans d'autres RDMS. Gnralement, la rplication par ligne ncessite moins de verrous sur le matre et l'esclave, ce qui permet d'atteindre un niveau de concurrence plus lev. L'un des inconvnients de la rplication par ligne est qu'elle gnre habituellement un volume de donnes consigner plus important. Par exemple, une instruction qui modifie 100 lignes dans une table reprsente 100 changements consigner avec la rplication par ligne, alors qu'avec la rplication par instruction seule l'instruction SQL doit tre rplique. Avant la version MySQL 5.5, les types de colonne devaient tre identiques sur le matre et l'esclave lors de l'utilisation de la rplication par ligne. Depuis la version 5.5, vous pouvez autoriser ou non le type promotion et/ou rtrogradation, ou imposer le contrle de type strict. Si MySQL Cluster est utilis, la rplication par ligne doit tre utilise.
Rplication en format mixte

Depuis la version MySQL 5.1.8, le format de journalisation binaire peut tre modifi en temps rel, selon l'vnement consigner, en utilisant la journalisation en format mixte. Avec le format mixte activ, la rplication par instruction est utilise par dfaut, mais elle bascule automatiquement vers une rplication par ligne dans certaines conditions, par exemple : Une instruction DML met jour une table MySQL Cluster Une instruction contient un objet UUID() Deux tables ou plus avec des colonnes AUTO_INCREMENT sont mises jour Un INSERT DELAYED est excut, quel qu'il soit Lorsque le contenu d'une vue ncessite la rplication par ligne, l'instruction qui cre la vue l'utilise galement, par exemple lorsque l'instruction crant une vue utilise la fonction UUID() Un appel une fonction dfinie par l'utilisateur (UDF) est effectu Pour consulter la liste complte des conditions, visitez : http://dev.mysql.com/doc/refman/5,1/en/binary-log-mixed.html
3 Liste des modifications apportes la rplication dans MySQL 5.5

MySQL 5.5 apporte plusieurs amliorations la rplication, rpertories ci-aprs dans cette section. Certaines amliorations sont dveloppes plus loin dans ce document. Rplication semi-synchrone : amlioration de la rsilience, avec le matre qui attend que l'esclave conserve des vnements. Rglage fsync de l'esclave et rcupration automatique des journaux de relais : option permettant de grer l'criture des journaux de relais sur le disque, sans dpendre du comportement par dfaut du systme d'exploitation. Dfinissez sync_relay_log=1 pour vous assurer qu'une instruction ou transaction au maximum est manquante dans le journal de relais aprs un incident. L'esclave peut dsormais reprendre partir de
Page 8 sur 32
journaux de relais corrompus en demandant au matre de renvoyer les entres corrompues. Trois nouvelles options sont introduites (sync-master-info, sync-relay-log et sync-relay-log-info). Leur utilisation est prsente dans le manuel de rfrence MySQL l'adresse http://dev.mysql.com/doc/refman/5.5/en/replication-optionsslave.html#sysvar_sync_master_info. Heartbeat de rplication : vrifie automatiquement l'tat de la connexion entre le matre et le ou les esclave(s) grce un dispositif de dtection des dfaillances plus prcis. Elle peut dtecter une perte de connexion en millisecondes (configurable) et vite toute rotation inutile de journal de relais lorsque le matre est inactif. Filtrage de rplication par serveur : lorsqu'un serveur est supprim d'un anneau de rplication, un serveur restant peut tre slectionn pour supprimer ses messages de rplication en attente, une fois appliqus par tous les serveurs. Conversions de type esclave prcises : permet d'utiliser diffrents types sur le master et sur l'esclave, avec un type de promotion et de rtrogradation automatique lors de l'utilisation de la rplication par ligne (dj possible avec la rplication par instruction). Vidage de journal individuel : vidage slectif des journaux de serveurs lors de l'utilisation de 'FLUSH LOGS' pour un contrle accru. Journalisation scurise des transactions mixtes : rplication des transactions contenant les modifications InnoDB et MyISAM
4 Cas d'utilisation de la rplication

Vous pouvez rpliquer vos donnes d'un serveur MySQL un autre pour de nombreuses raisons, tant techniques que commerciales. Dans cette section, nous explorons divers cas d'utilisation et scnarios d'application dans lesquels la rplication MySQL peut tre utile.
Dploiement horizontal
Il s'agit de la situation la plus frquente justifiant la mise en uvre d'une rplication pour les utilisateurs. Dans une topologie de dploiement horizontal, l'objectif principal est de distribuer la charge de travail sur un ou plusieurs serveurs esclaves afin d'amliorer les performances. Les utilisateurs peuvent crer aisment et rapidement plusieurs rpliques de leur base de donnes afin d'effectuer un dploiement horizontal souple et s'manciper des contraintes en capacit d'une instance unique. Ils peuvent ainsi rpondre rapidement aux charges de travail croissantes de base de donnes. Il s'oppose au dploiement vertical, qui consiste augmenter les ressources (gnralement la mmoire vide et le processeur) sur la machine existante. Le dploiement vertical peut tre associ une approche verticale de type chariot lvateur visant rpondre des besoins accrus en capacit. Dans une architecture de dploiement horizontal, les lectures et les critures sont partages entre le serveur matre et le ou les serveurs esclaves.
Page 9 sur 32
Figure 3 Dploiement horizontal avec la rplication MySQL Plus prcisment, toutes les critures (UPDATE, INSERT, DELETE) sont envoyes au matre pour excution, et les lectures (SELECT) sont diriges vers un ou plusieurs esclaves. La charge de travail de lecture, prcdemment excute sur le serveur matre, peut ainsi exploiter les ressources disponibles sur le ou les serveurs esclaves. Le dploiement horizontal permet une utilisation plus efficace des ressources en distribuant la charge de travail entre plusieurs serveurs. La sparation des lectures et des critures peut tre gre dans diffrentes couches du systme, par exemple au sein de l'application (elle gre les connexions tous les serveurs et choisit d'utiliser une connexion vers le matre ou vers les esclaves) ou dans le connecteur de base de donnes. Par exemple, si vous utilisez un connecteur JDBC de MySQL (Connector/J), lors de la connexion la base de donnes, vous pouvez indiquer plusieurs serveurs dans la chane de connexion, en commenant par le matre suivi des esclaves. Si nous prenons la configuration illustre dans la Figure 10 ( noir est le matre, bleu et vert sont les esclaves), l'application peut se connecter la base de donnes clusterdb en utilisant la chane de connexion jdbc:mysql:replication://black,blue,green/clusterdb . Une fois connect de cette faon, Connector/J achemine les transactions vers le serveur appropri (matre/esclave) en fonction de la valeur de l'attribut ReadOnly de la connexion (demand l'aide de connection.getReadOnly() et crit l'aide de connection.setReadOnly(bool)). Comme la rplication est asynchrone, si l'application ncessite une opration en lecture seule pour s'assurer d'utiliser les toutes dernires valeurs de la base de donnes, elle doit l'envoyer au matre plutt qu'aux esclaves. Dans le cas de Connector/J, cela implique l'excution de connection.setReadOnly(false).
Haute disponibilit
Dans ce scnario, l'ide est de rpliquer les modifications depuis un serveur matre vers un esclave afin de basculer sur le serveur esclave en cas de dconnexion du matre suite une erreur, un incident ou pour effectuer une maintenance. Comme pour le dploiement horizontal, la slection du serveur appropri peut tre mise en uvre de diffrentes faons. Par exemple, si vous utilisez Connector/J avec la configuration illustre dans la Figure 9 ( noir est le matre et bleu est l'esclave), l'application peut utiliser jdbc:mysql://black,blue/clusterdb comme chane de connexion. Connector/J envoie ensuite toutes les oprations vers noir tant qu'il est disponible, puis bascule vers bleu lorsqu'il n'est pas disponible.
Rplication gographique
Avec la rplication gographique, l'objectif est de rpliquer des donnes entre deux emplacements gographiquement distincts, gnralement trs loigns. La rplication asynchrone est la solution la plus adapte dans ce scnario bas sur l'impact potentiel de la
Page 10 sur 32
latence du rseau. Par exemple, les donnes d'une agence centrale Paris sont rpliques vers une agence rgionale Marseille, autorisant ainsi des requtes d'excution partir d'un magasin de donnes local. Cette approche est galement idale pour mettre en uvre la rcupration d'urgence en cas de catastrophe sur l'un des sites (par exemple une panne lectrique ou une catastrophe naturelle).
Figure 4 Rplication pour redondance gographique
Sauvegarde de base de donnes

Pour viter toute dtrioration des performances ou verrouillage qu'une sauvegarde sur le matre peut engendrer, vous pouvez excuter la place la sauvegarde sur le serveur esclave. Notez que les sauvegardes en ligne peuvent tre excutes sur la base de donnes matre en utilisant MySQL Cluster.
Analyses
De nombreuses requtes d'informatique dcisionnelle ou d'analyse peuvent tre exigeantes en ressources et ncessiter des dlais d'excution importants. Pour rpondre ces requtes d'analyses, il est possible de crer des esclaves. Dans cette configuration, l'excution des requtes n'a aucun impact sur les performances du matre. Cette mthode peut se rvler trs utile avec MySQL Cluster qui est idal pour les applications utilisant principalement une Cl Primaire base sur les lectures et critures, mais dont l'excution peut tre lente avec des requtes trs complexes sur de vastes ensembles de donnes. Il suffit de rpliquer les donnes MySQL Cluster vers un deuxime moteur de stockage (gnralement MyISAM ou InnoDB), puis de gnrer vos rapports cet emplacement. Cette action peut tre excute tout en rpliquant des donnes vers un site MySQL Cluster distant pour une redondance gographique, comme illustre dans la Figure 5 ci-dessous.
Page 11 sur 32
Figure 5 Cas d'utilisation d'association de rplications
5 Topologies de rplication
MySQL prend en charge diverses topologies de rplication. Nous prsentons ci-dessous certaines de ces topologies et d'autres prises en charge avec des restrictions.
Figure 6 Topologies de rplication MySQL courantes
Matre vers esclave

Cette topologie est la plus populaire et la plus facile en termes de configuration et d'administration. Elle implique deux serveurs, un matre et un esclave. Toutes les critures sont excutes sur le matre et les lectures peuvent tre partages entre le matre et l'esclave.
Matre vers plusieurs esclaves

Dans ce scnario, plusieurs esclaves sont associs un seul matre. Cette topologie offre un degr de dploiement horizontal suprieur contre une administration accrue.
Page 12 sur 32
Matre vers esclave(s) vers esclave(s)

Cette configuration est une extension d'une configuration matre/esclave ou matre/esclaves. Dans ce cas, un ou plusieurs esclaves supplmentaires sont associs l'esclave dj associ au serveur matre d'origine. En ralit, le ou les esclaves au centre de cette configuration agissent la fois comme matre et comme esclave. Dans cette configuration, toutes les critures sont excutes sur le matre principal.
Matre vers matre (plusieurs matres)

Dans une configuration matre/matre, deux serveurs sont associs dans une chane et sont rciproquement matres et esclaves. Cette configuration permet d'crire indiffremment sur l'un ou l'autre systme, mais comme la modification va tre rplique, le degr de complexit dans l'installation, la configuration et l'administration augmente de faon importante. De plus, sauf si vous utilisez MySQL Cluster, il n'existe pas de dtection ni de rsolution des conflits. Par consquent, l'application doit s'assurer de ne pas mettre jour une ligne sur un serveur alors qu'une modification apporte la mme ligne sur l'autre serveur n'est pas encore rplique. Il est galement possible d'organiser plusieurs serveurs MySQL en anneau pour augmenter les niveaux d'volutivit et de performance ( condition que l'application vite d'envoyer des mises jour conflictuelles vers la mme ligne sur diffrents serveurs). MySQL 5.5 prsente une nouvelle fonctionnalit de filtrage qui permet de mieux grer les checs sur un serveur alors que la rplication de ses mises jour est en cours vers les autres serveurs de l'anneau.
Figure 7 Anneau matres multiples Lors de l'utilisation de la rplication matres multiples avec des colonnes d'auto-incrmentation, vous devez utiliser les paramtres auto_increment_offset et auto_increment_increment sur chaque serveur pour vous assurer qu'aucune valeur en double n'est affecte. Un exemple pour 2 serveurs (noir et bleu) est illustr dans la Table 1 ci-dessous. Serveur noir bleu auto_increment_increment 2 2 auto_increment_offset 1 2 Valeurs 1,3,5 2,4,6
Table 1 Eviter les valeurs d'auto incrmentation conflictuelles
Matres multiples vers esclave (source multiple)

Cette topologie de rplication n'est pas prise en charge actuellement par MySQL. Dans une configuration matres multiples, un esclave sert deux matres principalement, en d'autres termes il rplique les modifications partir de plusieurs matres. MySQL Cluster permet plusieurs serveurs MySQL d'crire sur le mme Cluster. Par consquent, il est possible de configurer cette fonctionnalit (alors que chaque serveur MySQL est l'esclave d'un seul matre) si elle est requise pour une application approprie.
Page 13 sur 32
6 Rplication de flux de travail interne

Avec la rplication MySQL, le matre crit des mises jour dans ses fichiers journaux binaires et gre un index de ces fichiers afin de conserver une trace de la rotation des journaux. Les fichiers journaux binaires servent de registre de mises jour envoyer aux serveurs esclaves. Lorsqu'un esclave se connecte son matre, il dtermine la dernire position lue dans les journaux en fonction de sa dernire mise jour russie. L'esclave reoit ensuite toutes les mises jour qui ont eu lieu depuis cette date. L'esclave se bloque par la suite et attend que le matre l'informe de nouvelles mises jour. Une illustration simple de ces concepts est prsente dans la Figure 8 cidessous.
Figure 8 Mise en uvre de la rplication MySQL
Threads de rplication
Plusieurs threads sont utiliss pour mettre en uvre la rplication de mises jour depuis le matre vers le ou les esclaves. Chaque thread est dcrit dans cette rubrique. Si vous utilisez MySQL Cluster, un thread supplmentaire est impliqu. Pour plus d'informations, reportez-vous la section 11.
Thread Binlog Dump

Le matre cre ce thread pour envoyer le contenu du journal binaire l'esclave. Le thread Binlog Dump acquiert un verrou dans le journal binaire du matre pour lire chaque vnement envoyer l'esclave. Ds que l'vnement est lu, le verrou est annul, mme avant que l'vnement ne soit envoy l'esclave. Un matre auquel plusieurs esclaves sont raccords cre un thread de vidage binlog pour chaque esclave actuellement connect, chaque esclave disposant de ses propres threads I/O et SQL.
Thread I/O esclave

Lorsqu'une instruction START SLAVE est mise sur l'esclave, elle cre un thread I/O qui se connecte au matre et lui demande d'envoyer les mises jour enregistres dans ses journaux binaires. Le thread I/O esclave lit ensuite les mises jour que le thread de vidage binlog du matre envoie, puis les copie localement sur l'esclave en tant que journaux de relais dans le rpertoire de donnes de l'esclave.
Page 14 sur 32
Thread SQL esclave

L'esclave cre ce thread pour lire les journaux de relais crits par le thread I/O esclave, et excute les mises jour contenues dans les journaux de relais.
Rplication de fichiers journaux

Durant la rplication, le serveur MySQL cre plusieurs fichiers qui sont utiliss pour conserver le journal binaire relay depuis le matre, et enregistre les informations relatives l'tat et l'emplacement actuel dans le journal relay. Trois types de fichiers sont utiliss dans le processus par l'esclave :
le journal de relais
Le journal de relais sur l'esclave contient des vnements qui ont t lus sur le journal binaire du matre. Les vnements dans le journal binaire sont finalement excuts sur l'esclave par son thread SQL.
master.info
Les informations relatives l'tat et la configuration actuelle de l'esclave se situent dans le fichier master.info. Ce fichier contient les informations de connectivit de rplication de l'esclave, y compris le nom d'hte du matre, les identifiants de connexion utiliss et la position actuelle de l'esclave dans le journal binaire du matre.
relay-log.info
Les informations d'tat relatives au point d'excution dans le journal de relais de l'esclave se situent dans le fichier relay-log.info. Le journal binaire et le fichier d'index associ, pour le suivi de toutes les mises jour rpliquer, se situent sur le matre.
7 Configuration de la rplication MySQL

Dans cette section, nous prsentons une mthode de configuration de la rplication MySQL. Cette procdure est crite pour la configuration d'un esclave unique, mais peut tre rpte pour configurer plusieurs esclaves. Pour les besoins de ce guide, nous supposons que vous avez tlcharg et install avec succs au moins deux serveurs MySQL. Remarque au sujet de l'exemple Pour les besoins de ce document, nous avons configur deux serveurs MySQL 5.5 qui jouent les rles suivants : Matre Nom d'hte : noir IP : 192.168.0.31 Esclave Nom d'hte : bleu IP : 192.168.0.34
Page 15 sur 32
Figure 9 Configuration utilise pour l'exemple de procdure Nous supposons que vous utilisez le moteur de stockage InnoDB. Pour comprendre les diffrences avec le moteur de stockage MySQL Cluster (NDB), dot de fonctions supplmentaires, reportez-vous au chapitre 11. Pour prsenter les cas les plus complexes dans cet exemple, nous supposons que le serveur MySQL utiliser en tant que matre est dj excut et qu'il contient des donnes rpliquer vers le nouvel esclave. Si vous commencez avec des donnes vides, vous pouvez ignorer les tapes 3 et 4. Compatibilit Si vous tentez de configurer une rplication entre deux serveurs MySQL dj installs, assurezvous que les versions MySQL installes sur le matre et l'esclave sont compatibles. Pour consulter la liste de versions compatibles actuelle, visitez : http://dev.mysql.com/doc/refman/5.5/en/replication-compatibility.html
tape 1: Configurer les fichiers cnf du matre et de l'esclave

La premire tape de configuration de la rplication permet de modifier le fichier my.cnf sur les serveurs utiliss en tant que matre et esclave. Une valeur par dfaut est fournie avec l'installation MySQL. Nous fournissons toutefois des fichiers locaux de configuration master.cnf et slave.cnf , utiliser au dmarrage des serveurs MySQL si une base de donnes MySQL de production est dj excute sur ces serveurs. Au minimum, nous souhaitons ajouter deux options la section [mysqld] du fichier master.cnf :
log-bin : dans cet exemple, nous choisissons black-bin.log server-id : dans cet exemple, nous choisissons 1. Le serveur ne peut pas agir en tant que matre si la journalisation binaire n'est pas active. La variable server_id doit tre un nombre entier positif comprise entre 1 to 232
master.cnf :
[mysqld] server-id=1 log-bin=black-bin.log datadir=/home/billy/mysql/master/data innodb_flush_log_at_trx_commit=1 sync_binlog=1
Remarque : Pour optimiser la durabilit et la cohrence dans la configuration d'une rplication utilisant InnoDB avec les transactions, vous devez galement spcifier les options innodb_flush_log_at_trx_commit=1, sync_binlog=1. Vous devez ensuite ajouter l'option server-id la section [mysqld] du fichier slave.cnf de l'esclave. La valeur server-id, comme la valeur master_id, doit tre un nombre entier positif compris entre 1 et 2 - 1. Il est galement ncessaire que l'ID de l'esclave soit diffrent de celui du matre. Si vous
Page 16 sur 32
configurez plusieurs esclaves, chacun doit avoir une valeur server-id unique, distincte de celle du matre et des autres esclaves. Les valeurs server-id peuvent tre compares des adresses IP : ces ID identifient de manire unique chaque instance de serveur dans la communaut des serveurs de rplication. Vous pouvez galement dfinir les noms de fichiers utiliser par l'esclave en dfinissant relaylog-index et relay-log. slave.cnf :
[mysqld] server-id=2 relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin datadir=/home/billy/mysql/slave/data
A prsent, redmarrez les serveurs MySQL l'aide du gestionnaire de services ou directement partir de la ligne de commande s'ils ne sont pas excuts en tant que services :
[billy@black ~]$ mysqladmin -u root shutdown # only needed if MySQL already running [billy@black ~]$ mysqld --defaults-file=/home/billy/mysql/master/master.cnf & [billy@blue ~]$ mysqladmin -u root shutdown # only needed if MySQL already running [billy@blue ~]$ mysqld --defaults-file=/home/billy/mysql/slave/slave.cnf&
Remarque : Si l'esclave a dj effectu une rplication prcdemment, dmarrez le serveur esclave avec l'option i--skip-slave-start pour qu'il ne tente pas de se connecter immdiatement au matre. Vous pouvez galement dmarrer le serveur esclave avec l'option --log-warnings pour recevoir dans le journal d'erreurs davantage de messages concernant les problmes (par exemple, des problmes rseau ou de connexion). Cette option est active par dfaut, mais les connexions abandonnes sont consignes dans le journal d'erreurs uniquement si la valeur de l'option est suprieure 1.
tape 2: Crer un utilisateur de rplication

L'tape suivante de la configuration de la rplication permet de crer un compte sur le matre utilis exclusivement pour la rplication. Pour plus de scurit, il est vivement recommand de crer un utilisateur de rplication ddi et d'viter ainsi d'accorder des privilges supplmentaires, en plus des permissions de rplication. Crez un compte sur le serveur matre que le serveur esclave peut utiliser pour se connecter. Comme indiqu, le privilge REPLICATION SLAVE doit tre accord ce compte. Vous pouvez excuter GRANT dans le client MySQL ou dans votre outil d'administration MySQL favori :
[billy@black ~]$ mysql -u root --prompt='master> ' master> CREATE USER repl_user@192.168.0.34; master> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';
tape 3: Verrouiller le matre, noter la position du Binlog et sauvegarder la base de donnes matre
Sur le matre, videz toutes les tables et instructions d'criture de blocs en excutant une instruction FLUSH TABLES WITH READ LOCK.
master> FLUSH TABLES WITH READ LOCK;
Lorsque le verrou de lecture plac par FLUSH TABLES WITH READ LOCK est actif, lisez la valeur du nom de fichier du journal binaire actuel, puis dcalez sur le matre avec la commande suivante :
master> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+
Page 17 sur 32
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | black-bin.000001 | 1790 | | | +------------------+----------+--------------+------------------+
La colonne File affiche le nom du journal et la colonne Position affiche le dcalage dans le fichier. Dans cet exemple, le fichier journal binaire est black-bin.000001 et la position est 1790 . Notez ces valeurs qui seront utiles plus loin lors de la configuration de l'esclave. Elle reprsentent les coordonnes de rplication auxquelles l'esclave doit dmarrer le traitement des nouvelles mises jour depuis le matre. Remarque : Si le matre a t excut prcdemment sans journalisation binaire active, le nom du journal et les valeurs de position affichs par SHOW MASTER STATUS sont vides. Dans ce cas, les valeurs requises ultrieurement pour spcifier le fichier journal et la position de l'esclave correspondent la chane vide ('') et 4. Ensuite, en laissant ouverte la fentre du client MySQL utilise pour excuter le FLUSH TABLES WITH READ LOCK, vous devez vider le contenu des bases de donnes sur le matre que vous souhaitez rpliquer sur l'esclave. Dans notre exemple, nous allons vider le contenu de la base de donnes clusterdb . Remarque : Vous pouvez ne pas rpliquer la base de donnes systme mysql si le serveur esclave possde un ensemble de comptes d'utilisateur diffrent de ceux existant sur le matre. Dans ce cas, vous devez l'exclure du processus de vidage. Vous pouvez excuter mysqldump dans le client MySQL ou de faon graphique avec MySQL Workbench.
[billy@black ~]$ mysqldump -u root clusterdb > /home/billy/mysql/master/clusterdb.sql
Vous pouvez ractiver l'activit d'criture sur le matre avec la commande suivante :
master> UNLOCK TABLES;
tape 4: Charger le fichier de vidage sur l'esclave

Ensuite, vous devez charger le fichier mysqldump depuis le matre vers l'esclave (bien entendu, cette action ncessite de copier le fichier clusterdb.sql du serveur noir vers le serveur bleu ). Cette action peut tre excute l'aide de la ligne de commande ou de faon graphique avec MySQL Workbench. tant donn que la base de donnes clusterdb n'existe pas sur l'esclave, elle doit tre cre avant le chargement dans les tables et les donnes :
[billy@blue ~]$ mysql -u root e create database clusterdb; [billy@blue ~]$ mysql -u root clusterdb < /home/billy/mysql/slave/clusterdb.sql
tape 5: Initialiser la rplication

Nous sommes dsormais prt initialiser la rplication sur l'esclave. Excutez la commande suivante sur l'esclave :
slave> SLAVE STOP;
Vous devez ensuite mettre une commande CHANGE MASTER :

slave> -> -> -> -> CHANGE MASTER TO MASTER_HOST='192.168.0.31', MASTER_USER='repl_user', MASTER_PASSWORD='billy', MASTER_LOG_FILE='black-bin.000001', MASTER_LOG_POS=1790;
O :
Page 18 sur 32
MASTER_HOST : est l'IP ou le nom d'hte du serveur matre, dans cet exemple noir ou 192.168.0.31 MASTER_USER : est l'utilisateur auquel nous avons octroy le privilge REPLICATION SLAVE l'tape 2 de cet exemple repl_user MASTER_PASSWORD : est le mot de passe que nous avons affect repl_user l'tape 2 MASTER_LOG_FILE : est le nom de fichier que nous avons dtermin l'tape 3 MASTER_LOG_POS : est la position que nous avons dtermine l'tape 3
Pour terminer, dmarrez la rplication sur l'esclave :

slave> start slave;
tape 6: Vrifications de base

Nous sommes dsormais prts excuter une vrification de base pour garantir le fonctionnement de la rplication. Dans cet exemple, nous insrons une ligne de donnes dans la table simples sur le serveur matre, puis nous vrifions que ces nouvelles lignes se matrialisent sur le serveur esclave :
master> insert into clusterdb.simples values (999); slave> select * from clusterdb.simples; +-----+ | id | +-----+ | 1 | | 2 | | 3 | | 999 | +-----+
8 Migration vers une rplication semi-synchrone

Cette section suppose que la rplication asynchrone est installe mais que vous souhaitez migrer vers la rplication semi-synchrone, en d'autres termes, cet exemple fait suite la section 7. Vous pouvez bien entendu commencer utiliser immdiatement la rplication semi-synchrone si vous n'utilisez pas encore la rplication asynchrone. Remarque : La rplication semi-synchrone est disponible uniquement dans MySQL 5.5 et ultrieur.
tape 1: Installer les plug-ins sur le matre et l'esclave

Installez les plug-ins appropris pour chaque serveur MySQL :
master> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; slave> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';
tape 2: Activer la rplication semi-synchrone

Pour fonctionner, la rplication semi-synchrone doit tre active sur le matre et sur l'un des esclaves au moins (dans notre cas, un seul esclave existe). Pour cela, vous pouvez dfinir rpl_semi_sync_master_enabled sur ON dans master.cnf et rpl_semi_sync_slave_enabled sur ON dans slave.cnf, ou l'aide de la ligne de commande MySQL :
master> SET GLOBAL rpl_semi_sync_master_enabled = on; slave> SET GLOBAL rpl_semi_sync_slave_enabled = on; slave> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;
Page 19 sur 32
Si la rplication n'est pas en cours d'excution, il n'est pas ncessaire d'arrter puis de redmarrer le thread I/O esclave. Vous pouvez simplement mettre START SLAVE. Vrifiez que la rplication semi-synchrone est active sur le matre et qu'un esclave au moins est connect en mode semi-synchrone :
master> SHOW STATUS LIKE 'Rpl_semi_sync_master_status'; +-----------------------------+-------+ | Variable_name | Value | +-----------------------------+-------+ | Rpl_semi_sync_master_status | ON | +-----------------------------+-------+ master> SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | +------------------------------+-------+
a. Confirmer que la rplication est excute en mode semi-synchrone

Nous ajoutons une nouvelle ligne sur le matre, puis nous vrifions les variables d'tat pour nous assurer qu'il a t rpliqu de faon semi-synchrone (en d'autres termes, l'esclave a accus rception de la modification avant le dlai d'expiration du matre et avant qu'il confirme l'insertion du client de faon asynchrone).
master> insert into clusterdb.simples values (100); master> SHOW STATUS LIKE 'Rpl_semi_sync_master_yes_tx'; +-----------------------------+-------+ | Variable_name | Value | +-----------------------------+-------+ | Rpl_semi_sync_master_yes_tx | 1 | +-----------------------------+-------+ slave> select * from clusterdb.simples; +-----+ | id | +-----+ | 1 | | 2 | | 3 | | 100 | | 999 | +-----+
9 Administration et dpannage de la rplication

Dans cette section, nous prsentons l'excution de quelques tches administratives et de dpannage de base sur la rplication MySQL.
Vrification de l'tat de la rplication

Les tches les plus courantes dans la gestion d'un processus de rplication consistent garantir que la rplication est excute et qu'aucune erreur ne se produit entre l'esclave et le matre. La commande principale utiliser pour cette tche est SHOW SLAVE STATUS qui doit tre excute sur l'esclave. Par exemple :
slave> SHOW SLAVE STATUS\G *************************** 1. Slave_IO_State: Master_Host: Master_User: Master_Port: Connect_Retry: Master_Log_File: Read_Master_Log_Pos: row *************************** 192.168.0.31 repl_user 3306 60 black-bin.000003 790
Page 20 sur 32
Relay_Log_File: Relay_Log_Pos: Relay_Master_Log_File: Slave_IO_Running: Slave_SQL_Running: Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: Last_Error: Skip_Counter: Exec_Master_Log_Pos: Relay_Log_Space: Until_Condition: Until_Log_File: Until_Log_Pos: Master_SSL_Allowed: Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: Master_SSL_Verify_Server_Cert: Last_IO_Errno: Last_IO_Error: Last_SQL_Errno: Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id:
slave-relay-bin.000013 936 black-bin.000003 No No
0 0 790 1238 None 0 No
NULL No 0 0
Les conseils suivants peuvent vous tre utiles pour interprter les rsultats du document gnr : Slave_IO_State - indique l'tat actuel de l'esclave Slave_IO_Running - indique si le thread I/O pour la lecture du journal binaire du matre est en cours d'excution Slave_SQL_Running - indique si le thread SQL pour l'excution d'vnements dans le journal de relais est en cours d'excution Last_Error - indique la dernire erreur enregistre lors du traitement du journal de relais. L'idal est qu'il soit vide et n'indique aucune erreur. Seconds_Behind_Master - indique le nombre de secondes de retard du thread SQL esclave sur le traitement du journal binaire du matre. Une valeur leve (ou croissante) peut indiquer que l'esclave ne parvient pas grer une grande quantit d'instructions provenant du matre. Une valeur 0 pour Seconds_Behind_Master signifie gnralement que l'esclave a rattrap le matre, mais ce n'est pas toujours exact. Par exemple, la connexion rseau entre matre et esclave peut tre interrompue sans que le thread I/O esclave ne l'ait encore dtect, c.--d. que le dlai slave_net_timeout n'est pas encore coul.
Sur le matre, vous pouvez vrifier l'tat des esclaves en examinant la liste des processus en cours d'excution sur le serveur.
master> SHOW PROCESSLIST \G
L'esclave tant au cur du processus de rplication, la quantit d'informations disponibles dans ce rapport est faible.
Suspension de la rplication
Vous pouvez arrter et dmarrer la rplication des instructions sur l'esclave l'aide des instructions STOP SLAVE et START SLAVE. Pour arrter l'excution du journal binaire partir de l'esclave, utilisez STOP SLAVE :
Page 21 sur 32
slave> STOP SLAVE;
Lorsque l'excution est interrompue, l'esclave ne lit pas le journal binaire partir du matre via IO_THREAD et arrte le traitement des vnements du journal de relais qui n'ont pas encore t excuts via SQL_THREAD. Vous pouvez interrompre les threads IO ou SQL individuellement en spcifiant le type de thread. Par exemple :
slave> STOP SLAVE IO_THREAD;
L'arrt du thread SQL peut tre utile si vous souhaitez excuter une sauvegarde ou une autre tche sur un esclave qui traite uniquement des vnements partir du matre. Le thread continue d'tre lu partir du matre mais les modifications ne s'appliquent pas encore, ce qui permet l'esclave de rattraper son retard lorsque vous redmarrez les oprations sur l'esclave. L'arrt du thread IO permet aux instructions du journal de relais d'tre excutes jusqu' ce que le journal de relais cesse de recevoir de nouveaux vnements. Cette option peut s'avrer utile pour permettre l'esclave de rattraper son retard sur les vnements du matre, pour excuter des tches administratives sur l'esclave, mais galement pour vous assurer de disposer des dernires mises jour jusqu' un point spcifique. Cette mthode permet galement d'interrompre l'excution sur l'esclave pendant que vous effectuez des tches administratives sur le matre, tout en garantissant l'absence d'une quantit importante d'vnements en attente d'excution lors du redmarrage de la rplication. Pour redmarrer l'excution, utilisez l'instruction START SLAVE :
slave> START SLAVE;
Si ncessaire, vous individuellement.
pouvez
dmarrer
les
threads
IO_THREAD
ou
SQL_THREAD
Affichage des journaux binaires

Comme indiqu plus haut, le journal binaire du serveur inclut des fichiers contenant des vnements qui dcrivent les modifications apportes au contenu de la base de donnes. Le serveur crit ces fichiers sous un format binaire. Pour afficher leur contenu sous un format texte, utilisez l'utilitaire mysqlbinlog. Vous pouvez galement utiliser mysqlbinlog pour afficher le contenu des fichiers journaux de relais crits par un serveur esclave dans une configuration de rplication, car les journaux de relais utilisent le mme format que les journaux binaires. Pour plus d'informations sur l'utilitaire mysqlbinlog, visitez : http://dev.mysql.com/doc/refman/5.1/en/mysqlbinlog.html
10 Reprise aprs chec et rcupration

Le matre peut tomber en panne ou tre arrt pour une opration de maintenance. Cette section prsente les tapes requises.
tape 1: Conditions pralables

Dans les sections 7 et 8, nous avons configur une rplication pour deux serveurs MySQL dans une configuration matre-esclave. Dans cette section, nous allons la dvelopper avec les deux mthodes suivantes : 1. Autoriser le changement dans les relations : un serveur agissant en tant qu'esclave peut devenir matre (par exemple, pour arrter le matre d'origine des fins de maintenance) et le matre d'origine devenir esclave 2. Dmarrer une configuration plus complexe, comme illustr dans la Figure 10 : un matre unique (noir) et 2 esclaves (bleu et vert)
Page 22 sur 32
Figure 10 Un matre et deux esclaves Etant donn que tous ces serveurs peuvent devenir matre, les serveurs esclaves doivent aussi enregistrer les modifications dans un journal binaire. De mme, le serveur noir peut devenir esclave et doit par consquent disposer des donnes de configuration appropries. Les fichiers de configuration peuvent se prsenter comme suit :
black.cnf :
[mysqld] datadir=/home/billy/mysql/master/data server-id=1 # Replication Master log-bin=black-bin.log innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Replication Slave relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin
blue.cnf
[mysqld] datadir=/home/billy/mysql/slave/data server-id=2 # Replication Master log-bin=blue-bin.log innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Replication Slave relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin
green.cnf
[mysqld] datadir=/home/billy/mysql/slave/data server-id=3 # Replication Master log-bin=green-bin.log
Page 23 sur 32
innodb_flush_log_at_trx_commit=1 sync_binlog=1 # Replication Slave relay-log-index=slave-relay-bin.index relay-log=slave-relay-bin
Puisque chaque serveur peut agir en tant que matre et les deux autres en tant qu'esclaves, l'utilisateur de rplication doit tre cr sur chaque serveur avec des permissions de connexion depuis l'un des deux autres serveurs :
black> CREATE USER repl_user@192.168.0.34; black> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy'; black> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.32 IDENTIFIED BY 'billy'; blue> CREATE USER repl_user@192.168.0.31; blue> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.31 IDENTIFIED BY 'billy'; blue> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.32 IDENTIFIED BY 'billy'; green> CREATE USER repl_user@192.168.0.34; green> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.31 IDENTIFIED BY 'billy'; green> GRANT REPLICATION SLAVE ON *.* TO repl_user@192.168.0.34 IDENTIFIED BY 'billy';
Pour terminer, si la rplication semi-synchrone est utilise, le matre et les plug-ins esclaves doivent tre installs sur les trois serveurs, mais la fonctionnalit matre/esclave doit tre active uniquement sur les serveurs appropris :
black> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; black> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; black> SET GLOBAL rpl_semi_sync_master_enabled = on; blue> blue> blue> blue> green> green> green> green> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; SET GLOBAL rpl_semi_sync_slave_enabled = on; STOP SLAVE IO_THREAD; START SLAVE; INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so'; SET GLOBAL rpl_semi_sync_slave_enabled = on; STOP SLAVE IO_THREAD; START SLAVE;
tape 2: Dtecter si le matre a chou

Il est frquent de placer le matre hors ligne intentionnellement, par exemple pour effectuer une maintenance matrielle, auquel cas cette tape ne s'applique pas. Dans les autres cas, la dfaillance est vidente, par exemple lors d'une panne matrielle. Il existe toutefois de nombreux types de dfaillance , plus subtils, que vous devez dtecter et utiliser pour dclencher une reprise aprs chec. Une approche simple consiste surveiller la valeur Seconds_Behind_Master obtenue partir d'un ou de plusieurs esclaves :
blue> show slave status \G *************************** 1. Slave_IO_State: Master_Host: Master_User: Master_Port: Connect_Retry: Master_Log_File: Read_Master_Log_Pos: Relay_Log_File: Relay_Log_Pos: Relay_Master_Log_File: Slave_IO_Running: Slave_SQL_Running: Replicate_Do_DB: Replicate_Ignore_DB: row *************************** Waiting for master to send event 192.168.0.31 repl_user 3306 60 black-bin.000003 599 slave-relay-bin.000013 745 black-bin.000003 Yes Yes
Page 24 sur 32
Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: Last_Error: Skip_Counter: Exec_Master_Log_Pos: Relay_Log_Space: Until_Condition: Until_Log_File: Until_Log_Pos: Master_SSL_Allowed: Master_SSL_CA_File: Master_SSL_CA_Path: Master_SSL_Cert: Master_SSL_Cipher: Master_SSL_Key: Seconds_Behind_Master: Master_SSL_Verify_Server_Cert: Last_IO_Errno: Last_IO_Error: Last_SQL_Errno: Last_SQL_Error: Replicate_Ignore_Server_Ids: Master_Server_Id:
0 0 599 1047 None 0 No
0 No 0 0
Si la valeur Seconds_Behind_Master augmente et que le niveau de mises jour envoy au matre n'a pas chang de faon importante, cela peut indiquer que le matre rencontre des problmes (notamment si le mme comportement est observ sur plusieurs esclaves). Comme illustr dans la Figure 15, MySQL Enterprise Monitor permet notamment de surveiller l'tat de la rplication et de signaler la ncessit d'une reprise aprs chec.
a. Suspendre les critures vers le matre

Si le processus MySQL Server matre a expir ou que le matriel sous-jacent a chou, cette tape peut tre obsolte. Cependant, pour des maintenances programmes du matre ou des dfaillances plus subtiles, vous pouvez empcher les applications clientes d'effectuer des modifications pendant la transition. Il existe diverses mthodes pour interrompre les mises jour : via l'application, un quilibrage de charge ou le connecteur. Une autre approche consiste rclamer un verrou sur toutes les tables :
black> FLUSH TABLES WITH READ LOCK;
b. Promouvoir l'esclave en matre

Notre exemple comporte deux esclaves et nous devons slectionner celui destin devenir matre. La slection doit prendre en compte l'tat de mise jour, en d'autres termes, retenir le serveur le plus avanc dans le traitement des mises jour rpliques depuis le matre d'origine. Pour le dterminer, excutez show slave status \G sur chaque client. Une fois slectionn, le thread I/O (reportez-vous la Figure 8) doit tre interrompu sur le nouveau matre slectionn (dans notre exemple bleu est slectionn) :
blue> STOP SLAVE IO_THREAD;
Une fois cette tape effectue, l'excution du thread SQL des esclaves se poursuit et applique les mises jours restantes partir du journal de relais. Lorsque le dlai ncessaire l'application de toutes les modifications des journaux de relais est pass (attendez que Exec_Master_Log_Pos = Read_Master_Log_Pos dans la sortie de SHOW SLAVE STATUS \G ), la rplication peut tre entirement arrte sur le serveur qui va devenir le nouveau matre :
blue> STOP SLAVE;
Page 25 sur 32
Si vous utilisez la rplication semi-synchrone, activez prsent le plug-in ct matre sur le nouveau matre :
blue> SET GLOBAL rpl_semi_sync_master_enabled = on;
Avant de dmarrer une rplication depuis le nouveau matre (bleu) vers l'esclave restant (vert), vous devez dterminer la position actuelle dans le journal binaire du nouveau matre :
blue> show master status \G *************************** 1. row *************************** File: blue-bin.000001 Position: 807 Binlog_Do_DB: Binlog_Ignore_DB:
Sur l'esclave restant ( vert ), redfinissez le matre sur le nouveau matre :

green> green> -> -> -> -> green> stop slave; CHANGE MASTER TO MASTER_HOST='192.168.0.34', MASTER_USER='repl_user', MASTER_PASSWORD='billy', MASTER_LOG_FILE='blue-bin.000001', MASTER_LOG_POS=807; start slave;
Si vous utilisez la rplication semi-synchrone, assurez-vous que l'esclave restant est enregistr pour la rplication asynchrone en questionnant le nouveau matre (le rsultat doit tre 1) :
blue> SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; +------------------------------+-------+ | Variable_name | Value | +------------------------------+-------+ | Rpl_semi_sync_master_clients | 1 | +------------------------------+-------+
La rplication est de nouveau excute, comme illustr dans la Figure 11.
Figure 11 Rplication redmarre avec un nouveau matre
Page 26 sur 32
c. Rediriger les critures vers le nouveau matre une fois le journal de relais appliqu
L'application peut dsormais commencer envoyer des critures vers le nouveau matre (et des lectures vers le nouveau matre et l'esclave restant). Cette action peut tre active l'aide du connecteur, d'un quilibrage de charge ou au sein de l'application.
d. Synchroniser le matre chou avec le nouveau matre

Par la suite, il peut tre possible d'ajouter le matre d'origine (noir) en tant qu'esclave du nouveau matre (au moins initialement) dans la configuration. Pour cela, il existe deux options : 1. Traiter le matre d'origine en tant que nouvel esclave et suivre les tapes 3 6 de la section 7. Cette option est prfrable si de nombreuses mises jour ont t appliques au nouveau matre avant l'ajout du matre d'origine ou si des modifications effectues sur le matre d'origine n'ont pas t rpliques sur le nouveau matre (par exemple, lors d'une dfaillance non contrle du matre d'origine lorsque la rplication semi-synchrone n'est pas utilise). 2. Remettre jour le matre d'origine en l'ajoutant en tant qu'esclave du nouveau matre, afin de l'actualiser avec toutes les modifications effectues depuis sa promotion en tant que matre. Le reste de cette section prsente cette approche. Dans les deux cas, librez le verrou de lecture sur le matre d'origine, si ce n'est dj fait :
black> UNLOCK TABLES;
Si vous utilisez la rplication semi-synchrone, activez prsent ce plug-in sur le matre d'origine (nouvel esclave) :
black> SET GLOBAL rpl_semi_sync_slave_enabled = on;
Dmarrez le nouvel esclave partir du point enregistr l'tape 4 :

black> -> -> -> -> black> CHANGE MASTER TO MASTER_HOST='192.168.0.34', MASTER_USER='repl_user', MASTER_PASSWORD='billy', MASTER_LOG_FILE='blue-bin.000001', MASTER_LOG_POS=807; start slave;
A prsent, nous excutons de nouveau 1 matre et 2 esclaves, comme illustr dans la Figure 12.
Page 27 sur 32
Figure 12 Retour 1 matre et 2 esclaves Une dernire tape (facultative) consiste rexcuter cette procdure afin de rtablir le matre d'origine (noir).
11 Diffrences lors d'une rplication avec MySQL Cluster

MySQL Cluster est une base de donnes en cluster volutive et hautement performante, dveloppe initialement pour certaines applications parmi les plus exigeantes dans le secteur des tlcommunications. Ces applications de tlcommunication ncessitaient souvent une disponibilit de la base de donnes suprieure 99,999 %. MySQL Cluster peut tre utilis en tant que moteur de stockage enfichable, mais son architecture est fondamentalement diffrente de celle des autres moteurs de stockage MySQL (par exemple InnoDB et MyISAM), ce qui affecte le fonctionnement et la mise en uvre de la rplication. L'architecture est illustre dans la Figure 13 ci-dessous. En termes d'impact sur la rplication, sa principale caractristique architecturale ne repose pas sur le stockage des donnes dans une instance MySQL Server, mais sur leur distribution vers plusieurs nuds de donnes. Une rplication synchrone entre les nuds de donnes dans le Cluster offre une haute disponibilit. Notez que cette rplication synchrone n'est pas associe la rplication prsente dans ce livre blanc. Les donnes sont accessibles directement partir des nuds de donnes (par exemple via l'API C++ native), ou un ou plusieurs serveurs MySQL peuvent tre utiliss pour fournir l'accs SQL. Chaque serveur MySQL peut lire ou crire n'importe quelle ligne d'une table et la modification est immdiatement visible sur les autres serveurs MySQL.
Page 28 sur 32
Figure 13 Architecture MySQL Cluster La rplication MySQL est gnralement utilise avec MySQL Cluster pour fournir la redondance gographique : la rplication interne (synchrone) fournit la haute disponibilit entre les nuds de donnes colocaliss au sein du datacenter et la rplication MySQL (asynchrone) vers un site distant protge contre tout chec grave sur le site. Quel est l'impact sur la rplication MySQL ? Des modifications peuvent tre effectues partir de tout serveur MySQL ou directement dans les nuds de donnes. Un mcanisme a t mis en uvre pour regrouper toutes les modifications dans les journaux binaires d'un ou de plusieurs serveurs MySQL dsigns, qui agissent alors en tant que matres de la rplication MySQL. Elle est excute par le thread NDB Binlog Injector. Ce thread garantit que toutes les modifications, quel que soit l'emplacement de leur application dans le Cluster, sont crites dans le journal binaire dans l'ordre appropri. Comme illustr dans la Figure 14, elle renforce l'architecture systme de rplication. Deux serveurs MySQL sont illustrs dans lesquels les journaux binaires contiennent les mmes modifications. Chaque serveur peut tre utilis en tant que matre pour rpliquer ces modifications sur un ou plusieurs dploiements MySQL Cluster esclaves et/ou sur un serveur MySQL qui stocke des donnes l'aide des moteurs de stockage InnoDB ou MyISAM. Les journaux binaires de chaque matre doivent contenir les mme modifications, mais ils sont indpendants. Pour faciliter la reprise aprs chec d'un esclave en basculant d'un matre vers un autre, l'outil Epoch au niveau du Cluster est utilis pour reprsenter l'tat d'un Cluster sur un moment donn unique. Ces techniques avances de reprise aprs chec dpassent l'objet de ce livre. Pour plus d'informations, vous pouvez toutefois consulter le guide de rfrence de MySQL Cluster l'adresse : http://dev.mysql.com/doc/mysql-cluster-excerpt/5.1/en/mysql-cluster-replication-failover.html MySQL Cluster prend en charge l'excution de la rplication MySQL dans une configuration active-active plusieurs matres ou mme avec des anneaux de rplication. De plus, MySQL Cluster peut fournir une dtection ou une rsolution des conflits qui permet de grer l'criture des modifications conflictuelles sur les mmes lignes dans ces matres diffrents. Le fonctionnement de cette dtection / rsolution des conflits ncessite des tches supplmentaires au niveau de l'application, qui dpassent l'objet de ce livre blanc. Pour plus d'informations, vous pouvez toutefois consulter le guide de rfrence de MySQL Cluster : http://dev.mysql.com/doc/mysqlcluster-excerpt/5.1/en/mysql-cluster-replication-multi-master.html
Page 29 sur 32
Figure 14 Plusieurs matres au sein d'un Cluster Les versions MySQL Cluster sont produites selon un programme diffrent de celui des principales versions MySQL. Par consquent, les fonctionnalits de rplication MySQL ne sont pas toujours disponibles dans la dernire version MySQL Cluster. Par exemple, au moment de la rdaction de ces lignes, MySQL Cluster 7.1 est la dernire version disponible, qui utilise une version modifie de MySQL 5.1 pour les serveurs MySQL. Par consquent, les amliorations intgres MySQL 5.5 ne sont pas disponibles. La fonction de promotion et de rtrogradation intgre MySQL Cluster 7.1.3 est une exception. Lors de la rplication partir de MySQL Cluster, la rplication par ligne (plutt que la rplication par instruction) est toujours utilise.
12 Surveillance de la rplication avec MySQL Enterprise Monitor

MySQL Enterprise Monitor avec Query Analyzer est une application Web distribue que vous dployez en toute scurit derrire votre pare-feu d'entreprise. MySQL Enterprise Monitor surveille en permanence l'ensemble de vos serveurs MySQL et vous informe de manire proactive des problmes potentiels et des rglages possibles afin d'viter toute interruption onreuse. Il offre galement les conseils aviss de MySQL sur les problmes qu'il dtecte, pour vous aider optimiser votre temps et vos systmes MySQL.
Page 30 sur 32
Figure 15 MySQL Enterprise Monitor
Enterprise Monitor offre les fonctionnalits spcifiques la rplication MySQL suivantes : Les relations de rplication sont automatiquement dtectes, regroupes et maintenues, sans installation ni configuration DBA Une vue consolide et en temps rel des performance et de l'tat de toutes les relations matre/esclave, comme illustre dans la Figure 16 ci-dessous.
Figure 16 Statistiques de rplication dans MySQL Enterprise Monitor MySQL Enterprise Monitor est disponible en option commerciale pour les clients MySQL.
Page 31 sur 32
13 Conclusion
La rplication MySQL a dmontr son efficacit en tant que solution l'extrme volutivit des applications fondes sur une base de donnes dans les environnements les plus exigeants, tant sur le Web qu'au sein de l'entreprise. Ce livre blanc vous a prsent les avantages techniques et commerciaux du dploiement de la rplication MySQL, avec des guides pas--pas de prise en main pratiques. Comme le montre la version MySQL 5.5, la rplication est un secteur trs actif en plein dveloppement, qui fait l'objet d'amliorations permanentes dans divers domaines tels que l'intgrit des donnes, la flexibilit des performance et du dploiement. Les ressources ci-dessous viennent complter ce livre blanc, et peuvent acclrer votre valuation et votre dploiement de la rplication MySQL.
14 Ressources
Tlcharger MySQL 5.5 : http://dev.mysql.com/downloads/mysql/5.5.html Guide de l'utilisateur de la rplication MySQL : http://dev.mysql.com/doc/refman/5.5/en/replication.html Visionner le Webminaire Delivering Scalability and High Availability with MySQL 5.5 Replication Enhancements : http://www.mysql.com/news-and-events/on-demand-webinars/display-od572.html Visionner le Webminaire MySQL Cluster Geographic Replication : http://www.mysql.com/news-and-events/on-demand-webinars/display-od-415.html Documentation relative la rplication MySQL Cluster : http://dev.mysql.com/doc/mysql-clusterexcerpt/5.1/en/mysql-cluster-replication.html MySQL chez Ticketmaster (grand utilisateur de rplication MySQL) : http://www.mysql.com/customers/view/?id=684
Copyright 2010, Oracle et/ou ses filiales. MySQL est une marque dpose dOracle aux tats-Unis et dans dautres pays. Les autres produits mentionns sont les marques de leurs dtenteurs respectifs.
Page 32 sur 32

MySQL Replication White Paper FR

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MySQL Replication White Paper FR

Uploaded by

Copyright:

Available Formats

Rplication MySQL

Amlioration de l'volutivit et de la disponibilit avec MySQL 5.5

Livre blanc technique MySQL par Oracle Octobre 2010

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

TABLE DES MATIRES

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

2 Principes fondamentaux de la rplication

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Figure 2 Rplication asynchrone et synchrone

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Rplication par instruction

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Rplication par ligne

Rplication en format mixte

3 Liste des modifications apportes la rplication dans MySQL 5.5

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

4 Cas d'utilisation de la rplication

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Figure 4 Rplication pour redondance gographique

Sauvegarde de base de donnes

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Figure 5 Cas d'utilisation d'association de rplications

Figure 6 Topologies de rplication MySQL courantes

Matre vers esclave

Matre vers plusieurs esclaves

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Matre vers esclave(s) vers esclave(s)

Matre vers matre (plusieurs matres)

Table 1 Eviter les valeurs d'auto incrmentation conflictuelles

Matres multiples vers esclave (source multiple)

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

6 Rplication de flux de travail interne

Figure 8 Mise en uvre de la rplication MySQL

Thread Binlog Dump

Thread I/O esclave

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Thread SQL esclave

Rplication de fichiers journaux

7 Configuration de la rplication MySQL

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

tape 1: Configurer les fichiers cnf du matre et de l'esclave

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

tape 2: Crer un utilisateur de rplication

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | black-bin.000001 | 1790 | | | +------------------+----------+--------------+------------------+

tape 4: Charger le fichier de vidage sur l'esclave

tape 5: Initialiser la rplication

Vous devez ensuite mettre une commande CHANGE MASTER :

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

Pour terminer, dmarrez la rplication sur l'esclave :

tape 6: Vrifications de base

8 Migration vers une rplication semi-synchrone

tape 1: Installer les plug-ins sur le matre et l'esclave

tape 2: Activer la rplication semi-synchrone

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

a. Confirmer que la rplication est excute en mode semi-synchrone

9 Administration et dpannage de la rplication

Vrification de l'tat de la rplication

Copyright 2010, Oracle et/ou ses filiales. Tous droits rservs.

slave-relay-bin.000013 936 black-bin.000003 No No

0 0 790 1238 None 0 No