У меня есть 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- схема = ПЛАЩ КЛЮЧА
Он работает в системе Debian 11 с сервером MariaDB, упакованным в Debian. Чтобы запустить его, мне пришлось переместить данные MariaDB в файловую систему ext4, нечувствительную к регистру, и настроить MariaDB на игнорирование регистра в именах таблиц (см. мой пост здесь). До этого жаловался на Схема "KEYCLOAK" не найдена сообщение об ошибке.
Теперь я пытаюсь обновить KC 17.0.1 до KC 18, следуя это руководство, но когда я запускаю КС 18, я получаю это сообщение об ошибке (вкратце Схема "KEYCLOAK" не найдена).
Поскольку KC 17.0.1 жаловался на то же сообщение об ошибке, и проблема была решена путем перемещения MariaDB в файловую систему ext4 с регистром, я хотел убедиться, что MariaDB по-прежнему игнорирует регистр. Поэтому я попытался вручную выполнить из консоли MariaDB тот же оператор SQL, который вызывал сообщение об ошибке KC:
MariaDB [(нет)]> CREATE TABLE KEYCLOAK.DATABASECHANGELOGLOCK (ID INT NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP, LOCKEDBY VARCHAR(255), CONSTRAINT PK_DATABASECHANGELOGLOCK PRIMARY KEY (ID));
который ответил сообщением об ошибке, отличным от того, что KC сообщает в журналах:
ОШИБКА 1050 (42S01): таблица «databasechangeloglock» уже существует
поэтому KC 18 в процессе обновления пытается создать уже существующую таблицу. Может быть, он думает, что не существует, потому что не может найти ПЛАЩ ДЛЯ КЛЮЧЕЙ schema почему-то и пытается ее создать, но опять же, как KC 18 понял, что нужно обновить базу, если не смог ее найти? На самом деле я не ищу ответа на этот вопрос: я был бы доволен обходным путем.
Просто чтобы убедиться, что MariaDB действительно сворачивает как схемы, так и имена таблиц, вот еще несколько вещей, которые я пробовал:
# mysqladmin -u root -p переменные | grep lower_case_table_names
| имена_таблиц_нижних_кейсов | 2
# mysql
MariaDB [(нет)]> создать базу данных TESTDB;
Запрос ОК, затронута 1 строка (0,000 сек.)
MariaDB [(нет)]> удалить базу данных testdb;
Запрос выполнен успешно, затронуто 0 строк (0,001 сек.)
MariaDB [(нет)]> удалить базу данных nonexistingschemaname;
ОШИБКА 1008 (HY000): не удается удалить базу данных «nonexistingschemaname»; база данных не существует
MariaDB [(нет)]> создать базу данных TESTDB;
Запрос ОК, затронута 1 строка (0,000 сек.)
MariaDB [(нет)]> использовать testdb;
База данных изменена
Таким образом, MariaDB работает правильно (по крайней мере, с точки зрения casefold), но все же KC 18 вылетает при запуске, в то время как KC 17 работает. Любые подсказки?
