Tôi có KeyCloak 17.0.1 dường như đang hoạt động mà không gặp sự cố trên máy chủ của mình, được định cấu hình để sử dụng MariaDB. Tôi nói "có vẻ như" bởi vì cho đến hôm nay, nó vẫn chưa được sản xuất, mặc dù nó bắt đầu ở chế độ sản xuất, nhưng nó nằm trên một máy chủ phát triển và nó thực sự chỉ ở đó để cho phép các nhà phát triển chúng tôi chơi với nó. Tôi bắt đầu nó bằng lệnh này:
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- lược đồ=KEYCLOAK
Nó đang chạy trên hệ thống Debian 11 với máy chủ MariaDB đóng gói Debian. Để nó chạy, tôi phải di chuyển dữ liệu MariaDB trên hệ thống tệp ext4 không phân biệt chữ hoa chữ thường và định cấu hình MariaDB để bỏ qua chữ hoa chữ thường trong tên bảng (xem bài viết của tôi ở đây). Trước đó, nó đã phàn nàn với Không tìm thấy lược đồ "KEYCLOAK" thông báo lỗi.
Bây giờ tôi đang cố gắng nâng cấp KC 17.0.1 lên KC 18, sau hướng dẫn này, nhưng khi tôi bắt đầu KC 18, tôi nhận được thông báo lỗi này (Nói ngắn gọn Không tìm thấy lược đồ "KEYCLOAK").
Vì KC 17.0.1 phàn nàn với cùng một thông báo lỗi và sự cố đã được giải quyết bằng cách di chuyển MariaDB trên hệ thống tệp ext4 xếp theo trường hợp, tôi muốn đảm bảo rằng MariaDB vẫn bỏ qua trường hợp. Vì vậy, tôi đã thử thực thi thủ công, từ bảng điều khiển MariaDB, cùng một câu lệnh SQL đã gây ra thông báo lỗi KC:
MariaDB [(không có)]> TẠO BẢNG KEYCLOAK.DATABASECHANGELOGLOCK (ID INT KHÔNG NULL, LOCKED BOOLEAN KHÔNG NULL, DẤU THỜI GIAN ĐƯỢC KHÓA, LOCKEDBY VARCHAR(255), RÀNG BUỘC PK_DATABASECHANGELOGLOCK KHÓA CHÍNH (ID));
đã trả lời bằng một thông báo lỗi khác với những gì KC báo cáo trong nhật ký:
LỖI 1050 (42S01): Bảng 'databasechangeloglock' đã tồn tại
nên KC 18 trong quá trình nâng cấp đang cố gắng tạo bảng đã tồn tại. Có lẽ nó nghĩ rằng nó không tồn tại bởi vì nó không thể tìm thấy KHÓA KHÓA lược đồ vì một số lý do và nó cố gắng tạo ra nó, nhưng một lần nữa, làm thế nào mà KC 18 hiểu rằng nó cần phải nâng cấp cơ sở dữ liệu, nếu nó không thể tìm thấy nó? Tôi không thực sự tìm kiếm câu trả lời cho vấn đề này: Tôi rất vui khi chỉ cần một giải pháp thay thế.
Để chắc chắn rằng MariaDB thực sự sắp xếp theo trường hợp cả tên lược đồ và bảng, đây là một số cách khác mà tôi đã thử:
# biến mysqladmin -u root -p | grep Lower_case_table_names
| Lower_case_table_names | 2
# mysql
MariaDB [(không có)]> tạo cơ sở dữ liệu TESTDB;
Truy vấn OK, 1 hàng bị ảnh hưởng (0,000 giây)
MariaDB [(không có)]> thả cơ sở dữ liệu testdb;
Truy vấn OK, 0 hàng bị ảnh hưởng (0,001 giây)
MariaDB [(none)]> xóa tên cơ sở dữ liệu không tồn tại;
LỖI 1008 (HY000): Không thể xóa cơ sở dữ liệu 'không tồn tại lược đồ'; cơ sở dữ liệu không tồn tại
MariaDB [(không có)]> tạo cơ sở dữ liệu TESTDB;
Truy vấn OK, 1 hàng bị ảnh hưởng (0,000 giây)
MariaDB [(không có)]> sử dụng testdb;
Cơ sở dữ liệu đã thay đổi
Vì vậy, MariaDB dường như hoạt động chính xác (ít nhất là từ quan điểm trường hợp), nhưng KC 18 vẫn gặp sự cố khi khởi động, trong khi KC 17 hoạt động. Bất kì manh mối nào?
