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"))
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.
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>
.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.
%LOCALAPPDATA%\Parity\Ethereum\chains
und es hat geholfen.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) rsync
die 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.
MM_MarioMichel
Benutzer2284570