Heim  >  Artikel  >  Datenbank  >  Ausführliche Erläuterung des Problems der Datensicherung mit dem MySQL-Befehl unter Linux

Ausführliche Erläuterung des Problems der Datensicherung mit dem MySQL-Befehl unter Linux

黄舟
黄舟Original
2017-03-03 14:30:051423Durchsuche

In den letzten Tagen hat das Unternehmen ein neues komponentenbasiertes Projekt gestartet, das den Einsatz von MySQL-Datenbank-bezogenen Technologien erfordert. Da ich Mongodb schon einmal verwendet habe, ist MySQL fast in Vergessenheit geraten, sodass ich nur anfangen kann drüben in einer Linux-VM-Studie.

Grundlegendes Hinzufügen, Löschen, Ändern und Abfragen waren in Ordnung, aber ich hatte einige Probleme mit der Datensicherung. Glücklicherweise gelang es mir nach einigen Versuchen.

Die im Internet erwähnte API von MySQL und der Sicherungsbefehl lauten: mysqldump -uroot –p zu sichernder Datenbankname> Zielpfad/Name der Zieldatei.sql, also habe ich es erneut eingegeben, aber das Ergebnis Es wurde eine Ausnahme aus dem Jahr 2002 gemeldet. (Zusätzlich: Als ich diesen Befehl zum ersten Mal verwendete, wurde mir angezeigt, dass mysqldump nicht gefunden werden konnte. Später habe ich einen Softlink-LN verwendet, um die tatsächliche Adresse des Befehls mysqldump mit usr/bin zu verbinden):

mysqldump:Got error: 2002: Can't connect to local MySQL server through socket'/tmp/mysql.sock' (2) when trying to connect,
如图1:

Nachdem ich die Informationen überprüft hatte, nahm ich einige Änderungen vor, wie in Abbildung 2 gezeigt:


Aber zu diesem Zeitpunkt, 2002, ist es weg, aber stattdessen gibt es einen 1045-Fehler: mysqldump: Got error: 1045: Access denied for user 'root'@'localhost'(using password: YES) when try to connect, as siehe Abbildung 3:


Ich vermute, das bedeutet, dass es ein Problem mit den Root-Benutzer- und Localhost-Berechtigungen gibt, weil ich mich daran erinnere, als ich den MySQL-Remotezugriff eingerichtet habe , ich habe den Host auf % gesetzt:




Nachdem ich erneut online gesucht hatte, stellte ich fest, dass ich einen anderen Sicherungsbefehl gefunden und ausprobiert hatte, und stellte fest, dass er funktionierte, wie in Abbildung 5 dargestellt:


An diesem Punkt Die MySQL-Datenbank wurde erfolgreich in der virtuellen Linux-Maschine gesichert, aber dieser Befehl war zu lang. Dann dachte ich, dass die API von MySQL korrekt sein sollte, also dachte ich darüber nach, sie zu optimieren.

Nun, da ich wahrscheinlich vermute, dass der 1045-Fehler ein Problem mit den Benutzerberechtigungen ist, fange ich hier an. Wenn es keinen Root-Localhost gibt, füge ihn hinzu. Geben Sie die Datenbank ein, verwenden Sie MySQL, wie in Abbildung 4 gezeigt, und fügen Sie dann den Benutzer hinzu, wie in Abbildung 6 gezeigt:


Überprüfen Sie die Benutzertabelle erneut kann feststellen, dass es erfolgreich hinzugefügt wurde, wie in Abbildung 7 dargestellt:


Dann kann der Sicherungsbefehl in den optimierten Befehl geändert werden, wie in Abbildung 8 dargestellt:


Natürlich ist der Befehl kürzer geworden, aber er ist immer noch nicht kurz genug, also habe ich noch einmal nach Informationen gesucht und eine Lösung gefunden, die ich verlinken muss Die tatsächliche Verweisadresse von mysql.sock auf die Adresse im Fehler von 2002 ist wie in Abbildung 9 dargestellt:


Dann ist es wahrscheinlich der Moment Um das Wunder zu erleben, ist es an der Zeit, zu überprüfen, was die API sagt: Geben Sie den Befehl ein, drücken Sie die Eingabetaste und führen Sie erneut eine erfolgreiche Sicherung durch, wie in Abbildung 10 gezeigt:


Zusammenfassend lässt sich sagen, dass es für die Sicherung in drei Befehlsmethoden unterteilt werden kann. Wenn Sie es nur knapp verstehen, werden Sie es wissen. Tatsächlich handelt es sich nur um eine Art.

Das Obige ist eine detaillierte Erklärung des Problems der Datensicherung mit dem MySQL-Befehl unter Linux. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn)!


Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn