Đã đăng vào Thứ Ba, 12:47 SA 7 phút đọc

Apache Derby Bài 48: Nâng cấp phiên bản Derby (Version Upgrade) và Migration dữ liệu an toàn

1. Bản chất của việc nâng cấp trong Apache Derby

Trong vòng đời của một ứng dụng, bạn sẽ phải đối mặt với việc nâng cấp phiên bản hệ quản trị cơ sở dữ liệu (ví dụ từ Derby 10.14 lên 10.17) để vá các lỗ hổng bảo mật hoặc tận dụng các tính năng mới.

Khác với các phần mềm thông thường, nâng cấp cơ sở dữ liệu mang theo rủi ro rất lớn vì định dạng tệp tin vật lý trên đĩa cứng có thể thay đổi giữa các phiên bản. Apache Derby xử lý vấn đề này rất thông minh bằng cách cung cấp 2 chế độ nâng cấp: Nâng cấp mềm (Soft Upgrade) và Nâng cấp cứng (Full Upgrade).

2. Nâng cấp mềm (Soft Upgrade) - Chế độ tương thích ngược

Đây là chế độ an toàn và tự động của Derby.

Cách thực hiện: Bạn chỉ cần thay đổi tệp derby.jar cũ bằng tệp derby.jar mới (hoặc đổi version trong pom.xml của Maven) và khởi động lại ứng dụng. KHÔNG thay đổi chuỗi kết nối JDBC.

Cơ chế hoạt động:

Khi Engine mới kết nối vào CSDL cũ, nó sẽ nhận ra định dạng đĩa cứng thuộc về phiên bản cũ.
Nó sẽ chạy ở chế độ Tương thích ngược (Backward-compatibility).
Nó cho phép bạn thực hiện thao tác Đọc/Ghi bình thường mà không làm biến đổi cấu trúc vật lý của tệp dữ liệu.

Ưu và nhược điểm:

Ưu điểm: Nếu phát hiện phiên bản Derby mới bị lỗi không tương thích với ứng dụng Java của bạn, bạn có thể Hạ cấp (Downgrade) lập tức bằng cách lắp lại file .jar cũ. Dữ liệu không hề bị ảnh hưởng.
Nhược điểm: Bạn không thể sử dụng các tính năng SQL mới của phiên bản mới, vì CSDL vẫn bị khóa ở định dạng cũ.

3. Nâng cấp cứng toàn diện (Full Upgrade)

Khi bạn đã kiểm thử kỹ lưỡng và quyết định gắn bó vĩnh viễn với phiên bản Derby mới, bạn cần thực hiện Nâng cấp cứng để chuyển đổi hoàn toàn định dạng tệp tin vật lý trên ổ đĩa.

Cảnh báo sinh tử: Một khi đã thực hiện Full Upgrade, cơ sở dữ liệu đó sẽ KHÔNG BAO GIỜ có thể mở lại bằng các file derby.jar phiên bản cũ được nữa.

Cách thực hiện: Thêm thuộc tính upgrade=true vào chuỗi kết nối JDBC ở lần khởi động đầu tiên với Engine mới:

Plaintext

jdbc:derby:my_company_db;upgrade=true

Ngay khi nhận được lệnh này, Derby sẽ duyệt qua toàn bộ các tệp tin trong thư mục seg0, nâng cấp các cấu trúc từ điển dữ liệu (Data Dictionary), viết lại các header của trang nhớ để chuẩn hóa theo phiên bản mới. Quá trình này có thể mất một khoảng thời gian tùy thuộc vào dung lượng CSDL.

4. Quy trình Nâng cấp / Migration chuẩn công nghiệp

Để đảm bảo không mất mát dữ liệu tài chính hay thông tin quan trọng, mọi lần chuyển đổi phiên bản đều phải tuân thủ nghiêm ngặt 5 bước sau:

Bước 1: Đóng băng hệ thống Đảm bảo không còn bất kỳ client nào đang kết nối. Tắt máy chủ Derby an toàn bằng lệnh shutdown=true (như đã học ở Bài 44).

Bước 2: Sao lưu vật lý (BẮT BUỘC)

Sử dụng thủ tục Backup trực tuyến (SYSCS_BACKUP_DATABASE) trước khi tắt máy.
Hoặc khi máy đã tắt hoàn toàn, copy thư mục cơ sở dữ liệu ra một ổ cứng dự phòng. Đây là phao cứu sinh duy nhất nếu Full Upgrade bị lỗi giữa chừng do cúp điện.

Bước 3: Thay thế thư viện (Binaries) Cập nhật file .jar của Derby trên máy chủ hoặc cập nhật version trong pom.xml.

Bước 4: Kích hoạt nâng cấp cứng Viết một đoạn script Java nhỏ chạy một lần duy nhất để thực thi việc nâng cấp:

Java

public class DerbyUpgrader {
    public static void main(String[] args) {
        String upgradeUrl = "jdbc:derby://localhost:1527/my_company_db;upgrade=true";
        try (Connection conn = DriverManager.getConnection(upgradeUrl, "admin", "password")) {
            System.out.println("Nâng cấp CSDL lên phiên bản mới thành công!");
        } catch (SQLException e) {
            e.printStackTrace();
        }
    }
}

Bước 5: Xóa thuộc tính upgrade=true Sau khi nâng cấp thành công, ở các lần chạy ứng dụng tiếp theo, hãy xóa bỏ upgrade=true khỏi chuỗi kết nối để hệ thống trở về trạng thái vận hành bình thường.

5. Migration cấu trúc bảng với Flyway (Database Versioning)

"Migration" không chỉ là nâng cấp Engine của Derby, mà thường xuyên hơn, nó là việc thay đổi cấu trúc bảng (Schema). Ví dụ: Phiên bản 1.0 của ứng dụng có bảng NhanVien, nhưng phiên bản 2.0 cần thêm cột so_dien_thoai.

Trong Spring Boot (Bài 42), thay vì dùng hibernate.ddl-auto=update (rất rủi ro trên Production vì nó có thể tự động xóa cột), các Backend Developer chuyên nghiệp luôn sử dụng công cụ quản lý phiên bản CSDL như Flyway hoặc Liquibase.

Tích hợp Flyway cho Derby trong Spring Boot:

Khai báo thư viện flyway-core trong pom.xml.
Tạo thư mục src/main/resources/db/migration.
Tạo các file SQL chứa lệnh thay đổi, đánh số thứ tự nghiêm ngặt:
- V1__Tao_bang_nhan_vien.sql (Chứa lệnh CREATE TABLE)
- V2__Them_cot_so_dien_thoai.sql (Chứa lệnh ALTER TABLE nhan_vien ADD COLUMN so_dien_thoai VARCHAR(15))

Khi Spring Boot khởi động, Flyway sẽ kết nối vào Derby, kiểm tra xem CSDL đang ở version mấy. Nếu nó đang ở V1, Flyway sẽ tự động chạy file V2.sql để cập nhật bảng. Bằng cách này, mọi thay đổi về dữ liệu và cấu trúc đều được đồng bộ hoàn hảo với phiên bản mã nguồn Java của bạn.

6. Tổng kết

Nâng cấp cơ sở dữ liệu là tác vụ rủi ro cao. Luôn luôn Backup trước khi thực hiện.
Soft Upgrade: Đổi .jar, giữ nguyên URL. An toàn, tương thích ngược, có thể hạ cấp.
Full Upgrade: Đổi .jar, thêm upgrade=true. Kích hoạt tính năng mới nhưng không thể quay đầu.
Để quản lý sự thay đổi của các cột và bảng qua từng phiên bản ứng dụng, hãy tích hợp công cụ Migration như Flyway thay vì sửa CSDL thủ công.

Sau khi hệ thống đã hoạt động ổn định và có thể tự động nâng cấp, thách thức cuối cùng của một kỹ sư Backend là làm sao để hệ thống vẫn sống sót ngay cả khi máy chủ vật lý bị cháy hoặc mất kết nối mạng. Bài tiếp theo sẽ giải quyết vấn đề đó: Apache Derby Bài 49: Kiến trúc High Availability (HA) và Cơ chế Replication (Nhân bản dữ liệu).

Apache