Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation
languageen

Rebuild Slave-DB & Replication

Da der Befehl mysqldump die Tables locked, ist es nicht notwendig, dass auf der Master Datenbank kein Traffic ist. Durch Since the mysqldump command locks the tables, it is not necessary that there is no traffic on the master database. With --master-data wird im Befehl mysqldump die richtige Position zum Einsetzen der Replication auf dem Slave Server hinterlegt. 

Falls die Festplatte des Slaves voll ist, dann bitte die Anleitung auf dieser Seite weiter unten - "Slave Platte Voll" betrachten.

the command mysqldump stores the correct position for inserting the replication on the slave server. 

If the hard disk of the slave is full, please refer to the instructions on this page below - "Slave Disk Full".

  1. Login to slave server
    • Login to MySQL with credentials USER and PWD, then stop slave and leave MySQL again. Use the following commands for this

    Auf Slave-Server anmelden
    • Anmeldung in MySQL mit Credentials USER und PWD, danach Slave stoppen und MySQL wieder verlassen. Dafür folgende Befehle nutzen:

      Translations Ignore
      • mysql -uUSER -pPWD

      • STOP SLAVE;

      • RESET SLAVE;

      • QUIT;


    • Restart MySQL Server mit with service mysqld restart neu starten.

  2. 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: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

    • 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 As of release 3.12 wird folgender Befehl benötigtthe following command is required:

    • 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ärungHere is a brief explanation of this:

    • <Name LogFile> und  and <Position LogFile> werden durch  are saved through --master-data im Dump gespeichert. in the dump
    • use only the JTEL databasesnur die JTEL-Datenbanken verwenden '--databases'
    • alle Datenbanken vor Import löschen  delete all databases before import  '--add-drop-database'alle Tabelle der Datenbanken vor Import löschen
    • delete all tables of the databases before import '--add-drop-table'
    • alle Routinen und Prozeduren im Dump implementierenImplement all routines and procedures in the dump '--events --routines'
    • Zusätzlich kann noch der Parameter Additionally the parameter --default_character_set utf8 verwendet werden can be used

    Warning

    In Versionen versions 3.12, 3.14 und and 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.

    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 slaveWenn 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 versions 3.11 und abwärts sowie Version and below and version 3.16 besteht dieses Problem nichtthis problem does not exist.


  3. MySQL-Dump vom Master Datenbankserver auf den Slave Datenbank Server kopieren.
    Verwende hierfür das Tool deiner Wahl: Kommandozeile Copy MySQL dump from master database server to slave database server
    Use the tool of your choice: command line (scp), WinSCP, ...

  4. Wir wechseln wieder auf den Slave-Server und importieren nun den We switch back to the slave server and now import the mysqldump.

    Translations Ignore
    • mysql -uUSER -pPWD (Nun sind wir in MySQLwe 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>;


  5. Wir ermitteln nun die Replikationsparameter, da wir sie gleich benötigen werdenWe are now determining the replication parameters, as we will need them in a moment:
    • In der mysqldump Datei ganz am Anfang finden wir im Kommentarblock eine Zeile, die folgendermaßen aussiehtthe mysqldump file at the very beginning we find a line in the comment block that looks like this: CHANGE MASTER TO MASTER_LOG_FILE='binlog.000872', MASTER_LOG_POS=11940974; Die Parameter Memorize the parameters MASTER_LOG_FILE und MASTER_LOG_POS muss man sich merken.
    • Wir brauchen den Namen oder die IP vom We need the name or IP of the Master DB Server
    • Wir brauchen das Passwort des Benutzers repl auf dem We need the password of user repl on the 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:  This is usually always the password of the user root - the easiest way to try it is to log on from the slave to the master with this password: mysql -h <masterIP> -u repl -p<Passwort> - wenn das Funktioniert, weiss man bescheid. if this works, then you know.
  6. Now on the slave server there is already a consistent, fairly new state of the data. It is now only necessary to reconfigure the replication. The following commands do thisJetzt befindet sich auf dem Slave server schon eine konsistente, einigermaßen neuer Stand der Daten. Es ist nun nur noch erforderlich die Replikation neu zu konfigurieren. Dazu folgende Befehle:
    • mysql -uUSER -pPWD

    • CHANGE MASTER TO MASTER_HOST='<name oder IP des or ip of 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 ersetzenHere all parameters must be replaced with those from step 5.

      Translations Ignore
      • START SLAVE;


    Nun überprüfen wir den Slave Status (ein paar mal) mit dem Befehl: Now we check the slave status (a few times) with the command 

    Translations Ignore
    • SHOW SLAVE STATUS\G
    und erwarten folgendes Ergebnis


    and expect the following result:
    • Slave_IO_Running: Yes

    • Slave_SQL_Running: Yes

    Damit läuft die Replikation nun wieder. Der Name des Logfiles und die Position sollten zeitnah ziemlich genau denen des show master status auf der Master-Datenbank entsprechen.
  7. Aufräumen von Datenmüll nicht vergessen! D.h. mysqldumps und Verzeichnisse zumindest auf dem Slave wieder löschen. Auf der Master Datenbank kann ein Backup bleiben, sofern genügend Platz vorhanden ist. 

Slave Platte Voll

Es gibt diverse Gründe, warum die Slave Platte voll-laufen kann.

tmp Verzeichnis ist voll

Hintergrund

  1. Now the replication is running again. The name of the logfile and the position should promptly correspond pretty much to the show master status on the master database.

  2. Do not forget to clean up data garbage! I.e. delete mysqldumps and directories at least on the slave. A backup can remain on the master database, provided there is enough space. 

Slave Disk Full

There are several reasons why the slave disk can become full.

tmp directory is full

Background

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 variablesJedes 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  aswell as max_heap_table_size definiert.

Siehe auch See also https://dev.mysql.com/doc/refman/5.6/en/internal-temporary-tables.html für mehr Information for more information

Die Tabellen The tables in /tmp werden solange gehalten, bis die jeweilige DB-Verbindung geschlossen wird, oder ein are kept until the respective DB connection is closed or a 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

  1. Es muss erstmal Platz geschaffen werden. Einfach gnadenlos alles aus /tmp löschen.
  2. Falls dies genügend Platz verschafft, dann erstmal den mysql Dienst neustarten: service mysql restart
  3. 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

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

Procedure

  1. Space must first be made available. Just mercilessly delete everything from /tmp.
  2. If this provides enough space, then restart the mysql service first: service mysql restart
  3. If there is enough space (at least about 20%), then proceed with replication as described above.

Lots of "relay logs" available

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 Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql

Falls nicht, dann ist der Speicherort If not, the location can be found in /etc/my.cnfzu finden. Der Entsprechende Eintrag ist  The corresponding entry is datadir=(pfad)

  1. Alle Relay Logs löschen:

    Translations Ignore

    cd /var/lib/mysql
    rm mysqld-relay-bin*

    Restart MySQL Dienst neustartenservice

    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ß"

  1. If enough space is available (at least 20%) then proceed with the slave recovery as described above.

ibdata files on the slave "very large"

The files for the database are usually located in Die Dateien für die Datenbank befinden sich in der Regel in /var/lib/mysql

Auf Grund von nicht klar dokumentierte Due to not clearly documented MySQL internas, kann die Datei the file /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

can be huge compared to the master database.
To remedy this, you have to proceed a little more rigorously.

Procedure

  1. If no less than 100% disk can be achieved by the steps above:
    1. Unsubscribe the MySQL service from the autostart

    Falls nicht weniger als 100% Platte durch die Schritte Oben erreicht werden kann:
    1. Den MySQL Dienst aus der Autostart austragen:

      Translations Ignore

      service mysqld disable


    2. Den Rechner neu starten mitRestart the computer with :

      Translations Ignore

      reboot

      Geht nur wenn weniger als 100% Platte erreicht ist (ggf. nach Reboot oben) dann:

      Only works if less than 100% disk is reached (possibly after reboot above) then

      1. Log on to the mysql serverAuf den mysql Server anmelden:

        Translations Ignore

        mysql -u root -p


      2. Alle Drop all JTEL Datenbanken droppendatabases:

        Translations Ignore

        SET FOREIGN_KEY_CHECKS=0;
        DROP DATABASE JTELLog;
        DROP DATABASE JTELStats;
        DROP DATABASE JTELWeb;
        SET FOREIGN_KEY_CHECKS=1;

        Mit Press CTRL+C wieder auf die Kommandozeile, und dann:to return to the command line, and then

        Translations Ignore

        service mysqld stop
        rm /var/lib/mysql/ibdata*
        rm /var/lib/mysql/ib_log_*

        Start MySql Server starten, und ggf. wieder enablen, and enable it again if necessary:

        Translations Ignore

        service mysqld start
        service mysqld enable

        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.

      1. Check disk space, and proceed with Slave Restore as described above.

Still no disk space > 20% free

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 plateOder der Slave wird komplett neu gebaut mit einer größeren Platte.

Sv translation
languagede

Rebuild Slave-DB & Replication

Da der Befehl mysqldump die Tables locked, ist es nicht notwendig, dass auf der Master Datenbank kein Traffic ist. Durch --master-data wird im Befehl mysqldump die richtige Position zum Einsetzen der Replication auf dem Slave Server hinterlegt. 

Falls die Festplatte des Slaves voll ist, dann bitte die Anleitung auf dieser Seite weiter unten - "Slave Platte Voll" betrachten.

  1. Auf Slave-Server anmelden
    • Anmeldung in MySQL mit Credentials USER und PWD, danach Slave stoppen und MySQL wieder verlassen. Dafür folgende Befehle nutzen:

      Translations Ignore
      • mysql -uUSER -pPWD

      • STOP SLAVE;

      • RESET SLAVE;

      • QUIT;


    • MySQL Server mit service mysqld restart neu starten.

  2. 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:

    • <Name LogFile> und <Position LogFile> werden durch --master-data im Dump gespeichert.
    • nur die JTEL-Datenbanken verwenden '--databases'
    • alle Datenbanken vor Import löschen  '--add-drop-database'
    • alle Tabelle der Datenbanken vor Import löschen '--add-drop-table'
    • alle Routinen und Prozeduren im Dump implementieren '--events --routines'
    • Zusätzlich kann noch der Parameter --default_character_set utf8 verwendet werden

    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.


  3. MySQL-Dump vom Master Datenbankserver auf den Slave Datenbank Server kopieren.
    Verwende hierfür das Tool deiner Wahl: Kommandozeile (scp), WinSCP, ...

  4. Wir wechseln wieder auf den Slave-Server und importieren nun den mysqldump.

    Translations Ignore
    • mysql -uUSER -pPWD (Nun sind wir 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>;


  5. Wir ermitteln nun die Replikationsparameter, da wir sie gleich benötigen werden:
    • 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 Parameter MASTER_LOG_FILE und MASTER_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.
  6. Jetzt befindet sich auf dem Slave server schon eine konsistente, einigermaßen neuer Stand der Daten. Es ist nun nur noch erforderlich die Replikation neu zu konfigurieren. Dazu folgende Befehle:
    • 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
      • START SLAVE;


    Nun überprüfen wir den Slave Status (ein paar mal) mit dem Befehl: 

    Translations Ignore
    • SHOW SLAVE STATUS\G


    und erwarten folgendes Ergebnis:
    • Slave_IO_Running: Yes

    • Slave_SQL_Running: Yes

    Damit läuft die Replikation nun wieder. Der Name des Logfiles und die Position sollten zeitnah ziemlich genau denen des show master status auf der Master-Datenbank entsprechen.

  7. Aufräumen von Datenmüll nicht vergessen! D.h. mysqldumps und Verzeichnisse zumindest auf dem Slave wieder löschen. Auf der Master Datenbank kann ein Backup bleiben, sofern genügend Platz vorhanden ist. 

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

  1. Es muss erstmal Platz geschaffen werden. Einfach gnadenlos alles aus /tmp löschen.
  2. Falls dies genügend Platz verschafft, dann erstmal den mysql Dienst neustarten: service mysql restart
  3. 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)

  1. 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

  1. Falls nicht weniger als 100% Platte durch die Schritte Oben erreicht werden kann:
    1. Den MySQL Dienst aus der Autostart austragen:

      Translations Ignore

      service mysqld disable


    2. Den Rechner neu starten mit:

      Translations Ignore

      reboot

      Geht nur wenn weniger als 100% Platte erreicht ist (ggf. nach Reboot oben) dann:

      1. Auf den mysql Server anmelden:

        Translations Ignore

        mysql -u root -p


      2. Alle JTEL Datenbanken droppen:

        Translations Ignore

        SET FOREIGN_KEY_CHECKS=0;
        DROP DATABASE JTELLog;
        DROP DATABASE JTELStats;
        DROP DATABASE JTELWeb;
        SET FOREIGN_KEY_CHECKS=1;

        Mit CTRL+C wieder auf die Kommandozeile, und dann:

        Translations Ignore

        service mysqld stop
        rm /var/lib/mysql/ibdata*
        rm /var/lib/mysql/ib_log_*

        MySql Server starten, und ggf. wieder enablen:

        Translations Ignore

        service mysqld start
        service mysqld enable

        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.