OBS/Admihilfe/MySQLShell: Unterschied zwischen den Versionen
KKeine Bearbeitungszusammenfassung |
|||
| Zeile 67: | Zeile 67: | ||
=Bekannte Fehler= | =Bekannte Fehler= | ||
==The local_infile' global system variable must be set to ON== | ==The local_infile' global system variable must be set to ON== | ||
[[Datei:MySQLShellError Infile.png]] | |||
=== Lösung: === | |||
Die globale Variable local_infile auf ON setzen: <syntaxhighlight lang="mysql"> | |||
SET GLOBAL local_infile = 'ON' | |||
</syntaxhighlight> | |||
== Dump wurde mit abweichender Version erstellt == | |||
[[Datei:MySQLShellError AbweichendeVersion.png]] | |||
=== Lösung: === | |||
den Parameter <code>ignoreVersion:"true"</code> hinzufügen. | |||
Es kann hier natürlich zu diversen Problemen kommen. Laut MySQL Handbuch soll auf dem alten Server zunächst gepfürft werden, ob es zu Problemen kommen kann: | |||
<code>util.checkForServerUpgrade('user@example.com:3306', {"password":"password", "targetVersion":"8.0.27", "configPath":"C:\ProgramData\MySQL\MySQL Server 8.0\my.ini"})</code> | |||
Wenn alles gut läuft, sieht dies so aus: | |||
[[Datei:MySQLShellError AbweichendeVersionLoesung.png]] | |||
Version vom 8. November 2023, 11:25 Uhr
<accesscontrol>Programmierer</accesscontrol>
- System Überwachung
- DEP deaktivieren
- Darstellung unter Windows 7
- Einwahl auf Windows 2000 Server
- Preislisten
- Datenbank Sicherung
- Customize
- Zentrale
- MySQL Korrekturen
- Support Macro
- Service Debug
- Historienprotokoll (Datenänderung OBS)
- Fernwartungsprobleme
- Startparameter
- Fehler beim Kassenabschluss
- Diverse Informationen
- A ras.pbk
- B Command Line Interpreter
- C File Zilla Benutzer XML erzeugen
- D1 OBS_UPDATE.EXE zum OBS Update Server hochladen
- D2 SUPPORT_MACRO zum OBS Update Server hochladen
- H1 Remote Service Protokoll-Übersicht (Alles)
- H Remote ServiceProtokoll-Übersicht
- I Remote Service Commands
- I1 (Admin) Globaler Hinweis für Updates
- J Liste der OBS Updates
- K Angemeldete Service Firmen
- L Systeminformationen einlesen
- M Kundendaten anzeigen
- M1 Kundendatenbankinformationen anzeigen
- N Kundendaten einlesen
- O Kunden-Update Informationen anzeigen
- P Modul Registrierung OBS
- Q App Verwaltung
- S1 Firmen Statistik Protokolle OBS
- S2 Statistik Notfallkassen
Was ist die MySQL Shell?
Die MySQL Shell ist ein CMD Tool, was in Zukunft auch das MySQLDump ersetzten wird.
Die Shell muss über den MySQL Installer extra installiert werden.
Wofür ist die MySQL Shell gut?
Die MySQL Shell ist sehr vielseitig, momentan wird sie aber nur für den Im- und Export von Datenbanken benutzt.
Datenexport mit der MySQL Shell
Für den Export werden im Grunde nur 2 Befehle benötigt, nachdem man die Shell gestartet hat:
- \connect root@"Servername" und danach das Passwort eingeben
- util.dumpSchemas(["Datenbankname"],"Zielpfad mit "/"", {showProgress: "true",threads:12, consistent:"false"})
Die Parameter bedeuten folgendes:
showProgress → lässt den Fortschritt im Fenster mitlaufen
threads → Anzahl der Threads die die Shell intern zum Dumpen nutzt
consistent → entpsricht dem Parameter "SingleTransaction" beim alten Dump. Sollte auf false stehen, wenn im laufenden Betrieb genutzt
Beispiel:
util.dumpSchemas(["obs_mysql"],"c:/Backup/DBDump", {showProgress: "true",threads:12, consistent:"false"})
Dump-Export, wenn der Name der Datenbank nachträglich geändert werden soll
Falls der Name des Dumps beim Import geändert werden soll, muss das Dump mit util.dumpTables statt mit util.dumpSchemas erzeugt werden. Hierbei werden die Tabellen einzeln gedumpt. Mit dem Parameter all kann man alle Tabellen eines Schemas dumpen. Beispiel:
util.dumpTables("obs_mysql", [], "c:/Backup/DBDumpTables", { "all": true })
Sichern einer kompletten Datenbankinstallation
Wenn die gesamte Datenbankinstallation gesichert werden soll, geht das mit dem Befehl util.dumpInstance. Beispiel:
util.dumpInstance("Zielpfad mit "/"", {showProgress: "true",threads:12, consistent:"false"})
Datenimport mit der MySQL Shell
Zuvor muss in der Datenbank die Variable "local_infile" aktiv sein. Sonst kann der Dump nicht eingelesen werden.
Um die Daten wieder zu importieren, müsst ihr diese Befehle nutzen:
- \connect root@"Servername" und danach das Passwort eingeben
- util.loadDump("Zielpfad mit "/"",,{progressFile :"Zielpfad mit "/""+backuplog.json",threads:12,backgroundThreads:12})
So wird die Daten unter dem Datenbanknamen eingespielt, wie Sie auch exportiert wurden.
Der "progressfile" Paramater legt eine Datei an, mit der das Dump den letzten Datensatz kennt, falls es abbricht. Somit wird an der Stelle wieder begonnen.
Beispiel:
util.loadDump("c:/Backup/DBDump",{progressFile :"c:/Backup/DBDump/backuplog.json", threads:12, backgroundThreads:12})
Import mit abweichendem Datenbank-Namen (vom Dump)
Falls ein Dump unter einem anderen Namen importiert werden soll kann hierfür der Parameter schema verwendet werden. Das entsprechende schema muss jedoch zunächst angelegt werden. Das Anlegen des Schemas kann über \sql erfolgen. Hierüber können direkte SQL Befehle eingegeben werden. Beispiel:
\sql CREATE DATABASE IF NOT EXISTS obs_mysql_backup;
Beispiel des Imports mit schema-Parameter:
util.loadDump("c:/Backup/DBDumpTables",{progressFile :"c:/Backup/DBDumpTables/backuplog.json", schema:"obs_mysql_backup",threads:12,backgroundThreads:12})
Bekannte Fehler
The local_infile' global system variable must be set to ON
Lösung:
Die globale Variable local_infile auf ON setzen:
SET GLOBAL local_infile = 'ON'
Dump wurde mit abweichender Version erstellt
Lösung:
den Parameter ignoreVersion:"true" hinzufügen.
Es kann hier natürlich zu diversen Problemen kommen. Laut MySQL Handbuch soll auf dem alten Server zunächst gepfürft werden, ob es zu Problemen kommen kann:
util.checkForServerUpgrade('user@example.com:3306', {"password":"password", "targetVersion":"8.0.27", "configPath":"C:\ProgramData\MySQL\MySQL Server 8.0\my.ini"})
Wenn alles gut läuft, sieht dies so aus:
