(Parität) Wie korrigiere ich "Spaltenfamilien nicht geöffnet"

Starten von Parity/v1.5.0-unstable-0c7b7fc-20161204/x86_64-macos/rustc1.13.0

2016-12-04 18:50:47 Zustands-DB-Konfiguration: schnell

2016-12-04 18:50:47 Betriebsart: aktiv

2016-12-04 18:50:47 Konfiguriert für Frontier/Homestead mit Ethash-Engine

Client-Dienstfehler: Client(Database("Ungültiges Argument: Sie müssen alle Spaltenfamilien öffnen. Spaltenfamilien nicht geöffnet: col5, col4, col3, col2, col1, col0"))

Löschen Sie alle /parity/cache-Dateien und die Synchronisierung sollte dort fortgesetzt werden, wo sie gestoppt wurde.
@MM_MarioMichel wo sind diese Cache-Dateien jetzt mit Openethereum?

Antworten (3)

Die Ursache dafür ist wahrscheinlich eine beschädigte Datenbank, die selbst dadurch verursacht wurde, dass Parity zuvor auf unsaubere Weise heruntergefahren wurde.

Der Fehler, den Sie sehen, wird von Issue #2201 behandelt , wurde aber in #3020 behoben . Ich habe Mühe zu sehen, in welche Version der Fix gegangen ist, aber vermutlich nicht v1.5.0-unstable, was Sie ausführen.

Die Empfehlung in den Anmerkungen zu #2201 lautet, Ihre Blockchain-Daten zu löschen und von Grund auf neu zu synchronisieren.

Client-Dienstfehler: Client(Database("IO error: lock /Users/--------/.parity/906a34e69aec8c0d/v5.3-sec-overlayrecent/db/LOCK: Ressource vorübergehend nicht verfügbar"))
Läuft Parity noch im Hintergrund? Versuchen Sie es auf dem Terminal ps faux | grep parity. Andernfalls können Sie mit etwas wie überprüfen, welcher Prozess die Sperre hat lsof | grep 906a34e69aec8c0d. Wenn Sie herausfinden, welcher Prozess die Sperre hält, beenden Sie ihn mit kill <process_id>.
Ja, Parität läuft immer noch im Hintergrund vom Macos-Installationsprogramm, ich habe es versucht
versucht $ kill parity_906a34e69aec8c0d -bash: kill: parity_906a34e69aec8c0d: Argumente müssen als nächstes Prozess- oder Job-IDs sein?
@RichardHorrocks, da die Neusynchronisierung von Grund auf jetzt im Falle eines vollständigen Archivs 2 Jahre dauert, selbst wenn eine hochmoderne CPU für die Leistung eines einzelnen Threads verwendet wird. Wie kann die Datenbank einfach auf den Block zurückgesetzt werden, bevor sie beschädigt wurde?

Dies wird oft durch eine beschädigte Datenbank verursacht und kann durch vollständiges Zurücksetzen behoben werden mit:

parity db kill

Dies löscht die Kette und den Status und bewirkt eine vollständige Neusynchronisierung, ermöglicht Ihnen jedoch die erneute Verwendung der Parität.

Das hat super funktioniert. dauert eine Weile, um neu zu synchronisieren, aber es funktioniert.
Funktioniert bei mir aus irgendeinem Grund nicht: gist.github.com/Pzixel/c2607b035bcb0208a899111b426c23b4
Ich habe alles manuell entfernt %LOCALAPPDATA%\Parity\Ethereum\chainsund es hat geholfen.
@Afr, da die Neusynchronisierung von Grund auf jetzt 2 Jahre dauert, wenn ein vollständiges Archiv verwendet wird, selbst wenn eine hochmoderne CPU für die Leistung eines einzelnen Threads verwendet wird. Wie kann die Datenbank einfach auf den Block zurückgesetzt werden, bevor sie beschädigt wurde?

Ich bin gerade auf diesen Fehler gestoßen, als ich einen Paritätsknoten von einem Server auf einen anderen übertragen habe.

Mein Problem war, dass ich (dummerweise) rsyncdie Kettendaten an den neuen Server gesendet habe, ohne den Knoten gestoppt zu haben. Als solches wurde die Datenbank beschädigt.

Interessanterweise ist dies möglicherweise die beste Vorgehensweise, wenn Sie einen „Live“-Knoten übertragen.

Wie Sie vielleicht wissen, synchronisiert rsync standardmäßig neue oder geänderte Dateien. Ich habe die Dateien synchronisiert, während der Knoten lief. Dies dauerte ungefähr 40 Minuten. Nachdem es abgeschlossen war (und nicht geladen wurde), stoppte ich den Knoten und rsyncte erneut. Dies synchronisierte nur die geänderten Dateien und dauerte nur wenige Sekunden. Mein neuer Knoten war nicht mehr beschädigt und meine Ausfallzeit war eine Frage von Sekunden.

Was ist, wenn das Problem bei einem Block liegt, der vor Jahren beschädigt und unbemerkt war?