Tenho um KeyCloak 17.0.1 que aparentemente está funcionando sem problemas no meu servidor, configurado para usar MariaDB. Digo "aparentemente" porque, a partir de hoje, ainda não está em produção, embora comece no modo de produção, mas está em um servidor de desenvolvimento e na verdade está lá apenas para permitir que nós, desenvolvedores, brinquemos com ele. Eu começo com 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
Ele está rodando em um sistema Debian 11 com um servidor MariaDB empacotado em Debian. Para executá-lo, tive que mover os dados do MariaDB em um sistema de arquivos ext4 que não diferencia maiúsculas de minúsculas e configurar o MariaDB para ignorar maiúsculas e minúsculas nos nomes das tabelas (consulteminha postagem aqui). Antes disso, ele estava reclamando com Schema "KEYCLOAK" not foundmensagem de erro.
Agora estou tentando atualizar o KC 17.0.1 para o KC 18, seguindoeste guia, mas quando inicio o KC 18, receboesta mensagem de erro(resumidamente Schema "KEYCLOAK" not found).
Como o KC 17.0.1 estava reclamando com a mesma mensagem de erro e o problema foi resolvido movendo o MariaDB em um sistema de arquivos ext4 casefolding, eu queria garantir que o MariaDB ainda estivesse ignorando o caso. Então tentei executar manualmente, no console MariaDB, a mesma instrução SQL que estava causando a mensagem de erro 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 respondeu com uma mensagem de erro diferente da que KC relata nos logs:
ERROR 1050 (42S01): Table 'databasechangeloglock' already exists
então o KC 18, durante o processo de atualização, está tentando criar uma tabela que já existe. Talvez ele pense que não existe porque não consegue encontrar o KEYCLOAKesquema por algum motivo e tenta criá-lo, mas como o KC 18 entendeu que precisava atualizar o banco de dados, se não conseguiu encontrá-lo? Na verdade, não estou procurando uma resposta para isso: ficaria feliz com apenas uma solução alternativa.
Apenas para ter certeza de que o MariaDB está realmente dobrando os nomes dos esquemas e das tabelas, aqui estão algumas outras coisas que tentei:
# 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
Portanto, o MariaDB parece funcionar corretamente (pelo menos do ponto de vista do caso), mas ainda assim o KC 18 trava na inicialização, enquanto o KC 17 funciona. Alguma pista?