(Paridad) ¿Cómo corrijo las "familias de columnas no abiertas"?

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

2016-12-04 18:50:47 Configuración de base de datos de estado: rápido

2016-12-04 18:50:47 Modo de funcionamiento: activo

2016-12-04 18:50:47 Configurado para Frontier/Homestead usando el motor Ethash

Error de servicio de cliente: Cliente (Base de datos ("Argumento no válido: debe abrir todas las familias de columnas. Familias de columnas no abiertas: col5, col4, col3, col2, col1, col0"))

Elimine todos los archivos /parity/cache y debería reanudar la sincronización desde donde se detuvo.
@MM_MarioMichel, ¿dónde están ahora esos archivos de caché con Openethereum?

Respuestas (3)

La causa de esto es probablemente una base de datos corrupta, causada por el hecho de que Parity se cerró previamente de manera incorrecta.

El error que está viendo está cubierto por el problema #2201 , pero se corrigió en el #3020 . Estoy luchando por ver en qué versión entró la solución, pero presumiblemente no v1.5.0-unstable, que es lo que está ejecutando.

La recomendación en las notas a #2201 es eliminar sus datos de blockchain y volver a sincronizar desde cero.

Error de servicio del cliente: Cliente (Base de datos ("Error de E/S: bloquear /Usuarios/--------/.parity/906a34e69aec8c0d/v5.3-sec-overlayrecent/db/LOCK: Recurso temporalmente no disponible"))
¿Se sigue ejecutando Parity en segundo plano? En la terminal, intente ps faux | grep parity. De lo contrario, puede verificar qué proceso tiene el bloqueo usando algo como lsof | grep 906a34e69aec8c0d. Cuando encuentre qué proceso mantiene el bloqueo, elimínelo con kill <process_id>.
sí, la paridad todavía se ejecuta en segundo plano desde el instalador de macos, lo he intentado
intentó $ matar parity_906a34e69aec8c0d -bash: matar: parity_906a34e69aec8c0d: ¿los argumentos deben ser ID de proceso o trabajo a continuación?
@RichardHorrocks dado que la sincronización desde cero ahora toma 2 años en el caso de un archivo completo, incluso cuando se usa una CPU de última generación para el rendimiento de un solo subproceso, ¿cómo restablecer la base de datos al bloque antes de que se rompa?

Esto a menudo es causado por una base de datos corrupta y puede resolverse restableciéndola completamente con:

parity db kill

Esto borra la cadena y el estado y provoca una resincronización completa, pero le permite usar la paridad nuevamente.

Esto funcionó muy bien. Tarda un poco en resincronizarse pero funciona.
Eliminé todo manualmente %LOCALAPPDATA%\Parity\Ethereum\chainsy ayudó.
@Afr desde que volver a sincronizar desde cero ahora toma 2 años en el caso de un archivo completo, incluso cuando se usa una CPU de última generación para el rendimiento de un solo subproceso, ¿cómo restablecer la base de datos al bloque antes de que se rompa?

Acabo de encontrar este error al transferir un nodo de paridad de un servidor a otro.

Mi problema fue que (tontamente) rsyncedité los datos de la cadena en el nuevo servidor sin haber detenido el nodo. Como tal, la base de datos estaba dañada.

Curiosamente, si está transfiriendo un nodo 'en vivo', esta puede ser la mejor manera de hacer las cosas.

Como sabrá, por defecto, rsync sincroniza archivos nuevos o modificados. Sincronicé los archivos mientras el nodo se estaba ejecutando. Esto tomó aproximadamente 40 minutos. Después de que se completó (y no se cargó), detuve el nodo y volví a sincronizar. Esto sincronizó solo los archivos modificados y tomó unos segundos. Mi nuevo nodo ya no estaba dañado y mi tiempo de inactividad fue cuestión de segundos.

¿Qué pasa si el problema radica en un bloque que se corrompió hace años y pasó desapercibido?
(Paridad) ¿Cómo corrijo las "familias de columnas no abiertas"?
RespuestasAquíPolítica de privacidad1y, 0v