Diese Seite beschreibt Calíope 1.5, die Version, die wir gerade bauen. Die 1.4 ist fertig und in der App-Review, und der Store liefert heute 1.3 auf dem Mac und 1.2 auf dem iPad. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Was in Calíope schiefgegangen ist, wann und auf welchem Gerät.
Wo es zu finden ist: Workspace › Werkzeuge › Fehler
Das Fehlerprotokoll speichert eine Zeile pro Anwendungsfehler, mit Zeitstempel in Weltzeit, dem Gerät, auf dem er auftrat, dem betroffenen Bereich und dem beteiligten Verbindungsprofil, sofern vorhanden.
Es ist nicht das Abfrageprotokoll. Jenes speichert, was der Server auf eine Anweisung antwortet — etwa einen Syntax-ERROR 1064 —, was das normale Ergebnis des SQL-Schreibens ist. Dieses speichert, was der App passiert: eine Verbindung, die nicht zustande kommt, ein Tunnel, der abbricht, eine Sicherung, die sich nicht schreiben lässt.
Es funktioniert ohne Verbindung, und das ist Absicht: Das Protokoll ist lokal, und man muss es genau dann lesen können, wenn keine Verbindung möglich ist — dann ist es am wichtigsten.
Was nie gespeichert wird: kein Passwort, auch nicht gekürzt. Ein Authentifizierungsfehler hält fest, dass er auftrat und gegen welches Profil, nie mit welchen Anmeldedaten. Der Server wird über den Profil-Alias identifiziert, nicht über Host, Port und Benutzer.
Ein Fehler, der sich von selbst wiederholt, füllt das Protokoll nicht. Die Zustandsüberwachung fragt jeden Server alle paar Sekunden ab; ein ausgeschalteter Server würde über Nacht Tausende identischer Zeilen hinterlassen. Er wird beim ersten Mal festgehalten und erneut, wenn sich das Problem ändert, wenn der Server sich erholt und wieder ausfällt oder wenn es sechs Stunden später unverändert ist. Eine einzige Zeile bedeutet nicht, dass es nur einmal passiert ist.
Doppelklicken Sie eine Zeile (oder tippen Sie sie auf dem iPad an), um alle Details zu öffnen — mit dem technischen Text für den Support und einer Taste zum Kopieren. Hat der Fehler eine eigene Erklärung, finden Sie dort die Taste Lösung anzeigen.
Stichwörter: Fehler, Protokoll, Diagnose, Ausfälle, Support
Wie die Synchronisierung funktioniert und was das Gerät verlässt.
Wo es zu finden ist: Calíope › Einstellungen › Allgemein
Das Protokoll lässt sich in Ihre private iCloud spiegeln, sodass ein Fehler vom iPad auch auf dem Mac erscheint. Jede Zeile behält das Gerät, auf dem sie entstand: Ein zusammengeführtes Protokoll, bei dem man nicht weiß, wer welche Zeile schrieb, taugt nicht zur Diagnose.
Der Schalter ist anfangs aus, und das ist kein Versehen. Ein lokales Protokoll ist Ihre Datei auf Ihrem Rechner; es hochzuladen bringt die Aliasnamen Ihrer Profile und das technische Detail jedes Fehlers vom Gerät weg. Danach wird gefragt, das wird nicht vorausgesetzt. Er liegt unter Einstellungen › Allgemein, getrennt vom Schalter für die Aufzeichnung: Der eine entscheidet, ob gespeichert wird, der andere, ob es das Gerät verlässt.
Warum es nicht mit den übrigen Einstellungen reist. Einstellungen laufen über einen kleinen iCloud-Speicher mit einem Megabyte Obergrenze für alles zusammen; ist er voll, hört alles auf zu synchronisieren, nicht nur das, was ihn gefüllt hat. Ein Fehlerprotokoll wächst mit der Nutzung, es nimmt daher einen anderen Kanal — CloudKit, Datensatz für Datensatz —, wodurch Mac, iPad und iPhone zugleich schreiben können, ohne einander zu überschreiben.
Aufbewahrung. Standardmäßig 90 Tage, in den Einstellungen änderbar. Das Kürzen betrifft die lokale Datei und iCloud; das Leeren des Protokolls lässt also keine Kopie oben, die bei der nächsten Synchronisierung zurückkäme.
Der Server hat nicht geantwortet: was zu prüfen ist, und in welcher Reihenfolge.
Gilt für:MySQLMariaDBAurora
Dieser Fehler bedeutet, dass der Verbindungsversuch nie mit einem Server gesprochen hat: Entweder lauscht auf diesem Host und Port nichts, oder etwas unterwegs blockiert es.
Der Reihe nach, vom Wahrscheinlichsten zum Unwahrscheinlichsten:
1. Host und Port des Profils. Der Standardport ist 3306; ein Server im Container veröffentlicht meist einen anderen.
2. Der Server läuft. Prüfen Sie es auf der Maschine, auf der er läuft, sofern Sie Zugriff haben.
3. Der SSH-Tunnel, falls Sie einen nutzen. Ein Tunnelfehler zeigt sich sehr oft als „keine Verbindung“: Suchen Sie im Protokoll direkt davor nach einem SSH-Fehler.
4. Eine Firewall oder das Netz. Ein abgebrochenes VPN, ein Firmennetz, das 3306 filtert, oder eine Security-Group-Regel in der Cloud erzeugen denselben Fehler.
5. Auf welcher Schnittstelle der Server lauscht. Ein Server, der nur auf 127.0.0.1 lauscht, ist von einer anderen Maschine aus unerreichbar, auch wenn er läuft; die Antwort ist dann ein SSH-Tunnel, nicht das Öffnen des Ports.
Die Verbindung kam an, doch die Anmeldedaten gelten von hier aus nicht.
Gilt für:MySQLMariaDBAurora
Dieser Fehler ist halb gute Nachricht: Das Netz funktioniert und der Server lebt. Was scheitert, ist die Identität.
Drei Ursachen, unterschiedlich zu beheben:
- Passwort oder Benutzername entsprechen nicht dem, was der Server erwartet. Prüfen Sie sie in der Verbindungsverwaltung. Achten Sie beim Einfügen eines Passworts auf Leerzeichen am Anfang oder Ende.
- Das Konto existiert, aber nicht von diesem Rechner aus. In MySQL und MariaDB ist ein Konto das Paar Benutzer + Herkunftshost: dba@localhost und dba@% sind verschiedene Konten mit verschiedenen Passwörtern. Über einen SSH-Tunnel sieht der Server Sie von localhost kommen; ohne Tunnel von Ihrer IP. Das ist die häufigste Ursache für „an einem Ort geht es, am anderen nicht“.
- Das Konto hat keine Rechte an genau dieser Datenbank. Nennt die Meldung eine Datenbank, kam der Benutzer herein, darf sie aber nicht nutzen; ein GRANT darauf fehlt.
Die Benutzerverwaltung zeigt für jedes Konto, von welchen Hosts es sich verbinden darf und welche Rechte es hat.
Sie wurde gelöscht, umbenannt, oder Ihr Konto darf sie nicht sehen.
Gilt für:MySQLMariaDBAurora
Calíope merkt sich die zuletzt genutzte Datenbank je Profil; dieser Fehler taucht daher meist beim erneuten Verbinden mit einem veränderten Server auf.
Worauf zu achten ist:
- Groß- und Kleinschreibung. Unter Linux unterscheiden Datenbanknamen standardmäßig die Schreibweise, unter macOS und Windows nicht. Eine auf einem Laptop erstellte und auf einem Linux-Server gesuchte Datenbank kann allein deshalb verschwinden.
- Rechte. Ein Konto ohne Rechte an einer Datenbank sieht sie nicht in der Liste, deshalb sehen „existiert nicht“ und „Sie dürfen sie nicht sehen“ von hier aus sehr ähnlich aus. Sieht ein anderer Benutzer sie, ist es das.
- Der falsche Server. Bei mehreren ähnlichen Profilen schaut man leicht auf die Produktion und glaubt, es sei die Testumgebung.
Aktualisieren Sie den Schemabaum, um die Liste zu sehen, die der Server gerade tatsächlich liefert.
Sie brach mitten im Vorgang ab: warum, und was halb fertig bleibt.
Gilt für:MySQLMariaDBAurora
Die Verbindung stand und brach dann ab. Wichtig ist nicht das Neuverbinden — das ist einfach —, sondern zu wissen, was halb erledigt blieb.
Lief eine Schreibanweisung ohne explizite Transaktion, kann sie ganz, teilweise oder gar nicht angewendet worden sein, je nachdem, wo abgeschnitten wurde. Das Abfrageprotokoll nennt die zuletzt abgesetzte; prüfen Sie sie auf dem Server, bevor Sie sie wiederholen.
Übliche Ursachen:
- Zeitlimit des Servers. Eine Verbindung, die länger als wait_timeout untätig ist (standardmäßig 8 Stunden, oft auf Minuten gesenkt), schließt sich selbst. Es zeigt sich als „genau als ich zurückkam, war sie weg“.
- Eine Abfrage, die länger dauert als erlaubt. Dann läuft net_read_timeout ab oder ein Limit eines dazwischenliegenden Proxys.
- Ein zu großes Paket. Ein INSERT über max_allowed_packet schließt die Verbindung, statt einen lesbaren Fehler zu liefern.
- Das Netz. WLAN-Wechsel, Ruhezustand oder ein sich neu verbindendes VPN trennen die Verbindung ohne Vorwarnung.
Stichwörter: Verbindung verloren, Zeitlimit, wait_timeout, Netz, 2006, 2013
SSH-Authentifizierung fehlgeschlagen: Schlüssel, Passwort und der Zweitgerät-Fall.
Der Tunnel hat den SSH-Server erreicht, konnte sich aber nicht ausweisen. Die Datenbank wurde noch gar nicht versucht.
Der verwirrendste Fall: Sie haben gerade Ihr zweites Gerät eingerichtet. Profile synchronisieren über iCloud, die Berechtigung zum Lesen Ihrer privaten Schlüsseldatei jedoch nicht — und das ist kein Versehen: Diese Berechtigung verweist auf das Dateisystem eines Rechners und bedeutet auf einem anderen nichts. Auf dem neuen Gerät müssen Sie die Schlüsseldatei im Profil erneut auswählen. Das ist die häufigste Ursache für „dasselbe Profil geht auf dem Mac und nicht auf dem iPad“.
Alles Weitere, der Reihe nach:
- Der SSH-Benutzer ist nicht der Datenbankbenutzer. Das sind zwei getrennte Identitäten, oft mit verschiedenen Namen.
- Der öffentliche Schlüssel liegt nicht auf dem Server. Er muss in der ~/.ssh/authorized_keys dieses Benutzers auf dieser Maschine stehen.
- Dateirechte auf dem Server. Eine für andere lesbare authorized_keys ignoriert der Server stillschweigend, ohne den Grund zu nennen.
- Die Passphrase des Schlüssels. Ist der Schlüssel geschützt, müssen Sie sie eingeben; ein geschützter Schlüssel ohne Passphrase verhält sich wie ein falscher Schlüssel.
Wann das normal ist, wann nicht, und wie man vor dem Akzeptieren prüft.
Beim ersten Verbinden mit einem SSH-Server speichert Calíope den Fingerabdruck seines Schlüssels. Legt der Server später einen anderen vor, hält Calíope an und warnt.
Diese Warnung ist keine Formalität. Ein Schlüsselwechsel sieht genauso aus wie ein Abhörversuch zwischen Ihrem Rechner und dem Server: Akzeptieren Sie den neuen Schlüssel, würden Sie Ihre Anmeldedaten unbemerkt weitergeben.
Wann der Wechsel legitim ist:
- Das Betriebssystem des Servers wurde neu installiert.
- Die virtuelle Maschine oder der Container wurde neu erstellt.
- Name oder IP wurden einer anderen Maschine zugewiesen (in der Cloud häufig).
Wie man richtig prüft: Erfragen Sie den Fingerabdruck bei der Administration der Maschine über einen anderen Kanal als die Verbindung selbst — eine Nachricht, einen Anruf — und vergleichen Sie ihn mit dem angezeigten. Stimmt er, akzeptieren Sie. Können Sie nicht prüfen, akzeptieren Sie nicht.
Unterstützte Formate und warum die Datei von selbst unlesbar wird.
Calíope bringt eine eigene SSH-Implementierung mit und nutzt nicht das ssh des Systems, unterstützt also einen bestimmten Satz Formate: ed25519- und ECDSA-Schlüssel im OpenSSH-Format.
Wenn die Datei existiert, aber nicht gelesen wird:
- Die Berechtigung ist womöglich abgelaufen. Calíope erreicht nur Dateien, die Sie selbst in einem Dialog auswählen, und diese Berechtigung wird als Referenz gespeichert, die manchmal ungültig wird: Verschieben Sie die Datei, benennen Sie den Ordner um oder stellen Sie den Rechner aus einer Sicherung wieder her, müssen Sie sie erneut auswählen.
- Es könnte ein alter RSA-Schlüssel sein. Wandeln Sie ihn in ed25519 um, der zudem schneller und kürzer ist.
- Vielleicht haben Sie den öffentlichen Schlüssel gewählt. Die richtige Datei endet nicht auf .pub.
- Er könnte passphrasengeschützt sein. Dann müssen Sie die Passphrase beim Verbinden eingeben; ohne sie lässt sich der Schlüssel nicht entschlüsseln, und das Ergebnis ist von einer unlesbaren Datei nicht zu unterscheiden.
Er bricht alle paar Minuten ab: fast immer schließt der Server untätige Sitzungen.
Der Tunnel war offen und dann nicht mehr. Das Profil neu zu verbinden hilft, aber wenn es oft passiert, gibt es eine konkrete Ursache, die sich beseitigen lässt.
Am häufigsten schließt der SSH-Server selbst untätige Sitzungen. Viele sshd-Konfigurationen haben ClientAliveInterval und ClientAliveCountMax so eingestellt, dass nach wenigen Minuten ohne Datenverkehr getrennt wird. Da eine Datenbanksitzung lange Lesephasen ohne Senden hat, bricht der Tunnel genau dann ab, wenn Sie zur App zurückkehren.
Weitere Ursachen:
- Der Rechner war im Ruhezustand. Beim Aufwachen sind die bestehenden Netzverbindungen ungültig.
- Ein Netzwechsel. Von WLAN auf Kabel oder zwischen WLANs zu wechseln, ändert die Quelladresse und trennt die Sitzung.
- Ein Limit gleichzeitiger Sitzungen auf dem Server, wenn mehrere Personen denselben SSH-Benutzer teilen.
Das Aktivitätsfenster zeigt den Tunnel als aktiven Modus, solange er lebt — so sehen Sie auf einen Blick, ob er noch offen ist.
Was Calíope von iCloud braucht und was ohne iCloud nicht mehr geht.
Calíope nutzt iCloud, um Ihre Profile, Ihre Einstellungen und — falls Sie es aktivieren — Ihre Protokolle von einem Gerät zum anderen zu bringen. Ohne aktives Konto bleibt all das lokal.
Was zu prüfen ist:
1. Dass Sie in den Systemeinstellungen bei iCloud angemeldet sind.
2. Dass iCloud Drive eingeschaltet ist, nicht nur das Konto.
3. Dass Calíope in der Liste der Apps steht, die iCloud Drive nutzen dürfen. Das übersieht man leicht: Das Konto kann in Ordnung und die App abgewählt sein.
Inzwischen geht nichts verloren. Alles bleibt auf diesem Gerät gespeichert; nur die Kopie auf das andere unterbleibt. Sobald iCloud zurück ist, holt die Synchronisierung von selbst auf.
Ein fehlgeschlagener Upload verliert keine Daten; was tun, wenn es sich wiederholt.
Zuerst: Es ist nichts verloren. Alles, was Calíope synchronisiert, hat seine Kopie auf diesem Gerät; der Upload ist eine zusätzliche Kopie. Ein Fehler hier heißt, dass das andere Gerät die Daten später sieht, nicht dass sie gelöscht wurden.
Passiert es einmal und kehrt nicht wieder, war es fast immer das Netz. Es wird von selbst erneut versucht.
Wiederholt es sich:
- Prüfen Sie den Speicher Ihres Kontos. Ein volles iCloud erzeugt diesen Fehler dauerhaft.
- Sehen Sie nach, ob zu viele Schreibvorgänge hintereinander laufen. Calíope bündelt Uploads gerade deshalb, um unter dem Frequenzlimit von iCloud zu bleiben; ein erster Upload eines sehr großen Protokolls kann jedoch mehrere Versuche brauchen.
- Schalten Sie die betroffene Synchronisierung aus und wieder ein. Beim Einschalten wird alles von Grund auf hochgeladen.
Machen Sie vorher eine Kopie. Die Einstellungen bieten einen vollständigen Konfigurationsexport; es gibt ihn, weil eine schlecht durchgeführte Sync-Aktivierung die Verbindungsdatei des Containers durch eine leere ersetzen kann. Das ist ein gemessener Vorfall, keine Vermutung.
Stichwörter: icloud, Synchronisierung, Fehler, erneut versuchen, Sicherung
Was in Calíope Platz belegt und was sich kürzen lässt, ohne Wichtiges zu verlieren.
Calíope speichert standardmäßig sehr wenig in iCloud: Ihre Verbindungsprofile und Einstellungen belegen wenige Kilobyte.
Mit der Nutzung wachsen die Protokolle, und nur wenn Sie sie einschalten: das Abfrage- und das Fehlerprotokoll. Beide haben in den Einstellungen eine einstellbare Aufbewahrung; sie zu senken ist der direkteste Weg, Platz zurückzugewinnen, ohne etwas zu verlieren, das Sie gerade ansahen.
Was zu kürzen ist, nach Wirkung:
1. Die Aufbewahrungstage des Abfrageprotokolls. Mit Abstand am größten: Es speichert den vollständigen Text jeder Anweisung.
2. Die Tage des Fehlerprotokolls.
3. Der Verlauf des KI-Assistenten, falls synchronisiert.
Das Leeren eines der drei aus seinem eigenen Werkzeug löscht auch die iCloud-Kopie, der Platz kommt also wirklich zurück und nicht bei der nächsten Synchronisierung wieder weg.
Ihre Arbeitsdaten sind davon nicht betroffen: Datenbanken liegen auf ihren Servern, und Calíope kopiert sie nie nach iCloud.
Wie Dateizugriff in einer App-Store-App funktioniert.
Calíope läuft in einer Sandbox — eine Vorgabe des App Store: Es kann eine Datei nicht über ihren Pfad öffnen, sondern nur die, die Sie ausdrücklich in einem Öffnen- oder Sichern-Dialog auswählen.
Das hat eine praktische Folge, die beim ersten Mal überrascht: den Pfad von Hand einzutippen genügt nicht. Auch wenn die Datei existiert und Ihnen gehört: Ist sie nicht durch einen Dialog gegangen, sieht die App sie nicht.
So wird die Berechtigung erteilt: Öffnen Sie die Datei oder den Ordner über Öffnen… oder Sichern unter…. Danach speichert Calíope die Berechtigung und kann sie ohne Nachfrage wiederverwenden.
Wann sie neu erteilt werden muss:
- Wenn Sie die Datei oder ihren Ordner verschieben oder umbenennen.
- Wenn Sie den Rechner aus einer Sicherung wiederherstellen.
- Wenn es ein anderes Gerät ist. Diese Berechtigungen synchronisieren bewusst nicht: Auf einem anderen Rechner bedeuten sie nichts.
Aus demselben Grund müssen ein privater SSH-Schlüssel oder ein Ordner für geplante Sicherungen auf jedem Gerät erneut ausgewählt werden.
Warum eine Datei, die funktionierte, plötzlich nicht mehr aufgeht.
Wenn Sie eine Datei in einem Dialog auswählen, speichert Calíope nicht ihren Pfad, sondern eine Zugriffsberechtigung — eine vom System ausgestellte Referenz, die ablaufen kann. Läuft sie ab, kann die App die Datei nicht mehr öffnen, auch wenn sie noch am selben Ort liegt.
Was sie ungültig macht:
- Die Datei verschieben, umbenennen oder neu erstellen.
- Einen Ordner im Pfad umbenennen.
- Den Rechner aus einer Sicherung wiederherstellen.
- Die Datei liegt auf einem externen oder Netzwerkvolume, das ausgehängt wurde.
Und es gibt einen Fall, der kein Fehler ist, sondern eine Regel: Diese Berechtigungen synchronisieren nicht zwischen Geräten, und zwar nicht aus Nachlässigkeit. Eine solche Berechtigung verweist auf das Dateisystem einer bestimmten Maschine; auf einer anderen zeigt sie ins Leere, und sie mitzunehmen erzeugt Fehler ohne sichtbare Erklärung — typischerweise eine SSH-Authentifizierung, die grundlos scheitert.
Die Lösung ist immer dieselbe: Wählen Sie die Datei erneut aus. Sonst geht nichts verloren; der Zugriff muss nur noch einmal erteilt werden.
Was er abfängt, warum, und wie Sie es trotzdem ausführen, wenn Sie sicher sind.
Der sichere Modus prüft Anweisungen vor dem Senden und stoppt jene, die Daten unwiderruflich zerstören können: DROP, TRUNCATE sowie DELETE oder UPDATE ohne WHERE-Klausel.
Es ist keine Rechtebeschränkung. Ihr Konto darf das durchaus; der sichere Modus lässt Sie nur bestätigen, dass Sie es so gemeint haben. Er existiert für den Sekundenfehler: das DELETE, dessen WHERE draußen blieb, weil Sie es vor dem Ausführen nur halb markiert hatten.
Um es trotzdem auszuführen, schalten Sie den sicheren Modus in der Leiste des SQL-Editors aus und starten Sie erneut. Der Schalter liegt offen sichtbar und nicht tief in den Einstellungen — gerade damit das Ausschalten ein bewusster und kurzzeitiger Akt ist.
Praxistipp: In Produktionsprofilen eingeschaltet lassen, in Entwicklungsprofilen aus. Die Einstellung gilt je Profil, man muss also nicht daran denken.
Wo Sie ihn eingeben, wo er gespeichert wird und warum er nicht mit den Einstellungen reist.
Wo es zu finden ist: Calíope › Einstellungen › KI-Assistent
Der SQL-Assistent nutzt einen externen Anbieter und braucht einen API-Schlüssel von Ihnen, um mit ihm zu sprechen. Er wird unter Einstellungen › KI-Assistent eingetragen.
Wo er gespeichert wird: im Schlüsselbund des Systems, nicht in einer App-Datei. Weder die Konfigurationssicherung noch die normale Synchronisierung nimmt ihn standardmäßig mit: Ein Geheimnis verlässt dieses Gerät nur, wenn Sie es ausdrücklich verlangen und mit einem in diesem Moment gewählten Passwort verschlüsseln.
Wenn Sie gerade ein anderes Gerät eingerichtet haben und der Assistent dort nicht arbeitet, liegt es daran: Der Schlüssel muss auf jedem Gerät eingegeben werden, oder die Schlüsselbund-Synchronisierung muss in den Einstellungen aktiv sein.
Calíope steht nicht zwischen Ihnen und dem Anbieter. Der Schlüssel gehört Ihnen, geht direkt an Ihren Anbieter, und der Verbrauch wird Ihrem Konto berechnet. Deshalb werden Nutzungslimits und Guthaben im Dashboard des Anbieters verwaltet und nicht hier.
Stichwörter: API-Schlüssel, Assistent, KI, Schlüsselbund, Anbieter
Der Anbieter hat die Anfrage wegen des Kontingents abgelehnt
Nutzungslimits des Anbieters und was sich aus Calíope heraus einstellen lässt.
Das Kontingent legt nicht Calíope fest, sondern der von Ihnen eingerichtete KI-Anbieter — je nach Tarif und Guthaben.
Zwei verschiedene Grenzen, die denselben Fehler erzeugen:
- Frequenz. Zu viele Anfragen in kurzer Zeit. Eine Minute warten genügt.
- Verbrauch. Guthaben oder Periodenkontingent sind erschöpft. Das muss im Dashboard des Anbieters aufgefüllt werden.
Was sich hier einstellen lässt: Unter Einstellungen › KI-Assistent können Sie die maximalen Tokens pro Antwort senken — der größte Posten — und auf ein günstigeres Modell wechseln. Ein langes Gespräch kostet ebenfalls mehr, weil der Verlauf bei jeder Anfrage mitreist: Ein neues Gespräch zu beginnen senkt die Kosten der folgenden.
Der Rest des Programms arbeitet unverändert. Der Assistent ist nur ein Werkzeug unter vielen; nichts, was Sie mit SQL-Editor, Sicherungen oder Katalogen tun, hängt von ihm ab.
Die Datenbank bleibt in einem Zwischenzustand: wie Sie den Abbruchpunkt finden und was zu tun ist.
Wo es zu finden ist: Workspace › Werkzeuge › Backup
Gilt für:MySQLMariaDBAurora
Eine Wiederherstellung wendet die Datei Anweisung für Anweisung an. Bricht sie ab, ist das bis dahin Angewandte angewandt: Die Datenbank kehrt nicht von selbst in den vorigen Zustand zurück.
Zuerst: Halten Sie sie nicht für in Ordnung. Eine halb wiederhergestellte Datenbank hat vollständige Tabellen, leere Tabellen und fehlende Tabellen — auf den ersten Blick kann sie funktionsfähig wirken.
Wo Sie nachsehen: Das technische Detail des Fehlers nennt die Anweisung, bei der abgebrochen wurde. Meist ist es eines von drei Dingen:
- Eine bereits vorhandene Tabelle. Eine Wiederherstellung in eine nicht leere Datenbank scheitert am ersten wiederholten CREATE TABLE.
- Ein DEFINER, den es auf diesem Server nicht gibt. Sichten, Routinen und Trigger tragen den Benutzer, der sie erstellt hat; fehlt dieses Konto hier, schlagen sie fehl. Calíope entfernt diese Klausel in eigenen Sicherungen, doch eine mit einem anderen Werkzeug erzeugte Datei kann sie enthalten.
- Ein Größenlimit für Anweisungen. Eine Sicherung von einem Server mit hohem max_allowed_packet erzeugt Anweisungen, die ein Server mit dem Standardwert ablehnt.
Der Ausweg: Am saubersten ist es, die Datenbank zu löschen und von Grund auf in eine leere wiederherzustellen. Ein Fortsetzen aus der Mitte verlangt genaue Kenntnis des bereits Angewandten, und die trägt die Datei nicht.