Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
IntroductionThis page describes the process of rebuilding a Rebuild Slave-DB & Replication. Since the mysqldump MySQL Dump command locks the tables, it is not necessary that there is no need to create it when there is no traffic on the master databasemachine. It can be done during operational hours. With --master-data the command mysqldump stores the correct position for inserting the replication on the slave server.
Step-By-Step Guide
STOP SLAVELogin to the Slave Database MySQL and stop the slave SQL. Leave MySQL again afterwards. Use Login to MySQL with credentials USER and PWD, then stop slave and leave MySQL again. Usethe following commands for this: translations-ignore
Restart MySQL Server with the following command:
Write a MySQL dump. Now perform the following steps on the master server. Create a backup directory and change to the same. The MySQL dumb is now executed with the following command
Here is a brief explanation of this:
Use the tool of your choice: command line (scp), WinSCP, ... We switch back to the slave server and now import the mysqldump.
Now we check the slave status (a few times) with the command
Slave Disk FullThere are several reasons why the slave disk can become full. tmp directory is fullBackgroundEvery time a query creates a tmp table, it is written to the temp directory, usually /tmp. This happens when the maximum size exceeds the maximum "in memory" table size. This is defined with the variables See also https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html for more information. The tables in /tmp are kept until the respective DB connection is closed or a DROP TEMPORARY TABLE is called. If the /tmp directory is full, it is likely that a DROP TEMPORARY TABLE is missing somewhere. This can also happen through customer queries to the DB. The installation of tmpwatch creates help in a permanent way Hints:
Procedure
Lots of "relay logs" availableMySQL first writes the relay logs from the master to a file. Once replication is interrupted, but the slave relay process continues to operate, the disk is filled by relay logs. This step should be done in any case, especially before the next one (ibdata too large) to make room. ProcedureThe files for the database are usually located in /var/lib/mysql If not, the location can be found in /etc/my.cnf The corresponding entry is datadir=(pfad)
ibdata files on the slave "very large"The files for the database are usually located in /var/lib/mysql Due to not clearly documented MySQL internas, the file /var/lib/mysql/ibdata1 can be huge compared to the master database. To remedy this, you have to proceed a little more rigorously. ProcedureIf no less than 100% disk can be achieved by the steps above:Unsubscribe the MySQL service from the autostart:
Restart the computer with :
Only works if less than 100% disk is reached (possibly after reboot above) then Log on to the mysql server:
Drop all JTEL databases:
Press CTRL+C to return to the command line, and then
Start MySql Server, and enable it again if necessary:
Check disk space, and proceed with Slave Restore as described above. Still no disk space > 20% freeIn this case the slave is simply too small. The hard disk must be expanded (as with extending the STORE role, apply only to the logical volume where the MySQL database data resides). Then perform the steps again, if the disk is too small, then restore the slave as described above. Or the slave is completely rebuilt with a larger plate. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sv translation | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Translations Ignore |
---|
|
MySQL Server mit service mysqld restart
neu starten.
Einen MySQL-Dump schreiben. Auf dem Master-Server nun folgenden Schritte durchführen. Dazu ein Backup-Verzeichnis anlegen und in selbiges wechseln. Der MySQL-Dumb wird nun mit dem folgenden Befehl ausgeführt:
mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql
Ab Release 3.12 wird folgender Befehl benötigt:
mysqldump -uUSER -pPWD --single-transaction --master-data=2 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > filename.sql
Hierzu eine kurze Erklärung:
Warning |
---|
In Versionen 3.12, 3.14 und 3.15: Wenn sich jemand am Portal Anmeldet, während der Dump gezogen wird, geht das schief. Anbei eine SQL abfrage. Wenn die Zeit sich nach dem ausführen der Abfrage ändert, hat ein Login stattgefunden. Wenn das passiert, muss der Dump erneut gezogen werden und währenddessen dauerhaft geprüft werden, ob ein Login stattgefunden hat. Nur wenn dem nicht so ist, kann man den Dump Fehlerfrei auf den Slave replizieren. SELECT Max(dtAcdLoggedIn) FROM Users; In Versionen 3.11 und abwärts sowie Version 3.16 besteht dieses Problem nicht. |
Verwende hierfür das Tool deiner Wahl: Kommandozeile (scp), WinSCP, ...
Wir wechseln wieder auf den Slave-Server und importieren nun den mysqldump.
Translations Ignore |
---|
|
- In der mysqldump Datei ganz am Anfang finden wir im Kommentarblock eine Zeile, die folgendermaßen aussieht:
CHANGE MASTER TO MASTER_LOG_FILE='binlog.000872', MASTER_LOG_POS=11940974;
Die ParameterMASTER_LOG_FILE
undMASTER_LOG_POS
muss man sich merken. - Wir brauchen den Namen oder die IP vom Master DB Server
- Wir brauchen das Passwort des Benutzers
repl
auf dem Master DB Server. Dies entspricht eigentlich immer dem Passwort des Benutzers root - man kann es am einfachsten ausprobieren, in dem man sich vom Slave auf dem Master mit diesem Passwort anmeldet:mysql -h <masterIP> -u repl -p<Passwort>
- wenn das Funktioniert, weiss man bescheid.
mysql -uUSER -pPWD
CHANGE MASTER TO MASTER_HOST='<name oder IP des master servers>',MASTER_USER='repl',MASTER_PASSWORD='<passwort>',MASTER_LOG_FILE='<Name LogFile>', MASTER_LOG_POS=<Position LogFile>;
Hier sind alle Parameter mit denen aus Schritt 5 zu ersetzen.
Translations Ignore |
---|
|
Nun überprüfen wir den Slave Status (ein paar mal) mit dem Befehl:
Translations Ignore |
---|
|
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Phase 1 - MySQL Dump
A MySQL Dump of the master database is now created. Perform the following steps to create a MySQL Dump and save it to the STORE:
Warning | ||
---|---|---|
| ||
The mysqldump command is different, depending on the jtel portal release, as well as the MySQL software release installed on the databases. All different options and how to find out which one to choose is specified below. |
Warning | ||
---|---|---|
| ||
The mysqldump commands on this page can NOT be used to realign a master-master replication. Visit the following page for that description Restore MySQL Master-Master Replication |
jtel Portal software release
Info |
---|
The following commands are designed to be executed on the STORE as jtel user |
Code Block |
---|
# change to jtel user
su jtel
# Find out which software release is installed
cd /srv/jtel/shared/JTELCarrierPortal
git status
# If /srv/jtel/.. does not exist on the STORE, attempt this
cd /home/jtel/shared/JTELCarrierPortal
git status
# Expected output
release-stable/3.XX |
Create Backup Directory
Info |
---|
The following commands are designed to be executed on the STORE as jtel user The following cd commands depend on the variable JT_DATE_TIME, which is set at the beginning of the next part. If the variable is not set, commands will fail. |
Code Block |
---|
# Create backup directory
JT_DATE_TIME=$(date +%F)
mkdir /srv/jtel/shared/backup/${JT_DATE_TIME}
# If /srv/jtel/.. does not exist on the load balancer, attempt this
JT_DATE_TIME=$(date +%F)
mkdir /home/jtel/shared/backup/${JT_DATE_TIME} |
Create MySQL Dump
Warning | ||
---|---|---|
| ||
Credentials and IP-Adresses need to be changed before the following mysqldump commands can be executed |
To Check for MySQL Version, log in to the master database server and execute the following command
Code Block |
---|
mysql --version |
Info |
---|
The following commands are designed to be executed on the STORE as jtel user |
MySQL Dump - Until jtel Portal release 3.12
Warning | ||
---|---|---|
| ||
If someone logs on to the portal while the dump is being pulled, it will go wrong. Enclosed a SQL query. If the time changes after executing the query, a login has taken place. If this happens, the dump has to be pulled again and in the meantime it has to be permanently checked if a login has taken place. Only if this is not the case, the dump can be replicated error-free to the slave. SELECT Max(dtAcdLoggedIn) FROM Users; In versions 3.11 and below and version 3.16 this problem does not exist. |
Code Block |
---|
# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELLog --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql |
MySQL Dump - From jtel Portal release 3.12 until 3.31
Code Block |
---|
# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql |
MySQL Dump - From Release 3.32
Code Block |
---|
# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --master-data=1 --databases JTELWeb JTELStats JTELStats2 JTELLog JTELCustomer --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql |
MySQL Dump - From MySQL 8.0.27
Code Block |
---|
# change to jtel user
su jtel
# Change to backup directory
cd /srv/jtel/shared/backup/${JT_DATE_TIME}
# Create MysQL Dump
mysqldump -uUSER -pPWD -h<IP-Address-OR-Alias-GOOD-MASTER> --single-transaction --source-data --databases JTELWeb JTELStats JTELStats2 JTELLog --add-drop-database --add-drop-table --events --routines --triggers > /srv/jtel/shared/backup/${JT_DATE_TIME}/acd-dbm_<yyyymmdd>.sql |
Brief Explanation of the mysqldump command
<Name LogFile> and <Position LogFile> are saved through --master-data or --source-data in the dump
use only the JTEL databases '--databases'
delete all databases before import '--add-drop-database'
delete all tables of the databases before import '--add-drop-table'
Implement all routines and procedures in the dump '--events --routines'
Additionally the parameter --default_character_set utf8 can be used
Phase 2 - Import Dump on Slave Database
Info |
---|
The following commands are designed to be run from the STORE as root user. After the source <acd-dbm_<yyyymmdd>.sql> is executed, the dump will start importing into the slave database. Once it is finished, the Slave SQL is started. Brief explanation - tmux: tmux is a tool used to create sub-sessions within a ssh terminal. The tool is a good option for this specific operation, since the sub-session can be exited but the processes which were started will still be running in the background. This prevents failure by accidental loss of the ssh terminal, and provides the ability to view the MySQL process list to check the progress of the import Tmux cheat sheet: https://tmuxcheatsheet.com/ |
Import Dump - tmux
Code Block |
---|
# switch to root user
sudo -s
# start tmux sub-session
tmux new
# change to the directory where the dump file is located
JT_DATE_TIME=$(date +%F)
cd /srv/jtel/shared/backup/${JT_DATE_TIME}/
# copy the dump-filename
ls -als
# log in to mysql and import the dump
mysql -hacd-dbs -uroot -p<password>
source <acd-dbm_<yyyymmdd>.sql>; |
Import Dump - No tmux
Code Block |
---|
# switch to root user
sudo -s
# change to the directory where the dump file is located
JT_DATE_TIME=$(date +%F)
cd /srv/jtel/shared/backup/${JT_DATE_TIME}/
# copy the dump-filename
ls -als
# log in to mysql and import the dump
mysql -hacd-dbs -uroot -p<password>
source <acd-dbm_<yyyymmdd>.sql>; |
Check status
You can check the progress by executing the following command on acd-dbs
Code Block |
---|
watch 'mysql -uroot -p<password> -e "SHOW PROCESSLIST;"' |
Start Slave - tmux
Code Block |
---|
# If not attached to the sub-session anymore
tmux attach
# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G |
Start Slave - No tmux
Code Block |
---|
# Start Slave SQL
START SLAVE;
# Check Slave Status
SHOW SLAVE STATUS \G |
Slave Disk Full
There are several reasons why the slave disk can become full. Following is a summary of the different cases and further below is a detailed explanation:
Case |
---|
Temp directory full |
Lots of "relay logs" available |
ibdata files on the slave "very large" |
Still no disk space > 20% free |
tmp Directory Is Full
Introduction
Every time a query creates a tmp table, it is written to the temp directory, usually /tmp. This happens when the maximum size exceeds the maximum "in memory" table size. This is defined with the variables tmp_table_size
aswell as max_heap_table_size .
The tables in /tmp are kept until the respective DB connection is closed or a DROP TEMPORARY TABLE is called. If the /tmp directory is full, it is likely that a DROP TEMPORARY TABLE is missing somewhere. This can also happen through customer queries to the DB.
The installation of tmpwatch creates help in a permanent way
Hints:
- On CentOS 6 the /tmp directory is then by default freed from files that have not been accessed for > 10 days
- Circumstantially this may not be sufficient
- On CentOS 7 the /tmp directory is then freed by default from files that have not been accessed for> 1 day
Info |
---|
See also https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html for more information. |
Procedure
- Space must first be made available. Just mercilessly delete everything from /tmp.
- If this provides enough space, then restart the mysql service first: service mysql restart
- If there is enough space (at least about 20%), then proceed with replication as described above.
Lots of "relay logs" available
Introduction
MySQL first writes the relay logs from the master to a file. Once replication is interrupted, but the slave relay process continues to operate, the disk is filled by relay logs.
This step should be done in any case, especially before the next one (ibdata too large) to make room.
Procedure
The files for the database are usually located in /var/lib/mysql
If not, the location can be found in /etc/my.cnf The corresponding entry is datadir=(pfad)
Delete all relay logs:
Info |
---|
Slave Platte Voll
Es gibt diverse Gründe, warum die Slave Platte voll-laufen kann.
tmp Verzeichnis ist voll
Hintergrund
Jedes Mal, wenn eine Query eine tmp Tabelle anlegt, wird dies in das temp Verzeichnis, üblicherweise /tmp geschrieben. Dies geschieht dann, wenn die maximale Größe der maximale "in Memory" Tabellengröße überschritten wird.Dies wird mit den Variablen tmp_table_size
sowie max_heap_table_size
definiert.
Siehe auch https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html für mehr Information.
Die Tabellen in /tmp werden solange gehalten, bis die jeweilige DB-Verbindung geschlossen wird, oder ein DROP TEMPORARY TABLE aufgerufen wird. Falls das /tmp Verzeichnis voll-läuft, ist zu vermuten dass ein DROP TEMPORARY TABLE irgendwo fehlt. Dies kann durchaus auch durch Kunden-Abfragen an die DB geschehen.
Aushilfe auf permanente Weise schafft hier die Installation von tmpwatch
Hinweise:
- Auf CentOS 6 wird das /tmp Verzeichnis dann standardmäßig dann von Dateien auf den kein Zugriff > 10 Tage nicht erfolgt ist befreit
- Unter Umständen reicht dies nicht aus
- Auf CentOS 7 wird das /tmp Verzeichnis dann standardmäßig dann von Dateien auf den kein Zugriff > 1 Tag nicht erfolgt ist befreit
Vorgehensweise
- Es muss erstmal Platz geschaffen werden. Einfach gnadenlos alles aus /tmp löschen.
- Falls dies genügend Platz verschafft, dann erstmal den mysql Dienst neustarten: service mysql restart
- Falls dann genug Platz vorhanden ist (mindestens ca. 20%), dann mit Wiederherstellung der Replikation wie Oben beschrieben fortfahren.
Jede Menge "relay Logs" vorhanden
MySQL schreibt die Relay-Logs vom Master erstmal in eine Datei. Wenn die Replikation erstmal gebrochen ist, aber der Slave Relay Prozess weiter arbeitet, dann wird die Platte durch Relay Logs befüllt.
Dieser Schritt sollte im jeden Fall durchgeführt werden, insbesondere vor dem nächsten (ibdata zu groß), um Platz zu schaffen.
Vorgehensweise
Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql
Falls nicht, dann ist der Speicherort in /etc/my.cnf zu finden. Der Entsprechende Eintrag ist datadir=(pfad)
Alle Relay Logs löschen:
Translations Ignore cd /var/lib/mysql
rm mysqld-relay-bin*MySQL Dienst neustarten
Translations Ignore service mysqld restart
Falls genug Platz vorhanden (mind. 20%) dann mit der Wiederherstellung des Slaves fortfahren wie oben beschrieben.
ibdata Dateien auf den Slave "Riesen-Groß"
Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql
Auf Grund von nicht klar dokumentierte MySQL internas, kann die Datei /var/lib/mysql/ibdata1 eine riesige Größe annehmen im Vergleich zu der Master Datenbank.
Um dies zu bereinigen, muss man etwas härter vorgehen.
Vorgehensweise
Falls nicht weniger als 100% Platte durch die Schritte Oben erreicht werden kann:Den MySQL Dienst aus der Autostart austragen:
Translations Ignore |
---|
service mysqld disable |
Den Rechner neu starten mit:
Translations Ignore |
---|
reboot |
Geht nur wenn weniger als 100% Platte erreicht ist (ggf. nach Reboot oben) dann:
Auf den mysql Server anmelden:
Translations Ignore |
---|
mysql -u root -p |
Alle JTEL Datenbanken droppen:
Translations Ignore |
---|
SET FOREIGN_KEY_CHECKS=0; |
Mit CTRL+C wieder auf die Kommandozeile, und dann:
Translations Ignore |
---|
service mysqld stop |
MySql Server starten, und ggf. wieder enablen:
Translations Ignore |
---|
service mysqld start |
Plattenplatz prüfen, und mit Slave Wiederherstellung wie oben beschrieben fortfahren.
Trotzdem kein Plattenplatz > 20% Frei
In diesen Fall ist der Slave einfach zu klein. Die Festplatte muss erweitert werden (wie bei Erweiterung der Rolle STORE, nur auf das Logical Volume anwenden auf den die Daten der MySQL Datenbank sich befinden). Dann die Schritte wieder durchführen, bei Platte zu Klein, dann Slave wieder herstellen wie Oben beschrieben.
Oder der Slave wird komplett neu gebaut mit einer größeren Platte.
language | fr |
---|
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 esclavesConnectez-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 |
---|
|
Redémarrer Serveur MySQL avec service mysqld restart
.
Écrire un MySQL dump. Exécutez maintenant les étapes suivantes sur le serveur maître. Créez un répertoire de sauvegarde et changez pour le mê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 :
Warning |
---|
Dans les versions 3.12, 3.14 et 3.15 Si quelqu'un se connecte au portail pendant que le vidage est extrait, cela va mal tourner. J'ai joint une requête SQL. Si l'heure change après l'exécution de la requête, 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. |
Utilisez l'outil de votre choix : ligne de commande (scp), WinSCP, ...
Nous retournons à la serveur esclave et maintenant importer mysqldump.
Translations Ignore |
---|
|
- 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
etMASTER_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.
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.
Translations Ignore |
---|
|
Maintenant, nous vérifions le statut de l'esclave (plusieurs fois) avec la commande
Translations Ignore |
---|
|
Slave_IO_Running: Oui
Slave_SQL_Running: Oui
Disque d'esclave complet
Il y a plusieurs raisons pour lesquelles le disque esclave peut devenir plein.
le répertoire tmp est complet
Informations générales
Chaque fois qu'une requête crée une table tmp, elle est écrite dans le répertoire temporaire, généralement/tmp. Cela se produit lorsque la taille maximale dépasse la taille maximale de la table "en mémoire". Ceci est défini avec les variables tmp_table_size
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 soit appelée. Si le répertoire / tmp est plein, il est probable qu'un DROP TEMPORARY TABLE manque quelque part. Cela peut également se produire via 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" disponibles
MySQL é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édure
Les 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-ignorecd /var/lib/mysql |
Restart MySQL service
MySQLtranslations-ignoreCode Block |
---|
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.
If enough space is available (at least 20%) then proceed with the slave recovery as described above.
ibdata files on the slave "very large"
Introduction
The files for the database are usually located in
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
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 :
Procedure
If no less than 100% disk can be achieved by the steps above:
Unsubscribe the MySQL service from the autostart:
Code Block |
---|
systemctl disable mysqld |
Restart the computer with :
Code Block |
---|
systemctl reboot now |
Only works if less than 100% disk is reached (possibly after reboot above) then
Log on to the mysql server:
Code Block |
---|
mysql -u root -p |
Drop all JTEL databases:
Code Block |
---|
SET |
FOREIGN_KEY_CHECKS=0; |
DROP DATABASE JTELLog; |
DROP DATABASE JTELStats; |
DROP DATABASE JTELWeb; |
SET FOREIGN_KEY_CHECKS=1; |
Press CTRL+C
pour revenir à la ligne de commande, puisrm
to return to the command line, and then
Code Block |
---|
service mysqld stop rm /var/lib/mysql/ibdata* |
rm /var/lib/mysql/ib_log_* |
Start MySql Server,
et réactivez-le si nécessaire :Translations Ignore |
---|
service mysqld start |
Vérifiez l'espace disque, et procédez à la restauration des esclaves comme décrit ci-dessus.
Toujours pas d'espace disque > 20% gratuit
Dans 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'applique qu'au volume logique où résident les données de la base de données MySQL). Effectuez ensuite à nouveau les étapes, si le disque est trop petit, restaurez l'esclave comme décrit ci-dessus.
Ou bien l'esclave est complètement reconstruit avec une plaque plus grande.and enable it again if necessary:
Code Block |
---|
service mysqld start
service mysqld enable |
Check disk space, and proceed with Slave Restore as described above.
Still no disk space > 20% free
Introduction
The slave disk space is still full, more than 80% of the space on the drive is used by normal operation
Solution
In this case the slave is simply too small. The hard disk must be expanded (as with extending the STORE role, apply only to the logical volume where the MySQL database data resides). Then perform the steps again, if the disk is too small, then restore the slave as described above.
Or the slave is completely rebuilt with a larger plate.
Sv translation | ||
---|---|---|
| ||
Sv translation | ||
---|---|---|
| ||