Base de datos

Servicio: mariadb · Puerto: 3306 (sólo en la interfaz local) · Tecnología: MariaDB 10.11

Un único servidor MariaDB que aloja dos bases independientes:

Base	De quién es
zertipower-dev	API de Zertipower y API de tiempo real
zertiair	API del Contador

Se rellena sola

Al arrancar por primera vez —y sólo la primera, cuando el volumen está vacío— MariaDB ejecuta en orden alfabético los archivos que tiene montados:

Archivo	Qué hace
sql/00_databases.sql	Crea las dos bases
sql/seed_minimo.sql	Rellena zertipower-dev con el mínimo para arrancar

El seed es sintético: siete filas con roles, una ubicación, un cliente, el usuario admin, una comunidad de ejemplo y dos puntos de suministro con identificadores ficticios. No contiene datos reales de nadie.

Usuario	Contraseña	Rol
admin	admin123	ADMIN

zertiair se crea vacía

La base del Contador se crea, pero no se le aplican sus migraciones, así que no tiene ninguna tabla. Ver API del Contador.

Configuración

Variable	Qué es
MYSQL_ROOT_PASSWORD	Contraseña de root, tomada del secreto DB_PASSWORD

DB_PASSWORD sólo admite letras y dígitos

Se interpola sin codificar dentro de las cadenas de conexión del resto de servicios, así que un #, /, @, :, ? o % parte la URL y el backend no arranca, con un error engañoso: invalid port number in database URL.

Genérala con openssl rand -hex 32. No uses openssl rand -base64, porque su alfabeto incluye / y +.

Cambiarla después no surte efecto

MariaDB fija la contraseña de root sólo en el primer arranque. Para que un valor nuevo se aplique hay que recrear el volumen, lo que borra los datos:

./dev.sh down -v && ./dev.sh up -d

Conectarse

./dev.sh exec mariadb mariadb -u root -proot zertipower-dev

El puerto 3306 está publicado sólo en 127.0.0.1, para poder usar un cliente gráfico desde la misma máquina. En un servidor no debe exponerse a Internet.

Cargar un volcado de producción

./dev.sh exec -T mariadb mariadb -u root -proot zertipower-dev < volcado.sql

Comprueba el esquema del volcado

Un volcado tomado antes de las últimas migraciones puede no traer la tabla energy_realtime ni la columna cups.origin. Si falta alguna, el backend fallará al consultarlas y habrá que aplicar la migración después de cargarlo.

Ver también Volcado del servidor remoto y Trabajar con la base de datos.

Modelo de datos

El diseño funcional del proyecto define, entre otras, las tablas de blockchains, proveedores, contratos inteligentes, tokens, calendario, comunidades, CUPS, clientes, bloques, registros de energía, registro horario de energía, transacciones de energía, permisos y usuarios.

Sobre el volumen esperado, el propio diseño estimaba unos 1,3 MB anuales por contador (150 bytes × 8.760 horas): unos 1,3 GB al año para mil contadores y del orden de 10 TB para diez mil. Es el dato que condiciona cualquier decisión de escalado.