我有一個 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 移至 casefolding 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 可以工作。有什麼線索嗎？