Configurer la réplication source-réplica MySQL

La réplication MySQL® permet à un serveur de base de données (appelé serveur source dans cet article) d'être répliqué sur un ou plusieurs serveurs de base de données (appelés serveurs réplique dans cet article). Avec MySQL, la réplication est asynchrone. Cela signifie que les serveurs répliques n'ont pas besoin d'être connectés en permanence pour recevoir les mises à jour du serveur source. Par exemple, vous pouvez arrêter le thread de réplique sur le serveur de réplique et le redémarrer ultérieurement, et il se synchronise automatiquement avec la source.

Ce didacticiel propose une configuration simple (un serveur source unique répliquant sur un serveur réplica unique) qui réplique toutes les bases de données de la source vers la réplique.

Prérequis

Avant de commencer ce didacticiel, effectuez les étapes suivantes.

Installez votre système d'exploitation. (Les étapes décrites dans cet article sont effectuées à l'aide d'un système d'exploitation CentOS®)
Installer mysql
Installer mysql-devel
Installer mysql-server

Remarque : La procédure décrite dans cet article décrit la configuration de la réplication sur un nouvel ensemble de serveurs sans données ni base de données. Ceci est important car les données existantes sur les serveurs perturbent la réplication. Vous pouvez utiliser cette procédure pour d'autres versions de Linux®

Collecte des informations IP

La configuration MySQL de cet article se réplique sur les adresses IP privées de votre serveur cloud. Notez l'adresse IP privée de chaque serveur.

Source :

[user@mysql-source ~]$ /sbin/ifconfig
 eth0      Link encap:Ethernet  HWaddr 40:40:51:B7:A4:2E
           inet addr:67.23.9.185  Bcast:67.23.9.255  Mask:255.255.255.0
           inet6 addr: fe80::4240:51ff:feb7:a42e/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:28878 errors:0 dropped:0 overruns:0 frame:0
           TX packets:15147 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:37708534 (35.9 MiB)  TX bytes:1129533 (1.0 MiB)

 eth1      Link encap:Ethernet  HWaddr 40:40:1A:AF:35:F2
           inet addr:10.176.41.72  Bcast:10.176.63.255 Mask:255.255.224.0
           inet6 addr: fe80::4240:1aff:feaf:35f2/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
           TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:230 (230.0 b)  TX bytes:762 (762.0 b)

 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Vous voulez noter l'IP qui est affiché pour eth1 . L'adresse IP est indiquée juste après inet addr: . Dans cet exemple, l'adresse IP privée du serveur source est 10.176.41.72. Répétez cette opération sur le serveur répliqué et notez l'adresse IP privée.

Réplica :

 [user@mysql-replica ~]$ /sbin/ifconfig
 eth0      Link encap:Ethernet  HWaddr 40:40:BE:90:EB:1E
           inet addr:67.23.10.69  Bcast:67.23.10.255  Mask:255.255.255.0
           inet6 addr: fe80::4240:beff:fe90:eb1e/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:29047 errors:0 dropped:0 overruns:0 frame:0
           TX packets:13527 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:37743828 (35.9 MiB)  TX bytes:1473375 (1.4 MiB)

 eth1      Link encap:Ethernet  HWaddr 40:40:AE:5B:35:3A
           inet addr:10.176.41.207  Bcast:10.176.63.255 Mask:255.255.224.0
           inet6 addr: fe80::4240:aeff:fe5b:353a/64 Scope:Link
           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
           TX packets:13 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:1000
           RX bytes:230 (230.0 b)  TX bytes:762 (762.0 b)

 lo        Link encap:Local Loopback
           inet addr:127.0.0.1  Mask:255.0.0.0
           inet6 addr: ::1/128 Scope:Host
           UP LOOPBACK RUNNING  MTU:16436  Metric:1
           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:0
           RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

L'adresse IP de notre serveur réplique dans cet exemple est 10.176.41.207. Lorsque vous avez noté les deux adresses IP privées quelque part, vous êtes prêt à commencer la configuration.

Configurer le serveur

Source

Modifiez le fichier /etc/my.cnf fichier sur le serveur source pour activer la journalisation binaire et définir le nom du serveur.
```
  [user@mysql-source ~]$ sudo vi /etc/my.cnf
```

Ajoutez ces lignes sous le mysqld rubrique.

  log-bin=/var/lib/mysqllogs/RackspaceServerID-theServerShortName-binary-log
  expire_logs_days=7
  server-name=<server_number>

Définissez l'utilisateur de réplication.

  mysql> GRANT REPLICATION SLAVE ON *.* to 'replicant'@'slaveIP' IDENTIFIED BY 'somepassword';

La source mon.cnf la configuration est terminée.

Préparation de la réplique

Vérifiez que les fuseaux horaires correspondent entre la source et le réplica.

Définissez les éléments suivants :

  relay-log=/var/lib/mysqllogs/RackspaceServerID-theServerShortName-relay-log
  relay-log-space-limit = 16G
  read-only=1
  server-name=<server_number>

Copie initiale des données vers le réplica

Choisissez l'une des options suivantes pour copier les données vers le réplica.

mysqldump
Copiez les fichiers plats

mysqldump

Envisagez cette option si le répertoire de données est d'une taille raisonnable et si vous pouvez verrouiller vos tables pendant toute la durée de la procédure.

 mysqldump -A --flush-privileges --master-data=1 | gzip -1 > ~rack/master.sql.gz

Transférez le fichier de vidage vers la réplique et importez-le.

Copier les fichiers plats

Pour cette méthode, arrêtez MySQL sur les deux serveurs et déplacez le répertoire de données sur la réplique. Si MySQL n'est pas stoppé sur les deux serveurs, il faut faire une sauvegarde :

 # mv /var/lib/mysql{,.prereplication}

Utilisez l'une des méthodes répertoriées ci-dessus pour transformer le répertoire de données du réplica en une copie de la source. Par exemple :

 # rsync -azv --progress --delete /var/lib/mysql/ slave:/var/lib/mysql/

Lorsque la copie des données est terminée, redémarrez MySQL sur les deux serveurs. Vérifiez que innodb-log-file-size dans /etc/mon.cnf est défini de la même manière pour le réplica et la source, sinon MySQL ne démarrera pas sur le réplica.

Si le réplica est une version plus récente de MySQL, exécutez mysql_upgrade sur réplica avant d'émettre le start slave commande.

Attacher le réplica à la source

Vous avez besoin du nom et de la position du fichier journal binaire de la source qui correspond à la sauvegarde. Si vous utilisez mysqldump , cela sera inclus dans le master.sql.gz fichier lui-même.

 # zgrep -m 1 -P 'CHANGE MASTER' master.sql.gz
 CHANGE MASTER TO MASTER_LOG_FILE = '<binary log filename>', MASTER_LOG_POS = <binary log position>;

Pour une copie au niveau du fichier telle qu'une copie à froid obtenue en fermant MySQL et en utilisant rsync , le nom et la position du fichier journal binaire seront le premier fichier journal créé après le redémarrage de MySQL.

Vous pouvez l'obtenir en suivant ces étapes :

 # service mysqld stop
 # tail -n 1 /var/lib/mysqllogs/db1-1234-bin-log.index
 /var/lib/mysqllogs/db1-1234-bin-log.000001
 # rsync ...
 # service mysqld start

Dans ce cas, commencez au nom de fichier db1-bin-log.000001 + 1 = db1-1234-bin-log.000002 au début de ce dossier. Vous obtiendrez ce résultat :

 MASTER_LOG_FILE = 'db1-1234-bin-log.000002', MASTER_LOG_POS = 4

Maintenant, exécutez CHANGE MASTER sur le réplica pour définir les identifiants de connexion à la source, ainsi que le fichier journal binaire et la position à partir de laquelle démarrer la réplication.

 mysql> change master to master_host='master-ip',master_user='userSetAbove', master_password='passwordSetAbove',master_log_file='logfile-from-above-command', master_log_pos=4;
 mysql> start slave;

Identifiants racine MySQL

Assurez-vous que le nouveau réplica a les mêmes informations d'identification dans /root/.my.cnf fichier comme serveur source. La base de données MySQL et la table des autorisations utilisateur sont également synchronisées avec le réplica.

Hollande

Étant donné que vous avez importé la base de données MySQL à partir de la source, tous les mots de passe sont désormais identiques. Tout comme vous avez mis à jour le /root/.my.cnf sur dbReplica pour correspondre à dbSource, vous devrez peut-être mettre à jour le fichier /etc/holland/backupsets/default.conf fichier utilise les mêmes informations d'identification que la source pour rackspace_backup .

Tests

Testez vos paramètres en créant une base de données factice sur la source et en vérifiant qu'elle s'affiche sur la réplique. Une fois vérifiée, vous pouvez supprimer la base de données factice et confirmer que le réplica la supprime automatiquement.

Si vous voyez une erreur telle que Last_IO_Error: error connecting to master , testez manuellement l'utilisateur de réplication. À partir du réplica, essayez deux choses :

nc masterIP 3306

Si vous voyez une erreur ici, votre attribution est erronée, probablement parce que vous vous trouvez dans un segment de réseau différent de celui que vous pensiez. L'erreur ressemblera à Host dbSlave is not allowed to connect to this MySQL server .

mysql -ureplicant -hmasterDb -p

Si vous obtenez une erreur, votre subvention est erronée.

Si l'un de ces éléments ne parvient pas à se connecter, vous devrez peut-être ajuster le pare-feu ou vérifier que vous faites des hypothèses correctes sur la configuration du réseau pour ce client.

Filtrage

Il est recommandé de ne pas utiliser le filtrage de réplication. Si vous souhaitez exclure certaines tables du réplica, la seule méthode recommandée consiste à utiliser l'une des méthodes suivantes :my.cnf options configurées sur le réplica :

 replicate-wild-do-table=dbase1.%
 replicate-wild-do-table=dbase3.%

 replicate-wild-ignore-table=dbase2.%
 replicate-wild-ignore-table=dbase4.someTable

Les modèles peuvent contenir les caractères génériques % et \_ , qui ont la même signification que le LIKE opérateur de correspondance de modèle. Si vous devez utiliser un caractère literal_, échappez-le comme suit :

 replicate-wild-ignore-table=%.%\_tmp

Dans MySQL 5.5, les options de filtrage au niveau de la base de données sont sensibles à la casse sur les plates-formes prenant en charge la sensibilité à la casse dans les noms de fichiers. Les options de filtrage au niveau des tables ne sont sensibles à la casse sur aucune plate-forme, quelle que soit la valeur de lower_case_table_names variable système.

Événements

Si mon.cnf a été activé sur la source, vous pouvez le désactiver sur le réplica. Si le planificateur d'événements doit être activé sur le réplica, vérifiez que les événements existants ont été créés avec CREATE EVENT ... DISABLE ON SLAVE avec quelque chose comme :select db, name from mysql.event where status not in (‘disabled’,‘slavename_disabled’);

Surveillance

Surveillez toujours la réplication. Dans Emerging, nous utilisons généralement SiteScope Content Match avec check_replication.php , qui réside généralement dans snamee httpd s'exécutant sur le réplica.

Vous devez émettre le GRANT pour cela sur la source, qui se réplique sur le réplica :

 GRANT REPLICATION CLIENT ON *.* TO 'rep_monitor'@'slavePrimaryIP' IDENTIFIED BY 'somePassword';

En supposant que vous êtes derrière un pare-feu, le « slavePrimaryIP » doit être l'adresse IP interne du serveur de réplique [192.168.100.x]. Dans le fichier check_replication.php script, définissez host=‘192.168.100.x , l'adresse IP interne du serveur sur lequel le script s'exécute. C'est généralement le même que slavePrimaryIP .

Contactez votre responsable de compte et demandez la configuration du moniteur SiteScope. L'URL doit être l'adresse IP publique du serveur de surveillance, par exemple https://68.23.45.32/check_replication.php

Remarque : Le script peut avoir des éléments supplémentaires dans la dsn list tableau et vérifier plusieurs répliques avec une seule sonde SiteScope. La documentation PHP indique que la virgule après le dernier élément du tableau est facultative et peut être omise. Cependant, avec la sonde SiteScope vérifiant plusieurs répliques, il peut être moins clair quelle réplique a eu un problème lorsque l'alerte disparaît rapidement. À cet égard, il peut être judicieux d'avoir un check_replication.php etla sonde SiteScope correspondante s'exécutant sur chaque réplica.

Maintenant, asseyez-vous et laissez votre serveur réplique répliquer à partir de la source. Assurez-vous de ne pas effectuer d'écriture sur le serveur de réplique car cela interrompt la réplication ! Toutes les écritures effectuées sur la source sont envoyées automatiquement à la réplique via le journal binaire et la réplication. Pour plus d'informations sur la réplication MySQL, voirhttps://dev.mysql.com/doc/refman/5.0/en/replication.html.