Podar la base de datos para el validador Ethereum Geth. Liberar espacio en el SSD.
- Detalles
- Creado: Viernes, 08 Diciembre 2023 02:24
Para la minería POS de la criptomoneda Ethereum, se utiliza un software especial bajo el nombre general de Validador. El Validador, a su vez, consta de dos componentes: la Capa de Ejecución y la Capa de Consenso. La Capa de Consenso es la minería POS en sí, mientras que la Capa de Ejecución es la antigua red blockchain de Ethereum que operaba desde 2015 hasta la fusión en 2022. Todos los datos acumulados durante este tiempo se han transferido por completo a la nueva red POS.
Dado que hay varias opciones de software de validador, las siguientes consideraciones serán aplicables al cliente GETH, el más popular.
Cada capa utiliza su propia base de datos, y para la Capa de Ejecución, esta base de datos aumenta en 14 GB cada semana. El tamaño total de la base de datos ya es casi de 2 TB. Para el validador de archivo (utilizado para varios servicios como Etherscan y beacoincha.in), los requisitos de espacio en SSD son aún mayores, superando los 14 TB cuando se utiliza el cliente GETH.
Para reducir los requisitos de espacio en SSD para un nodo completo (validador estándar), los desarrolladores idearon un procedimiento de poda de la base de datos a los últimos 128 bloques para cada transacción.
Teóricamente, este procedimiento permite el uso de un SSD de 1 TB, pero la poda debe hacerse cada mes. Por lo tanto, se recomienda comprar un SSD de 2 TB para el validador y realizar la reducción de la base de datos una vez al año. Este procedimiento lleva aproximadamente de 6 a 7 horas, durante las cuales su validador estará fuera de línea y podría incurrir en penalizaciones.
La Capa de Consenso también tiene su propia base de datos, pero su tamaño no aumenta tan rápidamente como la base de datos de la Capa de Ejecución. Por lo tanto, el enfoque principal está en reducir el tamaño de la base de datos de la Capa de Ejecución.
Importante: Desde la versión 1.13.0, el cliente GETH admite el nuevo indicador --state.scheme=path así como el nuevo tipo de base de datos Pebble, si ya está usando --state.scheme=path o simplemente va a instalar el validador ETH con el nuevo tipo de base de datos, ya no es necesario recortar la base de datos. Para todos los demás clientes que hayan actualizado a la versión 1.13.0 o superior, la versión anterior de la base de datos sigue funcionando. Para cambiar a una nueva base de datos, debe eliminar completamente la base de datos del cliente Geth (comando geth removeb), especificar el indicador --state.scheme=path y --db.engine pebble en la configuración de GETH y esperar a que se complete la sincronización de el nodo durante 1 día, siempre que tenga un SSD rápido, una CPU moderna y potente e Internet rápido.
Ahora pasemos a las instrucciones sobre cómo realizar esta poda de la base de datos para el cliente GETH.
Podado de la base de datos para GETH
Importante: Solo puedes podar la base de datos si hay al menos 40 GB de espacio libre en el SSD. Si tienes menos espacio en el SSD, puedes aumentarlo reduciendo el archivo SWAP o expandiendo el tamaño del disco lógico. Alternativamente, mueve temporalmente la base de datos de la capa de consenso a otro disco o, como último recurso, realiza una nueva sincronización desde cero, pero con la base de datos Pebble.
Para verificar el espacio libre en el disco en Linux, utiliza el siguiente comando:
Important: You can only prune the database if there is at least 40GB of free space on the SSD. If you have less space on the SSD, you can increase it by reducing the SWAP file or expanding the logical disk size. Alternatively, temporarily move the consensus layer's database to another disk, or as a last resort, perform a new synchronization from scratch, but with the Pebble database.
To check free space on the disk in Linux, use the command:
df -h
Otro punto: Tu cliente GETH debe estar completamente sincronizado y funcionar durante al menos 35 minutos después de comenzar para recopilar los datos necesarios.
El primer paso es detener el proceso GETH:
sudo systemctl stop geth
También puedes detener la capa de consenso. Comandos de detención para el cliente PRYSM:
sudo systemctl stop prysmvalidator
sudo systemctl stop prysmbeacon
Espera 3 minutos antes de pasar al siguiente paso.
Antes de realizar más acciones, se recomienda iniciar un multiplexor de terminales, como TMUX, para asegurarte de que el proceso de poda no se interrumpa si pierdes el acceso a la terminal del servidor remoto.
tmux
Esto es necesario en caso de que pierdas el acceso a la terminal remota. En este caso, el proceso de poda de la base de datos no se interrumpirá junto con tu sesión.
Ahora puedes comenzar a reducir el tamaño de la base de datos.
Comando para podar la base de datos:
geth snapshot prune-state
Si instalaste el validador siguiendo las instrucciones de Somer Esat en Medium, lo que significa que GETH se inicia con systemd, el comando sería diferente:
sudo -u <user> geth --datadir <path> snapshot prune-state
Por ejemplo:: sudo -u geth geth --datadir /var/lib/geth snapshot prune-state
o sudo -u goeth geth --datadir /var/lib/goethereum snapshot prune-state
La elección del comando depende de dónde se almacena la base de datos GETH en el servidor. Puedes encontrar la ruta de la base de datos en el archivo geth.service:
sudo nano /etc/systemd/system/geth.service
La ruta de la base de datos se especifica bajo la bandera --datadir.
Si se hace correctamente, el proceso de reducción de la base de datos comenzará, dividido en 3 etapas:
La primera etapa es la construcción del filtro Bloom, que tomó poco más de 2 horas en mi computadora
elapsed: cuánto tiempo ha pasado
eta: tiempo estimado hasta el final del proceso
La poda real de la base de datos comenzará, tomando aproximadamente 4 horas más.
Después de la poda, la base de datos se compactará, indicado en la consola como "Compacting database". Este proceso puede tomar aproximadamente una hora adicional.
Tras completar con éxito la tarea de reducción de la base de datos del validador de Ethereum, un mensaje indicará "State pruning successful".
Apaga TMUX:
tmux kill-server
A continuación, inicia el cliente GETH y el validador si también se apagaron:
sudo systemctl start geth
sudo systemctl start prysmbeacon
sudo systemctl start prysmvalidator
Error: "Snapshot not old enough yet: need 128 more blocks"
Este error ocurre si tu validador no ha estado en funcionamiento el tiempo suficiente antes de decidir reducir la base de datos. Se recomienda que GETH se ejecute durante al menos 35 minutos antes de la poda.
También, este error ocurre si elegiste el comando incorrecto para podar la base de datos del cliente GETH. Especifica la ruta correcta o utiliza un formato de comando diferente.
Otra forma de iniciar la poda de la base de datos de Ethereum GETH
Edita el archivo existente geth.service:
sudo nano /etc/systemd/system/geth.service
Agrega la siguiente línea al final de ExecStart:
snapshot prune-state
Todos los demás parámetros deben permanecer sin cambios.
Recarga systemd:
sudo systemctl daemon-reload
Inicia el servicio GETH:
sudo systemctl start geth
Puedes monitorear el progreso de la poda de la base de datos con el comando:
journalctl -fu geth
Después de completar la poda de la base de datos GETH, elimina la línea snapshot prune-state del archivo geth.service:
sudo nano /etc/systemd/system/geth.service
Recarga systemd:
sudo systemctl daemon-reload
Inicia el servicio GETH:
sudo systemctl start geth
El proceso completo de reducción de la base de datos del cliente GETH tomó alrededor de 7 horas en un servidor con un procesador Ryzen 1700X, 32 GB de RAM y un SSD ADATA XPG GAMMIX S11 Pro de 2 TB.
Si la configuración de tu servidor es significativamente más débil, el tiempo total dedicado a reducir la base de datos será mayor. Por el contrario, en una computadora más potente, la poda puede tomar menos tiempo.
Conclusión: Podar la base de datos de un validador ETH que se ejecuta en el cliente GETH es una función muy útil, ya que permite el uso de un SSD mucho más pequeño de lo que realmente se requeriría. Esto también elimina problemas si tu SSD de 2 TB ya no es suficiente para admitir el validador de Ethereum. En solo unas pocas horas, puedes reducir la base de datos y evitar la necesidad de una sincronización completa de GETH durante 1 dia para hacer la transición a Pebble, donde la reducción de la base de datos ocurre automáticamente.
Si decides no cambiar a Pebble, recuerda ejecutar periódicamente el comando snapshot prune-state mientras aún haya 40 GB de espacio libre en tu SSD.