ScyllaDB es una base de datos NoSQL distribuida compatible con Apache Cassandra: usa el mismo lenguaje CQL, los mismos drivers y el mismo modelo de datos, pero está escrita en C++ con una arquitectura shard-per-core que asigna a cada núcleo de CPU su propia parte de los datos y de la memoria. En este tutorial instalarás ScyllaDB en tres servidores Ubuntu 24.04, formarás un clúster con un nodo por rack, activarás la autenticación y crearás un keyspace replicado con una tabla de ejemplo.
Requisitos previos
- Tres servidores con Ubuntu 24.04 LTS, por ejemplo VPS de CubePath, conectados por una red privada. Para una prueba puedes usar uno solo y ajustar el factor de replicación a 1 donde se indica.
- Al menos 2 vCPU y 4 GB de RAM por nodo. ScyllaDB reserva casi toda la memoria del servidor para sí mismo, así que no instales otros servicios pesados en los mismos nodos.
- Un usuario no root con privilegios
sudoen cada servidor. - Las IP privadas de los tres nodos. En esta guía se usan
10.0.0.11,10.0.0.12y10.0.0.13; sustitúyelas por las tuyas.
Salvo que se indique lo contrario, los pasos 1 a 3 se repiten en los tres nodos.
Paso 1: Instalar ScyllaDB
ScyllaDB ofrece un instalador que añade su repositorio APT con la clave de firma en /etc/apt/keyrings e instala los paquetes. Descárgalo y revísalo antes de ejecutarlo:
curl -sSf https://get.scylladb.com/server -o scylla-install.sh
less scylla-install.sh
Consulta las versiones con soporte activo:
bash scylla-install.sh --list-active-releases
ScyllaDB Active Releases (Latest to Oldest):
=============================================
2026.3: 2026.3.1 - latest
2026.2: 2026.2.7
2026.1: 2026.1.13 [LTS]
2025.1: 2025.1.15 [LTS]
Para un clúster de producción conviene una versión LTS. Instálala indicando su rama:
sudo bash scylla-install.sh --scylla-version 2026.1
Comprueba la versión instalada:
scylla --version
2026.1.13-0.20260911.8d1b4c0f2a17
El instalador no arranca el servicio: antes hay que preparar el sistema y la configuración.
Paso 2: Preparar el sistema
En producción, ScyllaDB necesita sus datos en un disco dedicado con sistema de archivos XFS, y el script interactivo scylla_setup se encarga de prepararlo: crea el RAID y el sistema de archivos, ajusta el kernel y mide el rendimiento del disco para calibrar la E/S. Si tus nodos tienen un disco de datos dedicado, ejecútalo y responde a sus preguntas:
sudo scylla_setup
En un VPS con un único disco, o en un entorno de pruebas, activa el modo de desarrollo, que desactiva las comprobaciones de hardware y de disco:
sudo scylla_dev_mode_setup --developer-mode 1
Advertenciael modo de desarrollo no calibra la E/S ni verifica el sistema de archivos. Sirve para aprender y hacer pruebas, pero en producción usa
scylla_setupcon discos dedicados.
Paso 3: Configurar el nodo
Toda la configuración está en /etc/scylla/scylla.yaml. Ábrelo:
sudo nano /etc/scylla/scylla.yaml
Busca cada una de estas claves y ajústala. Este es el bloque para el primer nodo (10.0.0.11):
cluster_name: 'cubepath-cluster'
seed_provider:
- class_name: org.apache.cassandra.locator.SimpleSeedProvider
parameters:
- seeds: "10.0.0.11"
listen_address: 10.0.0.11
rpc_address: 10.0.0.11
endpoint_snitch: GossipingPropertyFileSnitch
cluster_namedebe ser idéntico en todos los nodos; un nodo con otro nombre no se une al clúster.seedses la lista de nodos que un nodo nuevo contacta para descubrir el clúster. Basta con uno o dos, y deben ser iguales en todos los nodos.listen_addresses la IP para la comunicación entre nodos (puerto 7000) yrpc_addressla IP donde escuchan los clientes CQL (puerto 9042). Usa la IP privada de cada nodo.GossipingPropertyFileSnitchlee el centro de datos y el rack de cada nodo de un archivo local, lo que permite repartir las réplicas entre racks.
En los otros dos nodos, cluster_name, seeds y endpoint_snitch son iguales; cambia solo listen_address y rpc_address por la IP de cada uno (10.0.0.12 y 10.0.0.13).
Define ahora el centro de datos y el rack del nodo:
sudo nano /etc/scylla/cassandra-rackdc.properties
dc=dc1
rack=rack1
Usa rack=rack2 en el segundo nodo y rack=rack3 en el tercero. Con un nodo por rack y factor de replicación 3, cada rack guarda una réplica completa, y ScyllaDB puede repartir los datos de forma uniforme.
Importanteel snitch, el centro de datos y el rack deben estar configurados antes de arrancar el nodo por primera vez. Cambiarlos después en un nodo con datos no está soportado.
Por último, permite el tráfico entre nodos y de clientes solo desde la red privada (10.0.0.0/24 en este ejemplo):
sudo ufw allow from 10.0.0.0/24 to any port 7000 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 9042 proto tcp
sudo ufw allow from 10.0.0.0/24 to any port 19042 proto tcp
El puerto 7000 es la comunicación entre nodos, el 9042 el CQL estándar y el 19042 el puerto shard-aware que usan los drivers de ScyllaDB para enviar cada consulta directamente al núcleo que tiene los datos.
Paso 4: Arrancar el primer nodo
Arranca el servicio solo en el nodo semilla (10.0.0.11):
sudo systemctl enable --now scylla-server
El arranque tarda entre medio minuto y un par de minutos. Sigue el progreso con:
sudo journalctl -u scylla-server -f
Cuando aparezca un mensaje de que el servidor está listo para CQL (Starting listening for CQL clients), pulsa Ctrl+C y comprueba el estado del nodo:
nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.0.0.11 512 KB 256 ? 4f2a8c1e-6b3d-4e0a-9c7f-2d5e8a1b3c90 rack1
UN significa Up (activo) y Normal (sirviendo datos).
Paso 5: Añadir los otros nodos
Arranca el segundo nodo (10.0.0.12) y espera a que termine de unirse antes de arrancar el tercero. Los nodos deben entrar de uno en uno:
sudo systemctl enable --now scylla-server
Mientras se une aparecerá como UJ (Up, Joining) en nodetool status. Cuando pase a UN, repite en el tercer nodo. Al final, desde cualquier nodo:
nodetool status
Datacenter: dc1
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 10.0.0.11 724 KB 256 ? 4f2a8c1e-6b3d-4e0a-9c7f-2d5e8a1b3c90 rack1
UN 10.0.0.12 688 KB 256 ? a91c0d47-2e6f-4b8a-8d13-7c4e9f0a2b61 rack2
UN 10.0.0.13 702 KB 256 ? d3e7b5a2-9f14-4c6d-b0e8-5a2c7f1d4e83 rack3
Paso 6: Activar la autenticación
Por defecto ScyllaDB acepta conexiones CQL sin usuario ni contraseña. Actívala en los tres nodos editando /etc/scylla/scylla.yaml:
sudo nano /etc/scylla/scylla.yaml
authenticator: PasswordAuthenticator
authorizer: CassandraAuthorizer
Reinicia los nodos de uno en uno, esperando a que cada uno vuelva a UN en nodetool status antes de pasar al siguiente:
sudo systemctl restart scylla-server
Al activar la autenticación existe un superusuario por defecto, cassandra, con contraseña cassandra. Conéctate con él desde uno de los nodos:
cqlsh 10.0.0.11 -u cassandra -p cassandra
Crea un superusuario propio con una contraseña fuerte (sustituye your_strong_password):
CREATE ROLE admin WITH PASSWORD = 'your_strong_password' AND SUPERUSER = true AND LOGIN = true;
Sal con exit, vuelve a entrar con el nuevo usuario y elimina el predeterminado, que cualquiera conoce:
cqlsh 10.0.0.11 -u admin
DROP ROLE cassandra;
cqlsh pide la contraseña cuando no la pasas con -p, así que no queda en el historial.
Paso 7: Crear un keyspace y una tabla
Un keyspace agrupa tablas y define cómo se replican. Con NetworkTopologyStrategy indicas cuántas réplicas guardar en cada centro de datos. Dentro de cqlsh, conectado como admin, crea un keyspace con tres réplicas en dc1 (usa 'dc1': 1 si solo tienes un nodo):
CREATE KEYSPACE tienda
WITH replication = {'class': 'NetworkTopologyStrategy', 'dc1': 3};
En ScyllaDB, como en Cassandra, las tablas se diseñan a partir de las consultas que vas a hacer. Esta tabla guarda los pedidos de cada cliente ordenados del más reciente al más antiguo. La clave de partición, cliente_id, decide en qué nodos se guardan los datos; las columnas de agrupación, creado y pedido_id, ordenan las filas dentro de la partición:
CREATE TABLE tienda.pedidos (
cliente_id uuid,
creado timestamp,
pedido_id timeuuid,
total decimal,
estado text,
PRIMARY KEY ((cliente_id), creado, pedido_id)
) WITH CLUSTERING ORDER BY (creado DESC, pedido_id ASC);
Inserta algunos pedidos para un mismo cliente:
INSERT INTO tienda.pedidos (cliente_id, creado, pedido_id, total, estado)
VALUES (6a1f4d2e-3b5c-4e7f-8a9b-0c1d2e3f4a5b, '2026-09-20 10:15:00+0000', now(), 59.90, 'enviado');
INSERT INTO tienda.pedidos (cliente_id, creado, pedido_id, total, estado)
VALUES (6a1f4d2e-3b5c-4e7f-8a9b-0c1d2e3f4a5b, '2026-09-24 18:02:00+0000', now(), 124.50, 'pendiente');
Pide que las lecturas confirmen con la mayoría de réplicas y consulta los pedidos del cliente:
CONSISTENCY QUORUM;
SELECT creado, total, estado FROM tienda.pedidos
WHERE cliente_id = 6a1f4d2e-3b5c-4e7f-8a9b-0c1d2e3f4a5b;
creado | total | estado
---------------------------------+--------+-----------
2026-09-24 18:02:00.000000+0000 | 124.50 | pendiente
2026-09-20 10:15:00.000000+0000 | 59.90 | enviado
(2 rows)
Con tres réplicas y QUORUM, lecturas y escrituras siguen funcionando aunque caiga un nodo. Puedes comprobarlo parando ScyllaDB en uno de ellos (sudo systemctl stop scylla-server) y repitiendo la consulta desde otro.
Las consultas que no filtran por la clave de partición tienen que recorrer todo el clúster, y ScyllaDB las rechaza salvo que añadas ALLOW FILTERING. Si necesitas buscar por otra columna, crea una tabla adicional que use esa columna como clave de partición y escribe en ambas.
Paso 8: Conectar aplicaciones
Cualquier driver de Cassandra funciona con ScyllaDB, pero los drivers shard-aware de ScyllaDB aprovechan mejor su arquitectura porque abren una conexión por núcleo y envían cada consulta al shard correcto a través del puerto 19042. Por ejemplo, en Python se instala scylla-driver, que mantiene la misma API que cassandra-driver:
python3 -m venv ~/scylla-app
~/scylla-app/bin/pip install scylla-driver
Pasa al driver las IP de varios nodos como puntos de contacto, el usuario de la aplicación y el nombre del centro de datos local (dc1) en la política de balanceo, para que no envíe tráfico a otros centros de datos si amplías el clúster.
Paso 9: Supervisar el clúster
nodetool es la herramienta principal de administración. Además de status, estos comandos son útiles en el día a día:
nodetool info
nodetool tablestats tienda.pedidos
Cada nodo expone métricas en formato Prometheus en el puerto 9180:
curl -s http://localhost:9180/metrics | grep -m 3 '^scylla_'
Para paneles completos, ScyllaDB publica ScyllaDB Monitoring Stack, basado en Prometheus y Grafana, que recoge esas métricas de todos los nodos.
Migrar desde Cassandra
Como el protocolo y CQL son compatibles, las aplicaciones solo tienen que cambiar los puntos de contacto. Para los datos, exporta primero el esquema desde Cassandra y créalo en ScyllaDB:
cqlsh cassandra_ip -e "DESCRIBE KEYSPACE tienda" > tienda.cql
cqlsh 10.0.0.11 -u admin -f tienda.cql
Revisa el archivo antes de aplicarlo: algunas opciones de tabla específicas de Cassandra (como ciertas estrategias de compactación o índices SAI) pueden necesitar cambios. Para mover los datos, las opciones habituales son sstableloader sobre una instantánea de Cassandra o ScyllaDB Migrator, basado en Spark, para volúmenes grandes o migraciones sin parada.
Solución de problemas
- Un nodo no aparece en
nodetool status: comprueba quecluster_nameyseedsson idénticos en todos los nodos y que el puerto 7000 está abierto entre ellos (nc -zv 10.0.0.11 7000). - El servicio falla al arrancar con errores sobre el disco o
io_properties: el sistema no está preparado. Ejecutascylla_setupo, en pruebas,scylla_dev_mode_setup --developer-mode 1. Unable to connect to any serversen cqlsh:rpc_addressapunta a otra IP o el nodo aún está arrancando. Revisasudo journalctl -u scylla-server -n 50.Cannot achieve consistency level QUORUM: hay menos de dos réplicas disponibles para esa partición. Comprueba qué nodos están caídos connodetool status.
Conclusión
Tienes un clúster de ScyllaDB de tres nodos en Ubuntu 24.04, con un nodo por rack, autenticación activada y un keyspace replicado tres veces que tolera la caída de un nodo. Como siguientes pasos, activa el cifrado TLS entre nodos y con los clientes, instala ScyllaDB Monitoring Stack y programa copias de seguridad con ScyllaDB Manager o con nodetool snapshot.