Tengo un KeyCloak 17.0.1 que aparentemente funciona sin problemas en mi servidor, configurado para usar MariaDB. Digo "aparentemente" porque, a día de hoy, todavía no está en producción, aunque comienza en modo de producción, pero está en un servidor de desarrollo y en realidad está ahí sólo para permitirnos a los desarrolladores jugar con él. Lo comienzo con este comando:
bin/kc.sh -v start --hostname=my.real.hostname --https-certificate-file=/etc/letsencrypt/live/my.real.hostname/cert.pem --https-certificate-key-file=/etc/letsencrypt/live/my.real.hostname/privkey.pem --db-url-host localhost --db-username root --db-password my-real-password --proxy=reencrypt --db-schema=KEYCLOAK
Se ejecuta en un sistema Debian 11 con un servidor MariaDB empaquetado en Debian. Para que se ejecute, tuve que mover los datos de MariaDB a un sistema de archivos ext4 que no distingue entre mayúsculas y minúsculas y configurar MariaDB para ignorar las mayúsculas y minúsculas en los nombres de las tablas (vermi publicación aquí). Antes de eso, se quejaba con Schema "KEYCLOAK" not foundun mensaje de error.
Ahora estoy intentando actualizar KC 17.0.1 a KC 18, siguiendoesta guía, pero cuando empiezo KC 18, obtengoeste mensaje de error(en breve Schema "KEYCLOAK" not found).
Dado que KC 17.0.1 se quejaba con el mismo mensaje de error y el problema se resolvió moviendo MariaDB a un sistema de archivos ext4 plegable, quería asegurarme de que MariaDB todavía estuviera ignorando mayúsculas y minúsculas. Entonces intenté ejecutar manualmente, desde la consola MariaDB, la misma declaración SQL que estaba causando el mensaje de error de KC:
MariaDB [(none)]> CREATE TABLE KEYCLOAK.DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID));
que respondió con un mensaje de error diferente al que KC informa en los registros:
ERROR 1050 (42S01): Table 'databasechangeloglock' already exists
entonces KC 18, durante el proceso de actualización, intenta crear una tabla que ya existe. Tal vez piensa que no existe porque no puede encontrar el KEYCLOAKesquema por alguna razón e intenta crearlo, pero, de nuevo, ¿cómo entendió KC 18 que necesitaba actualizar la base de datos, si no podía encontrarla? Realmente no estoy buscando una respuesta a esto: estaría feliz con solo una solución alternativa.
Solo para asegurarme de que MariaDB realmente incluya tanto los esquemas como los nombres de las tablas, aquí hay algunas otras cosas que probé:
# mysqladmin -u root -p variables | grep lower_case_table_names
| lower_case_table_names | 2
# mysql
MariaDB [(none)]> create database TESTDB;
Query OK, 1 row affected (0.000 sec)
MariaDB [(none)]> drop database testdb;
Query OK, 0 rows affected (0.001 sec)
MariaDB [(none)]> drop database nonexistingschemaname;
ERROR 1008 (HY000): Can't drop database 'nonexistingschemaname'; database doesn't exist
MariaDB [(none)]> create database TESTDB;
Query OK, 1 row affected (0.000 sec)
MariaDB [(none)]> use testdb;
Database changed
Entonces, MariaDB parece funcionar correctamente (al menos desde el punto de vista de los casos), pero aún así KC 18 falla al iniciar, mientras que KC 17 funciona. ¿Alguna pista?