Am un KeyCloak 17.0.1 care aparent funcționează fără probleme pe serverul meu, configurat să folosească MariaDB. Spun „aparent” pentru că, de astăzi, nu este încă în producție, deși începe în modul producție, dar este pe un server de dezvoltare și de fapt este acolo doar pentru a ne lăsa dezvoltatorii să ne jucăm cu el. O incep cu aceasta comanda:
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-parola my-real-word --proxy=reencrypt --db- schema=KEYCHOAK
Acesta rulează pe un sistem Debian 11 cu un server MariaDB pachet Debian. Pentru ca acesta să ruleze, a trebuit să muți datele MariaDB pe un sistem de fișiere ext4 care nu ține seama de majuscule și minuscule și să configurez MariaDB să ignore majuscule și minuscule în numele tabelelor (vezi postarea mea aici). Înainte de asta, se plângea Schema „KEYCLOAK” nu a fost găsită mesaj de eroare.
Acum încerc să fac upgrade KC 17.0.1 la KC 18, în continuare acest ghid, dar când încep KC 18, primesc acest mesaj de eroare (pe scurt Schema „KEYCLOAK” nu a fost găsită).
Deoarece KC 17.0.1 se plângea de același mesaj de eroare și problema a fost rezolvată prin mutarea MariaDB pe un sistem de fișiere ext4 pliabil cu case, am vrut să mă asigur că MariaDB încă ignora majuscule. Așa că am încercat să execut manual, din consola MariaDB, aceeași instrucțiune SQL care a provocat mesajul de eroare KC:
MariaDB [(niciunul)]> CREATE TABLE KEYCLOAK.DATABASECHANGELOGLOCK (ID INT NU NULL, LOCKED BOOLEAN NU NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID));
care a răspuns cu un mesaj de eroare diferit de ceea ce raportează KC în jurnalele:
EROARE 1050 (42S01): Tabelul „databasechangeloglock” există deja
deci KC 18, în timpul procesului de actualizare, încearcă să creeze un tabel care există deja. Poate crede că nu există pentru că nu poate găsi CHEIE schema dintr-un anumit motiv și încearcă să o creeze, dar din nou cum a înțeles KC 18 că trebuie să actualizeze baza de date, dacă nu a putut să o găsească? Nu caut cu adevărat un răspuns la asta: aș fi mulțumit doar cu o soluție.
Doar pentru a mă asigura că MariaDB înfășoară de fapt atât schemele, cât și numele tabelelor, iată câteva alte lucruri pe care le-am încercat:
# mysqladmin -u root -p variabile | grep nume_tabele_minuscule
| nume_tabele_minuscule | 2
# mysql
MariaDB [(niciunul)]> creează baza de date TESTDB;
Interogare OK, 1 rând afectat (0.000 sec)
MariaDB [(niciunul)]> drop database testdb;
Interogare OK, 0 rânduri afectate (0,001 sec)
MariaDB [(niciunul)]> drop database nonexistingschemanname;
EROARE 1008 (HY000): Nu se poate elimina baza de date „nonexistingschemanname”; baza de date nu exista
MariaDB [(niciunul)]> creează baza de date TESTDB;
Interogare OK, 1 rând afectat (0.000 sec)
MariaDB [(niciunul)]> folosește testdb;
Baza de date schimbată
Deci MariaDB pare să funcționeze corect (cel puțin din punctul de vedere al casetei), dar totuși KC 18 se blochează la pornire, în timp ce KC 17 funcționează. Ceva indicii?
