我有一个 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 系统上，带有 Debian 打包的 MariaDB 服务器。为了运行它，我必须将 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 控制台手动执行导致 KC 错误消息的相同 SQL 语句：
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 似乎可以正常工作（至少从大小写角度来看），但 KC 18 在启动时仍然崩溃，而 KC 17 可以正常工作。有什么线索吗？