Reconstruire la BD-esclave et Réplication Comme la commande mysqldump verrouille les tables, il n'est pas nécessaire qu'il n'y ait pas de trafic sur la base de données principale. Avec --master-data, la commande mysqldump enregistre la position correcte pour l'insertion de la réplication sur le serveur esclave. Si le disque dur de l'esclave est plein, veuillez vous référer aux instructions sur cette page ci-dessous - "Disque d'esclave complet". - Connexion à serveur esclaves
Connectez-vous à MySQL avec les identifiants USER et PWD, puis arrêtez l'esclave et quittez MySQL à nouveau. Utilisez pour cela les commandes suivantes : Translations Ignore |
---|
mysql -uUSER -pPWD
STOP SLAVE;
RESET SLAVE;
QUIT;
|
Redémarrer Serveur MySQL avec service mysqld restart .
Ecrire Écrire un MySQL dump MySQL. Effectuez Exécutez maintenant les étapes suivantes sur le serveur maître. Créer Créez un répertoire de sauvegarde et changez pour le modifiermême. Le dumb MySQL est maintenant exécuté avec la commande suivante mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql
A partir de la version 3.12, veuillez utiliser la commande suivante : mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql
Voici une brève explication à ce sujet : - <Name LogFile> et et <Position LogFile> sont enregistrés grâce à --master-data dans le dump
- utiliser uniquement les bases de données JTEL '--databases'
- supprimer toutes les bases de données avant l'importation '--add-drop-database'
- supprimer toutes les tables des bases de données avant l'importation '--add-drop-table'
- Mettre en œuvre toutes les routines et procédures dans la décharge '--events --routines'
- De plus, le paramètre --default_character_set utf8 peut être utilisé
Warning |
---|
Dans les versions 3.12, 3.14 et 3.15 Si quelqu'un se connecte au portail alors pendant que la décharge est en cours d'extractionle vidage est extrait, cela va mal se passer. Ci-tourner. J'ai joint une requête SQL. Si l'heure change après l'exécution de la requête, c'est qu' une connexion a eu lieu. Si cela se produit, la décharge doit être à nouveau retirée et, dans l'intervalle, il faut vérifier en permanence si une connexion a eu lieu. Si ce n'est pas le cas, le dépôt peut être reproduit sans erreur à l'esclave. SELECT Max(dtAcdLoggedIn) FROM Users; Dans les versions 3.11 et inférieures et la version 3.16, ce problème n'existe pas. |
- Copier le dump MySQL du serveur de base de données maître vers le serveur de base de données esclave
Utilisez l'outil de votre choix : ligne de commande (scp), WinSCP, ...
Nous retournons à la serveur esclave et maintenant importer mysqldump. Translations Ignore |
---|
mysql -uUSER -pPWD (we are now in MySql)
SET foreign_key_checks = 0;
drop database JTELLog;
drop database JTELStats;
drop database JTELWeb;
drop database JTELStats2;
SET foreign_key_checks = 1;
source <filename>;
|
- Nous sommes en train de déterminer les paramètres de réplication, car nous en aurons besoin dans un instant :
- Dans le fichier mysqldump, au tout début, nous trouvons une ligne dans le bloc de commentaires qui ressemble à ceci :
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000872', MASTER_LOG_POS=11940974;Mémoriser les paramètres MASTER_LOG_FILE et et MASTER_LOG_POS . - Nous avons besoin du nom ou de l'adresse IP du serveur principal de la base de données
- Nous avons besoin du mot de passe de l'utilisateur
repl sur le serveur de base de données principal. Généralement, c'est always le Mot de passe Utilisateur root - la façon la plus simple de l'essayer est de se connecter de l'esclave au maître avec ce mot de passe : mysql -h <masterIP> -u repl -p<Passwort> - si cela fonctionne, alors vous savez.
- Maintenant, sur le serveur esclave, il y a déjà un état cohérent et assez relativement nouveau des données. Il ne reste plus qu'à reconfigurer la réplication. Les commandes suivantes le font cela:
mysql -uUSER -pPWD
CHANGE MASTER TO MASTER_HOST='<name or ip of master servers>',MASTER_USER='repl',MASTER_PASSWORD='<passwort>',MASTER_LOG_FILE='<Name LogFile>', MASTER_LOG_POS=<Position LogFile>; Ici, tous les paramètres doivent être remplacés par ceux de l'étape 5.
Maintenant, nous vérifions le statut de l'esclave (plusieurs fois) avec la commande
et attendez le résultat suivant : Maintenant, la réplication fonctionne à nouveau. Le nom du fichier journal et la position devraient rapidement correspondre à peu près au statut de maître d'exposition sur la base de données principale.
- N'oubliez pas de nettoyer les déchets de données! C'est à dire. supprimer les mysqldumps et les répertoires au moins sur l'esclave. Une sauvegarde peut rester sur la base de données maîtreprincipale, à condition qu'il y ait assez de place. suffisamment d'espace.
Disque d'esclave completIl y a plusieurs raisons pour lesquelles le disque esclave peut devenir plein. le répertoire tmp est completBackgroundChaque fois qu'une requête crée une table tmp, elle est écrite dans le répertoire temptemporaire, généralement/tmp. Cela se produit lorsque la taille maximale dépasse la taille maximale de la table "en mémoire". Celle-ci Ceci est définie défini avec les variables tmp_table_size ainsi aussi bien que max_heap_table_size . See also https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html pour plus d'informations. Les tables dans / tmp sont conservées jusqu'à ce que la connexion DB respective soit fermée ou qu'une DROP TEMPORARY TABLE TEMPORAIRE DROP soit appelée. Si le répertoire / tmp est plein, il est probable qu'il un DROP TEMPORARY TABLE manque quelque part une DROP TABLE TEMPORAIRE. Cela peut également se produire par le biais de requêtes des clients à la DBvia des requêtes client adressées à la base de données. L'installation de tmpwatch crée de l'aide de façon permanente Indices: - Sous CentOS 6, le répertoire /tmp est alors par défaut libéré des fichiers qui n'ont pas été consultés pour > 10 jours
- Cela peut ne pas être suffisant
- Sous CentOS 7, le répertoire /tmp est alors libéré par défaut des fichiers qui n'ont pas été consultés depuis > 1 jour
Procédure- Un espace doit d'abord être mis à disposition. Il suffit de tout supprimer impitoyablement dans /tmp.
- Si cela permet de disposer de suffisamment d'espace, il faut d'abord redémarrer le service mysql : service mysql restart
- S'il y a suffisamment d'espace (au moins environ 20 %), il faut alors procéder à la réplication comme décrit ci-dessus.
Beaucoup de "journaux de relais" disponiblesMySQL écrit d'abord les journaux de relais du maître dans un fichier. Une fois que la réplication est interrompue, mais que le processus de relais esclave continue à fonctionner, le disque est rempli par les journaux de relais. Cette étape doit être effectuée dans tous les cas, surtout avant la prochaine (ibdata trop grande) pour faire de la place. ProcédureLes fichiers de la base de données se trouvent généralement dans /var/lib/mysql Si ce n'est pas le cas, le lieu peut être trouvé dans /etc/my.cnf L'entrée correspondante est datadir=(pfad) Effacer tous les journaux de relais : Translations Ignore |
---|
cd /var/lib/mysql rm mysqld-relay-bin* |
Redémarrer le service MySQL Translations Ignore |
---|
service mysqld restart |
Si l'espace disponible est suffisant (au moins 20 %), il faut alors procéder à la récupération d'esclave comme décrit ci-dessus. Fichiers fichiers ibdata sur l'esclave "très grand"Les fichiers de la base de données se trouvent généralement dans /var/lib/mysql En raison de l'absence de documentation claire sur MySQL internas, le fichier /var/lib/mysql/ibdata1 peut être énorme par rapport à la base de données principale. Pour y remédier, il faut procéder avec un peu plus de rigueur. Procédure- Si les étapes ci-dessus permettent d'atteindre au moins 100 % de disque :
Désinscrire le service MySQL au démarrage automatique : Translations Ignore |
---|
service mysqld disable |
Redémarrez l'ordinateur avec : Translations Ignore |
---|
reboot |
Ne fonctionne que si le disque est inférieur à 100% (éventuellement après le redémarrage ci-dessus) alors Connectez-vous au serveur mysql : Translations Ignore |
---|
mysql -u root -p |
Supprimer toutes les bases de données JTEL : Translations Ignore |
---|
SET FOREIGN_KEY_CHECKS=0; DROP DATABASE JTELLog; DROP DATABASE JTELStats; DROP DATABASE JTELWeb; SET FOREIGN_KEY_CHECKS=1; |
Appuyez sur CTRL+C pour revenir à la ligne de commande, puis Translations Ignore |
---|
service mysqld stop rm /var/lib/mysql/ibdata* rm /var/lib/mysql/ib_log_* |
Démarrez MySql Server, et réactivez-le si nécessaire : Translations Ignore |
---|
service mysqld start service mysqld enable |
Vérifiez l'espace disque, et procédez à la restauration des esclaves comme décrit ci-dessus.
Toujours pas d'espace disque > 20% gratuitDans ce cas, l'esclave est tout simplement trop petit. Le disque dur doit être étendu (comme pour l'extension du rôle STORE, ne s'appliquer applique qu'au volume logique où résident les données de la base de données MySQL). Ensuite Effectuez ensuite à nouveau les étapes, si le disque est trop petit, il faut à nouveau effectuer les étapes, puis restaurer restaurez l'esclave comme décrit ci-dessus. Ou bien l'esclave est complètement reconstruit avec une plaque plus grande. |