Обновление до KeyCloak 18 не удалось
У меня есть 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 на игнорирование регистра в именах таблиц (см. мой пост здесь ). До этого он жаловался на сообщение об ошибке.
Сейчас пытаюсь обновить КС 17.0.1 до КС 18, следуя этому руководству , но при запуске КС 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
поэтому КС 18 в процессе обновления пытается создать уже существующую таблицу. Возможно, он думает, что его не существует, потому что не может найтиKEYCLOAKсхема почему-то и пытается ее создать, но опять же как КС 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, похоже, работает правильно (по крайней мере, с точки зрения случая), но KC 18 все равно вылетает при запуске, а KC 17 работает. Есть какие-нибудь подсказки?