MySQL implementiert Protokollverwaltung, Sicherung und Wiederherstellung auf Unternehmensebene – praktisches Tutorial

Hintergrund

Mit der Entwicklung des Geschäfts expandieren das Geschäft und der Umfang des Unternehmens weiter, und auf der Website werden große Mengen an Benutzerinformationen und -daten gesammelt. Für ein Internetunternehmen sind Benutzer- und Geschäftsdaten die Grundlage. Wenn die Daten eines Unternehmens gestört werden oder verloren gehen, ist das für das Internetunternehmen eine Katastrophe. Um Datenverluste aufgrund von Systembetriebsfehlern oder Systemausfällen zu verhindern, muss das Unternehmen die Zuverlässigkeit der Benutzerdaten verbessern, die Datensicherung auf Datenebene umfassend verstärken und in der Lage sein, sie bei einem Ausfall so schnell wie möglich wiederherzustellen.

Formular zur Datensicherung

Dateisicherung:

Verwenden Sie den Linux-Sicherungsbefehl, um die Dateien zu packen und lokal oder auf einem Remote-Server zu speichern. Wenn Sie sie wiederherstellen müssen, können Sie diese Dateien verwenden, um sie am angegebenen Speicherort wiederherzustellen.

Datenbankdatensicherung:

In einigen Branchen mit hohen Anforderungen an die Datenzuverlässigkeit, wie etwa im Bank-, Wertpapier- und Telekommunikationssektor, können unerwartete Ausfallzeiten oder Datenverluste zu erheblichen Verlusten führen. Zu diesem Zweck sollten Datenbankadministratoren detaillierte Strategien für die Datenbanksicherung und Notfallwiederherstellung entwickeln, die auf spezifischen Geschäftsanforderungen basieren, und Ausfälle für jeden

Nur durch striktes Testen aller möglichen Situationen kann eine hohe Datenverfügbarkeit sichergestellt werden. Die Datenbanksicherung ist ein langwieriger Prozess, während die Wiederherstellung erst nach einem Unfall durchgeführt wird. Die Wiederherstellung kann als umgekehrter Prozess der Sicherung betrachtet werden. Der Grad der Wiederherstellung hängt weitgehend von der Sicherungssituation ab. Auch,

Ob die vom Datenbankadministrator während der Wiederherstellung unternommenen Schritte korrekt sind oder nicht, wirkt sich ebenfalls direkt auf die endgültigen Wiederherstellungsergebnisse aus.

Art der Datensicherung

Nach Unternehmen: Es kann in Voll-Backup, inkrementelles Backup, differentielles Backup unterteilt werden

1. Vollständige Sicherung: Sichern Sie die Daten und die Datenstruktur der gesamten Datenbank

Vorteile: intuitiv und leicht verständlich

Nachteile: 1. Ein Großteil der Sicherungsdaten wird dupliziert, was viel Platz beansprucht und die Kosten erhöht.

2. Die zu sichernde Datenmenge ist groß und dauert lange

(Vollsicherung) Bei der sogenannten Vollsicherung handelt es sich um eine Sicherung der Daten und Datenstruktur der kompletten Datenbank. Der Vorteil dieser Sicherungsmethode besteht darin, dass sie sehr intuitiv und leicht verständlich ist. Und wenn es zu einem Datenverlust kommt, können die verlorenen Daten mithilfe der Sicherungsdateien von vor dem Desaster wiederhergestellt werden.

Allerdings hat auch dieses Verfahren seine Nachteile: Erstens werden viele Sicherungsdaten wiederholt, da das System jeden Tag vollständig gesichert wird. Diese doppelten Daten benötigen viel Platz, was für die Benutzer erhöhte Kosten bedeutet. Zweitens ist die zu sichernde Datenmenge recht groß, so dass die Sicherung sehr lange dauert. Für Einheiten mit hohem Arbeitsaufkommen und begrenzten Zeitfenstern für Backups ist die Wahl dieser Backup-Strategie zweifellos nicht ratsam.

2. Inkrementelles Backup: Die jedes Mal gesicherten Daten entsprechen nur den Daten, die nach dem letzten Backup hinzugefügt und geändert wurden.

Vorteile: Keine doppelten Backup-Daten, dadurch Platzersparnis

Nachteile: Die Datenwiederherstellung ist mühsam und jedes Problem mit den Sicherungsdaten führt zu Datenverlust

Das heißt, die jedes Mal gesicherten Daten entsprechen nur den Daten, die seit der letzten Sicherung hinzugefügt und geändert wurden. Die Vorteile dieser Sicherungsart liegen auf der Hand: Es entstehen keine doppelten Sicherungsdaten, was Platz spart und die Sicherungszeit verkürzt. Der Nachteil besteht jedoch darin, dass die Daten im Katastrophenfall nur schwer wiederhergestellt werden können. Wenn zum Beispiel

Kommt es beispielsweise am Donnerstagmorgen zu einem Systemausfall und damit zu einem großen Datenverlust, muss das System wieder in den Zustand von Mittwochnacht versetzt werden.

Zu diesem Zeitpunkt muss der Administrator zuerst am Montag die vollständigen Sicherungsdaten finden, um das System wiederherzustellen, dann am Dienstag die Daten finden, um die Daten vom Dienstag wiederherzustellen, und dann am Mittwoch die Daten finden, um die Daten vom Mittwoch wiederherzustellen. Dies ist offensichtlich viel problematischer als die erste Strategie. Darüber hinaus ist dieses Backup zuverlässig

Der Sex ist auch schlecht. Bei dieser Art der Sicherung ist die Beziehung zwischen den einzelnen Sicherungsdaten wie eine Kette, ein Glied nach dem anderen. Wenn bei einer der Sicherungsdaten ein Problem auftritt, wird die gesamte Kette unterbrochen.

3. Differenzielles Backup: Jedes Backup enthält Daten, die seit dem letzten vollständigen Backup neu hinzugefügt oder geändert wurden.

Das heißt, die jedes Mal gesicherten Daten sind die nach der letzten vollständigen Sicherung neu hinzugefügten und geänderten Daten. Der Administrator führt am Montag zunächst eine vollständige Systemsicherung durch. Anschließend sichert er in den darauffolgenden Tagen alle Daten, die seit Montag neu hinzugekommen sind (neu oder geändert), auf Band. Beispiel: Am Montag führt der Netzwerkadministrator wie üblich eine vollständige Systemsicherung durch. Am Dienstag gibt es nur noch eine weitere Asset-Liste im System, sodass der Administrator nur diese Asset-Liste sichern muss. Am Mittwoch gibt es einen weiteren Produktkatalog im System, sodass der Administrator

Es sollte nicht nur dieser Katalog gesichert werden, sondern auch die Asset-Liste vom Dienstag.

Wenn am Donnerstag eine zusätzliche Gehaltsabrechnung im System vorliegt, müssen am Donnerstag folgende Inhalte gesichert werden: Gehaltsabrechnung + Produktkatalog + Anlagenliste. Daraus können wir ersehen, dass die Vollsicherung am längsten dauert, die Wiederherstellungszeit jedoch am kürzesten und die Bedienung am bequemsten ist. Wenn die Datenmenge im System nicht groß ist, ist die Vollsicherung am zuverlässigsten. Die differenzielle Sicherung kann die Mängel der beiden anderen Strategien vermeiden, aber in bestimmten Kombinationen können unterschiedliche Sicherungstypen vorhanden sein. In bestimmten Kombinationen können unterschiedliche Sicherungstypen vorhanden sein. In bestimmten Kombinationen können unterschiedliche Sicherungstypen vorhanden sein.

Beispiele für die Kombination verschiedener Sicherungstypen

Vollständige und differenzielle Backups

Vollständige Sicherungen werden montags und differenzielle Sicherungen von Dienstag bis Freitag durchgeführt. Wenn die Daten am Freitag beschädigt werden, müssen Sie nur das vollständige Backup vom Montag und das differenzielle Backup vom Donnerstag wiederherstellen. Bei dieser Strategie ist das Sichern der Daten zeitaufwändiger, die Wiederherstellung der Daten jedoch zeitaufwändiger.

Vollständige und inkrementelle Backups

Vollständige Sicherungen werden montags und inkrementelle Sicherungen von Dienstag bis Freitag durchgeführt. Wenn die Daten am Freitag beschädigt werden, müssen Sie das normale Backup vom Montag und alle inkrementellen Backups von Dienstag bis Freitag wiederherstellen. Mit dieser Strategie lässt sich die Datensicherung schneller durchführen, die Datenwiederherstellung nimmt jedoch mehr Zeit in Anspruch.

Klassifizierung nach Modus: kann in Hot-Standby, Warm-Standby und Cold-Standby unterteilt werden

Unter Hot Backup versteht man das Sichern einer Datenbank direkt während der Ausführung, ohne dass dabei Auswirkungen auf die laufende Datenbank auftreten.

Bei einem Cold Backup handelt es sich um ein Backup, das bei angehaltener Datenbank durchgeführt wird. Diese Art von Backup ist die einfachste und erfordert im Allgemeinen nur das Kopieren der relevanten physischen Datenbankdateien.

Ein Warm-Backup wird ebenfalls bei laufender Datenbank durchgeführt, wirkt sich jedoch auf aktuelle Datenbankvorgänge aus und fügt beispielsweise eine globale Lesesperre hinzu, um die Konsistenz der Sicherungsdaten sicherzustellen. (Wenn Sie eine Tabelle in der Datenbank sichern, sperren Sie die Tabelle zuerst, um zu verhindern, dass andere die Daten in der Tabelle hinzufügen, prüfen, löschen oder ändern. Auf diese Weise ändern sich die Daten in der Tabelle beim Sichern nicht, und die Konsistenz der Sicherungsdaten wird sichergestellt.)

Physische Sicherung: Sicherung durch direktes Kopieren von Datendateien (direkt kopierte und gesicherte Datendateien liegen im Binärformat vor)

Vorteile: Es sind keine zusätzlichen Tools erforderlich, einfach kopieren und wiederherstellen durch direktes Kopieren der Sicherungsdatei

Nachteile: bezogen auf die Speicher-Engine, schwache plattformübergreifende Fähigkeit

Logisches Backup: Ein Backup, das durch „Exportieren“ von Daten aus der Datenbank und separates Speichern dieser Daten durchgeführt wird (Exportieren von SQL-Anweisungen in eine Textdatei, die größer als eine Binärdatei ist).

Vorteile: Kann mit einem Editor bearbeitet werden, ist leicht wiederherzustellen, kann über das Netzwerk wiederhergestellt werden, hilft, Datenkorruption zu vermeiden

Nachteile: Die Sicherungsdatei ist groß, die Sicherung ist langsam, die Genauigkeit der Gleitkommazahlen kann nicht garantiert werden und nach der Wiederherstellung der logischen Sicherungsdaten muss der Index manuell neu erstellt werden, was viele CPU-Ressourcen verbraucht.

Sicherungsflussdiagramm

Einführung in das MySQL-Protokoll

MySQL-Protokolle:

Enthält hauptsächlich: Fehlerprotokoll, Abfrageprotokoll, Protokoll für langsame Abfragen, Transaktionsprotokoll, Binärprotokoll usw.;

Protokolle sind ein wichtiger Bestandteil der MySQL-Datenbank. Die Protokolldatei zeichnet die Änderungen auf, die während des Betriebs der MySQL-Datenbank auftreten. Das heißt, sie dient zur Aufzeichnung

Protokollieren Sie den Client-Verbindungsstatus der MySQL-Datenbank, den Ausführungsstatus von SQL-Anweisungen und Fehlermeldungen. Wenn die Datenbank versehentlich beschädigt wird, können Sie

Sie können die Ursache des Dateifehlers über die Protokolldatei anzeigen und die Daten über die Protokolldatei wiederherstellen.

Mysql-Fehlerprotokoll

In der MySQL-Datenbank ist die Fehlerprotokollfunktion standardmäßig aktiviert. Außerdem kann die Fehlerprotokollierung nicht deaktiviert werden. Standardmäßig wird das Fehlerprotokoll in der Datendatei der MySQL-Datenbank gespeichert. Die Fehlerprotokolldatei trägt normalerweise den Namen hostname.err. Hier gibt Hostname den Hostnamen des Servers an.

Die Fehlerprotokollinformationen können von Ihnen selbst konfiguriert werden. Die im Fehlerprotokoll aufgezeichneten Informationen können durch logerror und log-warnings definiert werden. Log-err definiert, ob die Fehlerprotokollfunktion und der Speicherort des Fehlerprotokolls aktiviert werden sollen, und log-warnings definiert, ob Warninformationen im Fehlerprotokoll definiert werden sollen. Standardmäßig zeichnet das Fehlerprotokoll die folgenden Informationen auf: Informationen während des Startens und Herunterfahrens des Servers (nicht unbedingt Fehlerinformationen, z. B. wie MySQL die InnoDB-Tablespace-Datei startet, wie die eigene Speicher-Engine initialisiert wird usw.), Fehlerinformationen während des Serverbetriebs, generierte Informationen, wenn der Ereignisplaner ein Ereignis ausführt, und generierte Informationen, wenn der Serverprozess vom Server gestartet wird.

mysql -uroot -p

Wählen Sie globale Variablen wie „%log%“ aus.

Sie können log_error über die Konfigurationsdatei ändern

vim /etc/my.cnf //Wie unten gezeigt: Ich habe den Pfad des Fehlerprotokolls in /var/log/mariadb/mariadb.err geändert

log-error=/var/log/mariadb/mariadb.err

Starten Sie dann den Datenbankdienst neu, um eine Verbindung zur Datenbank herzustellen und das globale Protokoll anzuzeigen. Die Änderung war erfolgreich.

Anzeigen des Inhalts des Fehlerprotokolls

Temporäre Änderung:

Im MySQL-Fehlerprotokoll kann log_error direkt als Dateipfad oder als ON|OFF definiert werden.

log_warings können nur mit 1|0 aktiviert werden.

Dauerhafte Änderung:

Um den Speicherort des Fehlerprotokolls zu ändern, können Sie mit log_error das Format wie folgt festlegen:

[root@stu18 Daten]# vim /etc/my.cnf

[mysqld]

Log_error=DIR/[Dateiname]

Analyse: Der Parameter DIR gibt den Pfad des Fehlerprotokolls an. Der Parameter filename ist der Name des Fehlerprotokolls. Wenn dieser Parameter nicht angegeben ist, wird standardmäßig der Hostname verwendet. Ändern Sie die Konfigurationsdatei und starten Sie den MySQL-Server neu, damit die Änderungen wirksam werden.

Hinweis: Vor MySQL 5.5.7: Datenbankadministratoren können lange zurückliegende Fehlerprotokolle löschen, um Festplattenspeicher auf dem MySQL-Server sicherzustellen. In der MySQL-Datenbank können Sie den Befehl mysqladmin verwenden, um ein neues Fehlerprotokoll zu öffnen.

Die Syntax des mysqladmin-Befehls lautet wie folgt:

mysqladmin –u root –pflush-logs Sie können sich auch bei der MySQL-Datenbank anmelden und mit der Anweisung FLUSHLOGS ein neues Fehlerprotokoll öffnen.

Mysql-Abfrageprotokoll

Standardmäßig ist die Abfrageprotokollierung deaktiviert. Da das Abfrageprotokoll alle Benutzervorgänge aufzeichnet, einschließlich Hinzufügungen, Löschungen, Abfragen und Änderungen, werden in einer Umgebung mit vielen gleichzeitigen Vorgängen große Mengen an Informationen generiert, was zu unnötigem Festplatten-E/A führt und die Leistung von MySQL beeinträchtigt. Es wird empfohlen, die Abfrageprotokollierung nicht zu aktivieren, wenn sie nicht zum Debuggen der Datenbank dient.

MySQL

globale Variablen wie „%log%“ anzeigen;

Mysql langsames Abfrageprotokoll

Das Protokoll langsamer Abfragen wird zum Aufzeichnen von Abfrageanweisungen verwendet, deren Ausführung länger als eine angegebene Zeit dauert. Über das Protokoll langsamer Abfragen können Sie herausfinden, welche Abfrageanweisungen eine geringe Ausführungseffizienz aufweisen (die Ausführung mancher Abfrageanweisungen dauert lange und Sie müssen diese Abfrageanweisungen finden und löschen, um die Serverleistung zu optimieren), damit Sie Optimierungen vornehmen können. Es wird dringend empfohlen, es zu aktivieren. Es hat nur geringe Auswirkungen auf die Serverleistung, kann jedoch Abfrageanweisungen aufzeichnen, die über einen langen Zeitraum auf dem MySQL-Server ausgeführt wurden. Es kann uns helfen, Leistungsprobleme zu lokalisieren.

Starten und richten Sie das Slow Query Log ein:

1. Das Protokoll für langsame Abfragen kann über die Option „log-slow-queries“ in der Konfigurationsdatei my.cnf aktiviert werden.

Das Formular lautet wie folgt:

vim /etc/meine.cnf

[mysqld]

slow-query-log = EIN

langsame Abfrage-Logdatei = /var/log/mariadb/slow.log

lange Abfragezeit = 0,01

Der Parameter DIR gibt den Speicherpfad des Slow Query-Logs an; der Parameter filename gibt den Dateinamen des Logs an. Der vollständige Name der generierten Logdatei lautet filename-slow.log. Wenn der Speicherpfad nicht angegeben ist, wird das Slow-Query-Log standardmäßig in der Datendatei der MySQL-Datenbank gespeichert. Wenn der Dateiname nicht angegeben ist, lautet der Standarddateiname hostname-slow.log

2. Definieren Sie direkt durch die Anmeldung am MySQL-Server

So geht's:

Zuerst müssen Sie über globale Berechtigungen verfügen. Führen Sie dann mysql>set global slow_query_log=1 aus. (vorübergehender Effekt: SQL-Anweisungen, deren Ausführung länger als 1 Sekunde dauert, werden als langsame Abfrageprotokolle bezeichnet.)

Wie hoch ist standardmäßig das Zeitlimit für ein langsames Abfrageprotokoll?

Dieser Zeitwert wird normalerweise über die Option long_query_time festgelegt. Die Zeit wird in Sekunden angegeben und kann auf Mikrosekunden genau sein. Wenn die Abfragezeit diesen Zeitwert überschreitet (der Standardwert beträgt 10 Sekunden), wird die Abfrageanweisung im Protokoll für langsame Abfragen aufgezeichnet. Um den Standardwert für die Serverzeit anzuzeigen, gehen Sie wie folgt vor:

Hinweis: Die langsame Abfragezeit bedeutet nicht nur, dass die Anweisungsausführung selbst 10 Sekunden überschreitet. Sie umfasst auch die Abfrageausführungszeit, die aufgrund der Anforderung anderer Ressourcen oder aus anderen Gründen blockiert ist. Diese werden alle in der langsamen Abfrage aufgezeichnet. Daher stellt die Dauer dieser langsamen Abfrage die gesamte Zeit vom Beginn der Abfrage bis zum Ende der Abfrage dar, einschließlich aller möglichen Gründe.

Anzeigen des Inhalts des Protokolls für langsame Abfragen

Mysql-Transaktionsprotokoll

Transaktion: Eine Transaktion ist eine Sammlung einer Reihe von Operationen, die festgeschrieben werden müssen. Erst nach der Übermittlung kann diese Reihe von Operationen als Transaktion bezeichnet werden. (Entweder werden alle Operationen ausgeführt oder keine davon)

Transaktionsprotokolle (InnoDB-spezifische Protokolle) können dazu beitragen, die Transaktionseffizienz zu verbessern. Bei Transaktionsprotokollen muss die Speicher-Engine beim Ändern der Daten in der Tabelle lediglich ihre Speicherkopie ändern und dann das Änderungsverhalten im auf der Festplatte gespeicherten Transaktionsprotokoll aufzeichnen, ohne die geänderten Daten selbst jedes Mal auf der Festplatte speichern zu müssen. Das Transaktionsprotokoll wird angehängt, sodass das Schreiben des Protokolls ein sequentieller E/A-Vorgang in einem kleinen Bereich auf der Festplatte ist. Im Gegensatz zum zufälligen E/A-Vorgang, bei dem der Kopf an mehrere Stellen auf der Festplatte bewegt werden muss, ist das Transaktionsprotokoll relativ schneller. Nachdem das Transaktionsprotokoll persistent gespeichert wurde, können die geänderten Daten im Speicher im Hintergrund langsam wieder auf die Festplatte geschrieben werden. Die meisten Speicher-Engines implementieren dies derzeit. Wir nennen es normalerweise Write-Ahead-Logging. Das Ändern von Daten erfordert zweimaliges Schreiben auf die Festplatte.

MySQL-Transaktionsbasierte Vorgänge ändern die Daten direkt im entsprechenden Speicher. Nach der Änderung können Sie überprüfen, ob sie wirksam geworden ist, aber sie wird nicht auf die Festplatte geschrieben. Sie wird zuerst in das Transaktionsprotokoll geschrieben und dann regelmäßig auf die Festplatte geleert (das Transaktionsprotokoll wird nacheinander angehängt auf die Festplatte geschrieben, was die Effizienz der Transaktion erheblich verbessert).

Wenn die Datenänderung im Transaktionsprotokoll aufgezeichnet und beibehalten wurde, die Daten selbst jedoch nicht auf die Festplatte zurückgeschrieben wurden und das System abstürzt, kann die Speicher-Engine die geänderten Daten beim Neustart automatisch wiederherstellen. Die verfügbaren Wiederherstellungsmethoden hängen von der Speicher-Engine ab.

Die InnoDB-Engine ist eine Engine, die Transaktionen unterstützt

Definition des Transaktionsprotokolls anzeigen

globale Variablen wie „%log%“ anzeigen;

MySQL-Binärprotokoll

Das Binärprotokoll wird auch Änderungsprotokoll genannt. Es wird hauptsächlich verwendet, um MySQL-Anweisungen aufzuzeichnen, die Daten ändern oder Datenänderungen verursachen können. Es zeichnet auch die Anweisungsauftrittszeit, die Ausführungszeit, Betriebsdaten usw. auf. Über das Binärlog kann daher abgefragt werden, welche Änderungen in der MySQL-Datenbank vorgenommen wurden. Die maximale Größe beträgt normalerweise 1 GB.

globale Variablen wie „%log%“ anzeigen;

sql_log_bin = {ON|OFF} #Wird verwendet, um die Sitzungsebene zu steuern (die Verbindung zu MySQL zum Ausführen einer Operationsanweisung ist die Sitzungsebene, beispielsweise wird das direkte Importieren einer Datei in MySQL nicht als Sitzungsebene betrachtet), wobei die Binärprotokollierungsfunktion ein- oder ausgeschaltet wird. Die Standardeinstellung ist „EIN“, was bedeutet, dass die Protokollierungsfunktion aktiviert ist. Der Benutzer kann den Wert dieser Variable auf Sitzungsebene ändern, muss dazu aber über das SUPER-Privileg verfügen.

binlog_cache_size = 32768 #Standardwert 32768 Binlog Cache wird in einer Umgebung verwendet, in der die Aufzeichnungsfunktion für Binärprotokolle (Binlog) aktiviert ist. Es handelt sich um einen von MySQL entwickelten Speicherbereich zur Verbesserung der Aufzeichnungseffizienz von Binlog und wird zum vorübergehenden Zwischenspeichern von Binlog-Daten für einen kurzen Zeitraum verwendet. Generell gilt: Wenn unsere Datenbank keine großen Transaktionen enthält und die Schreibvorgänge nicht besonders häufig sind, sind 2 bis 4 MB eine geeignete Wahl. Wenn unsere Datenbank jedoch viele große Transaktionen und eine große Anzahl von Schreibvorgängen aufweist, können wir binlog_cache_size entsprechend erhöhen. Gleichzeitig können wir mit binlog_cache_use und binlog_cache_disk_use analysieren, ob die eingestellte binlog_cache_size ausreichend ist und ob aufgrund unzureichender Speichergröße eine große Menge an binlog_cache temporäre Dateien (binlog_cache_disk_use) zum Zwischenspeichern verwendet.

log_bin = mysql-bin #Geben Sie den Speicherort von Binlog an, der sich standardmäßig im Datenverzeichnis befindet.

binlog-format= {ROW|STATEMENT|MIXED} #Geben Sie den Binärprotokolltyp an, MIXED wird empfohlen. Wenn das Binärprotokollformat festgelegt, das Binärprotokoll jedoch nicht aktiviert ist, werden beim Start von MySQL Warnprotokollinformationen generiert und im Fehlerprotokoll aufgezeichnet.

Zeile: zeichnet nicht den Kontext jeder SQL-Anweisung auf, sondern zeichnet nur auf, dass die einzelnen Daten geändert wurden

Anweisung: Jede SQL-Anweisung, die Daten ändert, wird aufgezeichnet

Gemischt: bezeichnet eine Mischung der ersten beiden

sync_binlog = 10 #Legen Sie fest, wie oft das Binärprotokoll mit der Datenträgerdatei synchronisiert werden soll. 0 bedeutet keine Synchronisierung, und jeder positive Wert bedeutet eine Synchronisierung nach jeder bestimmten Anzahl von Schreibvorgängen in der Binärdatei. Wenn der Wert von Autocommit 1 ist, führt die Ausführung jeder Anweisung zu einer Synchronisierung des Binärprotokolls. Andernfalls führt die Übermittlung jeder Transaktion zu einer Synchronisierung des Binärprotokolls.

Die binäre Protokollierung kann durch Bearbeiten der Option „log-bin“ in my.cnf aktiviert werden. Das Format ist wie folgt:

Der Parameter DIR gibt den Speicherpfad der Binärdatei an; der Parameter Dateiname gibt den Dateinamen der Binärdatei im Format Dateiname.Nummer an, wobei die Nummer das Format 000001, 000002 usw. hat. Bei jedem Neustart des MySQL-Dienstes oder Ausführen von „mysql> flush logs;“ wird eine neue Binärprotokolldatei generiert und die Anzahl dieser Protokolldateien steigt weiter an. Zusätzlich zur Generierung der oben genannten Dateien wird auch eine Datei mit dem Namen Dateiname.index generiert. In dieser Datei wird eine Liste aller Binärprotokolldateien gespeichert, die auch als Binärdateiindex bezeichnet wird.

Bei jedem Neustart des Datenbankdienstes wird eine binäre Protokolldatei generiert

Sehen Sie sich das Binärprotokoll an:

Das Binärprotokoll wird im Binärformat definiert. Durch die Verwendung dieses Formats können mehr Informationen gespeichert und das Schreiben in das Binärprotokoll effizienter gestaltet werden. Sie können den Befehl „Anzeigen“ jedoch nicht direkt verwenden, um das Binärprotokoll zu öffnen und anzuzeigen.

Kleine Erweiterung: Die Aufzeichnungsposition des Binärprotokolls ist normalerweise die Position der Endzeit der vorherigen Ereignisausführung. Jede Protokolldatei selbst hat ihre eigenen Metadaten. Für die aktuelle Version von MySQL beträgt die Startposition der Binärdatei daher normalerweise 107.

Stellen Sie eine Verbindung zu MySQL her und geben Sie mehrere SQL-Anweisungen ein, die Daten ändern können, um Binärprotokolle zu generieren

Zeigen Sie die angegebenen Binärprotokollinformationen an

Zeigen Sie das Binärprotokoll in der Befehlszeile an:

Da Sie cat oder andere Methoden nicht verwenden können, um das Binärprotokoll direkt zu öffnen und anzuzeigen, müssen Sie den Befehl mysqlbinlog verwenden. Es wird jedoch empfohlen, dies nicht zum Öffnen der verwendeten Binärprotokolldatei zu verwenden, wenn MySQL-Lese- und -Schreibvorgänge ausgeführt werden. Wenn Sie sie öffnen müssen, können Sie „flushlogs“ verwenden. So verwenden Sie den Befehl mysqlbinlog:

Exportieren Sie die Informationen dieser Datenbank:

[root@stu18 data]#mysqlbinlog mysql-bin.000017 > /tmp/a.sql

In diese Datenbank zu importierende Informationen:

[root@stu18 Daten]#mysql < a.sql

Binäre Protokollinformationen löschen:

Das Binärprotokoll zeichnet eine große Menge an Informationen auf (einschließlich einiger nutzloser Informationen). Wenn das Binärprotokoll längere Zeit nicht bereinigt wird, wird viel Speicherplatz verschwendet. Das Löschen kann jedoch dazu führen, dass die Datenbank abstürzt und nicht wiederhergestellt werden kann. Wenn Sie also das Binärprotokoll löschen möchten, müssen Sie es zuerst mit der Datenbank sichern. Sie können das Binärprotokoll nur vor der Sicherung löschen und die neu generierten Protokollinformationen können nicht gelöscht werden (Sie können eine Point-in-Time-Wiederherstellung durchführen). Ein direktes Löschen nach dem Herunterfahren des MySQL-Servers ist nicht möglich, da es sonst zu Fehlern in der Datenbank kommen kann. Wenn Sie das Binärprotokoll löschen müssen, müssen Sie Folgendes tun: Exportieren Sie die Sicherungsdatenbank und die Binärprotokolldateien für die komprimierte Archivspeicherung. So löschen Sie die Binärdatei:

Verwenden Sie die Anweisung RESET MASTER, um alle Binärprotokolle zu löschen. Die Anweisung hat folgende Form:

mysql> Master zurücksetzen;

Abfrage OK, 0 Zeilen betroffen (0,17 Sek.)

mysql> Binärprotokolle anzeigen;

Mysql-Sicherungstool

mysqldump: logisches Sicherungstool, anwendbar auf alle Speicher-Engines, kann für Warm-Backups verwendet werden, kann Voll-Backups und Teil-Backups durchführen; für InnoDB-Speicher-Engines

Unterstützt Hot-Standby;

Dateisystem-Tools wie cp und tar: physische Backup-Tools, anwendbar auf alle Speicher-Engines; werden für Cold-Backups verwendet, ermöglichen Voll- und Teil-Backups;

lvm2-Snapshot: nahezu Hot Backup; physisches Backup wird mit Hilfe von Dateisystemtools erreicht;

mysqlhotcopy: Fast kaltes Backup; gilt nur für die MyISAM-Speicher-Engine;

Mysql-Backup-Lösung ①mysqldump+binlog: (empfohlen)

Vollständige Sicherung, inkrementelle Sicherung durch Sicherung von Binärprotokollen

② zusätzliche Sicherung:

Für InnoDB: Hot-Standby, Unterstützung für Voll-Backup und inkrementelles Backup

Für MyISAM: Warm Backup, nur Voll-Backup wird unterstützt

③lvm2-Schnappschuss + Binärprotokoll:

Nahezu Hot-Standby, physisches Backup

Das Syntaxformat des Befehls mysqldump+binlog

mysqldump [OPTIONEN] Datenbank [Tabellen]: Sichern Sie eine einzelne Datenbank oder eine oder mehrere von der Datenbank angegebene Tabellen.

mysqldump [OPTIONEN] --databases [OPTIONEN] DB1 [DB2DB3...]: Sichern Sie eine oder mehrere Datenbanken

mysqldump [OPTIONEN] --all-databases [OPTIONEN]: Alle Datenbanken sichern

Andere Optionen

-x, --lock-all-tables: alle Tabellen sperren

-l, --lock-tables: Sperren Sie die Sicherungstabellen.

--single-transaction: Starten Sie eine große Einzeltransaktion, um die Sicherung durchzuführen

-C, --compress: Übertragung komprimieren

-E, --events: Sichern Sie den Ereignisplaner der angegebenen Bibliothek

-R, --routines: Gespeicherte Prozeduren und gespeicherte Funktionen sichern

--triggers: Sicherungsauslöser

--master-data={0|1|2}

0: Nicht aufzeichnen

1: Protokollieren Sie die Anweisung CHANGE MASTER TO. Diese Anweisung ist nicht kommentiert.

2: Als Kommentaranweisung aufzeichnen

-F, --flush-logs: Führt den Befehl zum Leeren der Protokolle aus, nachdem die Tabelle gesperrt wurde.

mysqldump+binlog Backup und Wiederherstellung 1. Ändern Sie die MySQL-Konfigurationsdatei und aktivieren Sie das Binärprotokoll

vim /etc/meine.cnf

log-bin = Master-Protokoll

Starten Sie dann MySQL neu

systemctl Neustart MariaDB

Geben Sie mysql ein, um zu prüfen, ob ein Binärprotokoll generiert wird

2. Bereiten Sie das Sicherungsverzeichnis vor

3. Bereiten Sie die Sicherung der Datenbank und der Tabellen vor

MySQL

Datenbanktest erstellen;

benutze Magedu;

Tabelle erstellen m(id int,name char(20));

4. Erstellen Sie ein vollständiges Backup

mysqldump --all-databases --lock-all-tables --flush-log --master-data=2 > /backup/`date +%F_%T`-all.sql

5. Daten in die Tabelle einfügen

MySQL

benutze Magedu;

Masterstatus anzeigen;

in m26 einfügen (ID, Name) Werte (1, „rauchend“), (2, „zhangmeng“);

6. Führen Sie eine inkrementelle Sicherung durch und sichern Sie Binärprotokolle

mysqlbinlog --start-position=245 --stop-position=479 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

Bestimmen Sie den Start und Stopp der Position

Master-Protokolle anzeigen;

Binlog-Ereignisse in „master-log.000002“ anzeigen;

Das Ende muss „Commit“ enthalten.

7. Fügen Sie weiterhin Daten ein, löschen Sie die Datenbank ohne Sicherung und simulieren Sie Fehlbedienungen

8. Datenwiederherstellung. Da wir die Datenbank ohne Backup gelöscht haben, müssen wir zunächst das letzte Binärprotokoll sichern. Wenn diese Binärprotokolle verloren gehen, können sie nicht wiederhergestellt werden. Überprüfen Sie vor dem Löschvorgang den Positionswert mysqlbinlog /var/lib/mysql/master-log.000002

9. Sichern Sie das Binärprotokoll der letzten Operation

mysqlbinlog --start-position=467 --stop-position=677 /var/lib/mysql/master-log.000002 > /backup/binlog/binlog-`date +%F_%T`.sql

ls /backup/binlog/

10. Importieren Sie alle vorherigen Backups

mysql < /backup/2017-12-07_20\:20\:04-all.sql Vollständiges Backup importieren

mysql < /backup/binlog/binlog-2017-12-07_20\:45\:17.sql inkrementelles Backup importieren

mysql < /backup/binlog/binlog-2017-12-07_21\:05\:42.sql importiert das inkrementelle Backup vor dem Löschen der Datenbank

11. Datenbank und Daten anzeigen

Abonnieren

Xtrabackup ist ein von Percona bereitgestelltes MySQL-Datenbank-Backup-Tool. Laut der offiziellen Einführung ist es ein Open-Source-Tool, das Hot-Backups von InnoDB- und XtraDB-Datenbanken durchführen kann.

Merkmale:

(1) Der Backup-Prozess ist schnell und zuverlässig

(2) Der Backup-Prozess unterbricht laufende Transaktionen nicht

(3) Möglichkeit, Speicherplatz und Datenverkehr durch Komprimierung und andere Funktionen zu sparen

(4) Automatische Backup-Verifizierung

(5) Schnelle Wiederherstellungsgeschwindigkeit

Experimentelle Schritte: (1) Installation von xtrabackup

yum installiere percona-xtrabackup -y

(2) Vollsicherung

innobackupex --user=root /backup

(3) Daten hinzufügen

mysql -uroot

Datenbank Magedu erstellen;

benutze Magedu

Tabelle m26 erstellen (ID int, Name char(20));

in m26-Werte einfügen (007, 'rauchend'), (008, 'zhangmeng')

(4) Inkrementelle Sicherung

innobackupex --incremental /backup/ --incremental-basedir=/backup/2017-11-16_16-53-4

(5) Vorbereitung der Datenwiederherstellung
1. Führen Sie den Vorgang durch (vollständiges Backup):

innobackupex --apply-log --redo-only BASE-DIR (BASE-DIR ist das Verzeichnis des Voll-Backups)

Beispiel: innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=/backup/2017-11-16_17-17-52/

2. Führen Sie dann (inkrementell) aus:

innobackupex --apply-log --redo-only BASE-DIR --incrementaldir=INCREMENTAL-DIR-1 (INCREMENTAL-DIR-1 ist das inkrementelle Sicherungsverzeichnis)

Beispiel: innobackupex --apply-log --redo-only /backup/2017-11-16_16-53-43 --incrementaldir=/backup/2017-11-16_17-17-52/

(6) Recovery-Phase: Wiederherstellung der Daten

mv /var/lib/mysql /var/lib/mysql.bak simuliert das Löschen der Datenbank

mkdir /var/lib/mysql

cd /var/lib/mysql

innobackupex --copy-back /backup/2017-11-16_16-53-43 Vollständiges Backup wiederherstellen

lvm2-Schnappschuss + Binärprotokoll

Bevor wir das Experiment durchführen, überprüfen wir das Wissen über lvm2-snapshot

Vereinfacht ausgedrückt speichert ein LVM-Snapshot die Metadaten aller Dateien in der Snapshot-Quellpartition zu einem bestimmten Zeitpunkt. Wenn sich die Quelldatei nicht geändert hat, verweist die entsprechende Datei, die auf das Snapshot-Volume zugreift, direkt auf die Quelldatei der Quellpartition. Wenn sich die Quelldatei geändert hat, ändert sich die entsprechende Datei im Snapshot-Volume nicht. Snapshot-Volumes werden hauptsächlich zum Sichern von Dateien verwendet.

Experimentelle Schritte:

1. Fügen Sie eine Festplatte hinzu und unterteilen Sie den Festplattentyp in den LVM-Typ

echo '- - -' > /sys/klasse/scsi_host/host2/scan

2. Partition

t 8e ist lvm

partx -a /dev/sdb sorgt dafür, dass der Kernel die neue Festplatte erkennt

3.pvcreate /dev/sdb1, um ein physisches Volume hinzuzufügen

4.vgcreate myvg /dev/sdb1, um eine Volume-Gruppe hinzuzufügen

5.lvcreate -n mydata -L 5G myvg zum Hinzufügen eines logischen Volumes

6. mkfs.ext4 /dev/mapper/myvg-mydata formatiert das logische Volume

7. Mounten Sie /dev/mapper/myvg-mydata /lvm_data und verwenden Sie es

8. Ändern Sie die Mysql-Konfiguration so, dass sich die Datendatei auf dem logischen Volume datadir=/lvm_data befindet

9. service mysqld restart startet den MySQL-Dienst

10. Erstellen Sie eine Datenbank und führen Sie Vorgänge durch

11.mysql> FLUSH TABLES WITH READ LOCK; #Tabelle sperren

12. lvcreate -L 1G -n meineDaten-snap -pr -s /dev/mapper/myvgmydata

#Snapshot-Volume erstellen. Logisches Volume „mydata-snap“ erstellt.

13.mysql> UNLOCK TABLES; #Alle Tabellen entsperren

14. mount /dev/myvg/mydata-snap /lvm_snap/ #Snap einhängen

15. tar cvf /tmp/mysqlback.tar ./* #Paket physisches Backup

16. umount /lvm_snap/ #Snap deinstallieren

17. lvremove myvg mydata-snap #Snap löschen

18. MySQL-Daten löschen rm -rf /lvm_data/*

19. Entpacken und Wiederherstellen gelöschter Daten tar xvf /tmp/mysqlback.tar ./

20. Überprüfen Sie, ob die Datenbankdaten korrekt wiederhergestellt wurden

Zusammenfassen

Okay, das war’s für heute. Bis zum nächsten Mal.

Das obige praktische Tutorial zur Implementierung von Protokollverwaltung, Sicherung und Wiederherstellung auf Unternehmensebene mit Mysql ist alles, was ich mit Ihnen teilen möchte. Ich hoffe, es kann Ihnen als Referenz dienen, und ich hoffe auch, dass Sie 123WORDPRESS.COM unterstützen werden.