У меня есть KeyCloak 17.0.1, который, по-видимому, работает без проблем на моем сервере, настроенном на использование MariaDB. Я говорю «по-видимому», потому что на сегодняшний день он еще не находится в производстве, хотя и запускается в режиме производства, но он находится на сервере разработки и на самом деле находится там только для того, чтобы мы, разработчики, могли с ним поиграться. Я запускаю его с помощью этой команды:
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
Он работает на системе Debian 11 с сервером MariaDB, упакованным Debian. Чтобы он работал, мне пришлось переместить данные MariaDB в нечувствительную к регистру файловую систему ext4 и настроить MariaDB на игнорирование регистра в именах таблиц (см.мой пост здесь). До этого он жаловался на Schema "KEYCLOAK" not foundсообщение об ошибке.
Сейчас я пытаюсь обновить KC 17.0.1 до KC 18, следуяэто руководство, но когда я начинаю KC 18, я получаюэто сообщение об ошибке(суммируя Schema "KEYCLOAK" not found).
Поскольку KC 17.0.1 жаловался на то же самое сообщение об ошибке, и проблема была решена перемещением MariaDB на файловую систему ext4 с регистром, я хотел убедиться, что MariaDB по-прежнему игнорирует регистр. Поэтому я попытался вручную выполнить из консоли MariaDB тот же оператор SQL, который вызывал сообщение об ошибке 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));
который ответил сообщением об ошибке, отличным от того, которое KC сообщает в журналах:
ERROR 1050 (42S01): Table 'databasechangeloglock' already exists
так что KC 18 во время процесса обновления пытается создать таблицу, которая уже существует. Может быть, он думает, что ее не существует, потому что KEYCLOAKпо какой-то причине не может найти схему, и пытается ее создать, но опять же, как KC 18 понял, что ему нужно обновить базу данных, если он не смог ее найти? Я на самом деле не ищу ответа на этот вопрос: я был бы рад просто обходному пути.
Чтобы убедиться, что MariaDB действительно преобразует регистр как схем, так и имен таблиц, я попробовал сделать еще несколько вещей:
# 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
Итак, MariaDB, похоже, работает правильно (по крайней мере, с точки зрения casefold), но KC 18 все равно вылетает при запуске, в то время как KC 17 работает. Есть какие-нибудь подсказки?