Oracle 7 — RAC, Data Guard & sao lưu (RMAN)

Cho đến giờ trong series Oracle chúng ta đã bàn về một database Oracle đơn lẻ: kiến trúc instance vs database, cách phân vùng và lưu trữ. Nhưng với một hệ thống trọng yếu — điển hình là core banking — thì một máy chủ, dù mạnh đến đâu, vẫn có hai nỗi lo cố hữu: nó có thể chết (đĩa hỏng, mất điện, sập cả data center), và nó chỉ có bấy nhiêu tài nguyên để phục vụ. Oracle giải quyết bài toán này bằng ba trụ cột: RAC cho sẵn sàng cao trong một site, Data Guard cho khắc phục thảm hoạ (DR) sang site khác, và RMAN cho sao lưu/khôi phục. Ghép cả ba lại là MAA (Maximum Availability Architecture).

Lưu ý đọc bài: Sandbox của chúng ta chạy PostgreSQL, nên toàn bộ lệnh RMAN, Data Guard (DGMGRL), SRVCTL và cấu hình dưới đây là (minh hoạ — Oracle, không chạy trong sandbox Postgres). Mục tiêu là hiểu cơ chế và tư duy kiến trúc, không phải để gõ chạy. Ở cuối bài có phần đối chiếu sang mô hình HA của PostgreSQL để bạn nối được bức tranh chung.

Hai chỉ số luôn xuất hiện khi bàn HA/DR: RPO (Recovery Point Objective — chấp nhận mất tối đa bao nhiêu dữ liệu, đo bằng thời gian) và RTO (Recovery Time Objective — mất bao lâu để phục vụ trở lại). Ba trụ cột trên chính là các đòn bẩy để kéo cả RPO lẫn RTO về gần 0.

RAC — nhiều instance, một database

Điểm cốt lõi để hiểu RAC phải quay lại phân biệt instance vs database đã nói ở bài kiến trúc:

• Database = tập hợp file trên đĩa (data files, control files, redo logs) — phần dữ liệu nằm yên.
• Instance = vùng nhớ SGA + các tiến trình nền — phần đang chạy trong RAM/CPU của một máy chủ.

Với Oracle đơn (single-instance), quan hệ là 1–1: một instance phục vụ một database. Real Application Clusters (RAC) phá vỡ điều đó: nhiều instance trên nhiều node vật lý cùng gắn vào một database duy nhất đặt trên shared storage (lưu trữ dùng chung). Storage này thường được quản lý bởi ASM (Automatic Storage Management) — hệ quản lý volume/filesystem chuyên dụng của Oracle — và mọi node đều nhìn thấy cùng các data file.

Cache Fusion — trái tim của RAC

Vấn đề khó nhất của "nhiều instance, một database" là tính nhất quán của bộ nhớ đệm. Mỗi instance có buffer cache riêng trong SGA của nó. Nếu Node 1 vừa sửa một block dữ liệu trong cache của mình, còn Node 2 cần đọc đúng block đó, thì Node 2 phải thấy phiên bản mới nhất — chứ không phải bản cũ trên đĩa, và cũng không được để hai node ghi đè lẫn nhau.

Giải pháp của Oracle là Cache Fusion: thay vì buộc Node 1 ghi block xuống đĩa rồi Node 2 đọc lên (chậm), block được chuyển thẳng từ buffer cache của node này sang node kia qua interconnect — một mạng riêng (private network) tốc độ cao (Ethernet 10/25GbE hoặc InfiniBand) chỉ dành cho giao tiếp nội bộ cụm. Điều phối việc này là hai dịch vụ toàn cục:

• GCS (Global Cache Service) — quản lý sự nhất quán của các block dữ liệu giữa các buffer cache: ai đang giữ bản mới nhất, block đang ở trạng thái nào (shared/exclusive), và chuyển block khi cần.
• GES (Global Enqueue Service) — quản lý các khoá và enqueue toàn cục (ví dụ khoá dòng, khoá đối tượng) trên toàn cụm.

Cùng nhau, GCS + GES giữ coherency (tính mạch lạc) cho cache và lock trên toàn cluster. Interconnect vì thế là thành phần sống còn về hiệu năng: nghẽn interconnect thì cả cụm chậm.

SCAN Listener — một điểm vào duy nhất

Client không cần biết có bao nhiêu node hay node nào còn sống. SCAN (Single Client Access Name) cung cấp một tên/địa chỉ vào duy nhất cho cả cụm. SCAN listener nhìn tải hiện tại của các instance rồi trả về địa chỉ (VIP + port) của local listener phù hợp nhất để client kết nối. Nhờ đó ta có cân bằng tải kết nối và thêm/bớt node mà không phải sửa cấu hình phía client.

RAC cho ta gì — và không cho ta gì

• HA trong site: mất một node, các instance còn lại vẫn phục vụ database. Các session trên node chết sẽ bị đứt, nhưng ứng dụng có thể kết nối lại ngay sang node khác (và với Application Continuity có thể phát lại giao dịch dở dang một cách trong suốt).
• Mở rộng ngang (có giới hạn): thêm node để tăng thông lượng — nhưng đây là scale-out cho compute, mọi node vẫn dùng chung một storage. Khi ứng dụng ghi nóng vào cùng vùng dữ liệu, chi phí đồng bộ Cache Fusion tăng, nên khả năng mở rộng không tuyến tính vô hạn.
• Khác hẳn sharding: RAC không chia nhỏ dữ liệu. Vẫn là một database logic duy nhất; các node chia sẻ cùng dữ liệu chứ không mỗi node giữ một phần. (Muốn chia dữ liệu theo shard, Oracle có sản phẩm riêng là Oracle Sharding.)

Một lệnh quản trị cụm điển hình (qua srvctl) trông như sau:

# (minh hoạ — Oracle, không chạy trong sandbox Postgres)
# Xem trạng thái database RAC trên các instance
srvctl status database -d ORCLCDB

# Khởi động instance trên một node cụ thể
srvctl start instance -d ORCLCDB -i ORCLCDB2

Cảnh báo chi phí & độ phức tạp: RAC không miễn phí về tiền lẫn công sức. Đây là tuỳ chọn có license riêng (đắt), đòi hỏi shared storage tin cậy, mạng interconnect chuyên dụng dư thừa, và kỹ năng vận hành cụm (Grid Infrastructure, ASM, Clusterware). Với nhiều hệ thống, một primary + standby Data Guard đơn giản đã đủ HA; RAC chỉ thực sự đáng khi bạn cần không gián đoạn phục vụ ngay cả khi mất một máy chủ, như core banking.

Data Guard — standby cho khắc phục thảm hoạ

RAC bảo vệ bạn khi mất một node — nhưng nếu cháy cả data center thì shared storage cũng mất theo, RAC bó tay. Đó là lúc cần Data Guard: duy trì một (hoặc nhiều) standby database đặt ở site khác, liên tục đồng bộ redo từ primary.

Cơ chế nền tảng vẫn là redo — nhật ký mọi thay đổi mà Oracle sinh ra trước khi ghi dữ liệu (giống WAL của PostgreSQL). Primary chuyển luồng redo sang standby; standby áp dụng redo đó để giữ mình luôn là bản sao cập nhật.

Physical standby vs Logical standby

• Physical standby — bản sao byte-for-byte của primary. Standby dùng Redo Apply (tiến trình MRP) áp dụng redo y hệt như primary đã làm, nên khối vật lý giống hệt nhau. Đây là lựa chọn phổ biến nhất cho DR vì đơn giản, tin cậy, và bao trùm mọi kiểu dữ liệu. Với option Active Data Guard, physical standby có thể được mở read-only trong khi vẫn đang apply redo — tức bạn tận dụng nó để chạy báo cáo/truy vấn đọc thay vì để nó "ngồi không".
• Logical standby — không copy khối vật lý mà biến redo thành câu lệnh SQL rồi thực thi lại (kỹ thuật SQL Apply). Vì thao tác ở mức logic, standby loại này có thể khác cấu trúc vật lý, có thể mở đọc–ghi cho các đối tượng riêng, thêm index riêng để phục vụ báo cáo. Đổi lại phức tạp hơn và không hỗ trợ mọi kiểu dữ liệu. Lưu ý: switchover sang một logical standby sẽ vô hiệu hoá các physical standby khác, nên khi chọn mục tiêu chuyển vai trò người ta thường ưu tiên physical standby.

Ba chế độ bảo vệ (protection modes)

Điểm đánh đổi cốt lõi của Data Guard là RPO vs hiệu năng/khả dụng của primary, thể hiện qua ba chế độ:

Cốt lõi kỹ thuật nằm ở SYNC vs ASYNC:

• SYNC — tiến trình LGWR trên primary phải chờ xác nhận redo đã được ghi (hoặc nhận) ở standby trước khi báo commit thành công. Đây là chế độ zero data loss, ưu tiên bảo vệ dữ liệu hơn tốc độ; độ trễ mạng giữa hai site sẽ cộng thẳng vào thời gian commit.
• ASYNC — LGWR không chờ; redo được gửi đi nền. Độ trễ hay sự cố phía standby không ảnh hưởng đến khả dụng và hiệu năng của primary, đổi lại có cửa sổ mất mát dữ liệu nếu primary sập đột ngột.

Thực tế đa số hệ chọn Maximum Availability với SYNC tới một standby gần (RPO≈0 nhưng không tự sát primary), đôi khi kèm một standby ASYNC ở xa cho DR địa lý.

Chuyển vai trò: switchover, failover, Fast-Start Failover

• Switchover — đổi vai trò có kế hoạch, không mất dữ liệu: primary hạ xuống standby còn standby lên làm primary. Dùng cho bảo trì (vá OS, nâng cấp phần cứng site chính).
• Failover — chuyển vai trò khi primary hỏng thật sự (thảm hoạ). Standby được thăng cấp làm primary mới. Tuỳ chế độ bảo vệ mà có thể zero data loss hoặc mất một cửa sổ nhỏ.
• Fast-Start Failover (FSFO) — failover tự động do Data Guard Broker điều phối: khi primary được xác định là không còn khả dụng, broker tự chuyển sang standby mục tiêu mà không cần DBA can thiệp, kéo RTO xuống còn hàng chục giây. Một observer độc lập theo dõi cả hai để tránh split-brain. Tại một thời điểm chỉ một standby là mục tiêu failover.

Các thao tác này thường chạy qua DGMGRL (Data Guard Broker command-line):

-- (minh hoạ — Oracle, không chạy trong sandbox Postgres)
DGMGRL> SHOW CONFIGURATION;
DGMGRL> SWITCHOVER TO 'standby_dr';        -- đổi vai trò có kế hoạch
DGMGRL> FAILOVER TO 'standby_dr';           -- khi primary đã hỏng
DGMGRL> SHOW DATABASE 'standby_dr';         -- kiểm tra transport/apply lag

GoldenGate — khi cần replication linh hoạt hơn

Data Guard là replica toàn bộ database, một chiều, cùng phiên bản/nền tảng. Khi cần replication linh hoạt — chọn lọc bảng, đa hướng (active-active), giữa các phiên bản/nền tảng/DBMS khác nhau, hay để tích hợp dữ liệu — Oracle dùng GoldenGate (nền tảng CDC dựa trên đọc redo/transaction log). Đây là chủ đề riêng, xem Kiến trúc GoldenGate trong series Oracle CDC.

RMAN — sao lưu & khôi phục

Replication bảo vệ khỏi mất máy, nhưng không bảo vệ khỏi lỗi logic: một câu DELETE sai, một DROP TABLE nhầm sẽ được nhân bản y nguyên sang standby. Để quay ngược thời gian, ta cần backup. RMAN (Recovery Manager) là công cụ sao lưu/khôi phục tích hợp của Oracle, hiểu cấu trúc bên trong database nên làm được nhiều thứ mà copy file thô không làm được.

Các kiểu backup

• Full / Level 0 — sao lưu toàn bộ block đang dùng của data file. Về nội dung, một incremental level 0 tương đương full và là nền để các incremental sau xây lên.
• Incremental (Level 1) — chỉ sao lưu các block đã thay đổi, gọn và nhanh hơn nhiều. Hai kiểu:
  • Differential — các block đổi kể từ backup level 0 hoặc level 1 gần nhất.
  • Cumulative — các block đổi kể từ backup level 0 gần nhất (backup to hơn nhưng phục hồi nhanh hơn vì cần ít file hơn).
• Image copy — bản sao nguyên vẹn của data file (dạng file, không nén thành backup set), cho phép khôi phục cực nhanh bằng cách "switch to copy". Kết hợp với incremental để rolling forward một image copy luôn cập nhật.

Block Change Tracking — tăng tốc incremental

Bình thường để làm incremental, RMAN phải quét toàn bộ data file tìm block đã đổi — tốn IO. Bật Block Change Tracking (BCT) sẽ tạo một file bitmap ghi lại block nào đã thay đổi kể từ backup trước. Nhờ đó incremental chỉ đọc đúng những block cần, nhanh hơn hẳn trên database lớn (BCT giữ dấu vết đủ cho vài backup gần nhất).

Archived redo & PITR

Muốn khôi phục về một thời điểm bất kỳ chứ không chỉ về lúc backup, ta cần archived redo logs (các online redo log đã được lưu trữ lại). Quy trình PITR (Point-In-Time Recovery): RMAN restore data file từ backup trước thời điểm mục tiêu, rồi recover — cuộn tiến (roll forward) bằng archived redo cho đến đúng điểm cần (theo SCN, số thứ tự log, mốc thời gian, hay một restore point). Đây chính là cách "quay ngược" trước cú DROP TABLE nhầm lúc 10:05 sáng.

# (minh hoạ — Oracle, không chạy trong sandbox Postgres)
rman target /

# Sao lưu incremental level 1 kèm archived redo, có nén
RMAN> BACKUP INCREMENTAL LEVEL 1 DATABASE PLUS ARCHIVELOG;

# Kiểm tra tính hợp lệ của backup mà không thực sự restore
RMAN> RESTORE DATABASE VALIDATE;

# Point-In-Time Recovery: quay database về ngay trước sự cố
RMAN> RUN {
        SET UNTIL TIME "TO_DATE('2026-06-30 10:04:00','YYYY-MM-DD HH24:MI:SS')";
        RESTORE DATABASE;
        RECOVER DATABASE;
      }

Validation & Data Recovery Advisor

• Backup validation — VALIDATE/RESTORE ... VALIDATE cho phép kiểm tra backup có khôi phục được không mà không cần thực sự restore. Backup chưa từng test khôi phục là backup chưa đáng tin.
• Data Recovery Advisor (DRA) — trợ lý chẩn đoán tích hợp: khi có lỗi (mất file, block hỏng…), DRA phát hiện và liệt kê các hư hại, xếp hạng, rồi đề xuất phương án sửa và có thể tự sinh script khôi phục — giảm nguy cơ DBA làm sai lúc khủng hoảng.

MAA — ghép cả ba trụ cột

Maximum Availability Architecture (MAA) là bộ khuyến nghị của Oracle để đạt HA/DR gần như tuyệt đối bằng cách kết hợp:

• RAC — chịu lỗi cấp node trong một site (mất một máy vẫn phục vụ).
• Data Guard — chịu lỗi cấp site (mất cả data center vẫn còn standby ở nơi khác).
• RMAN — chống lỗi logic & hỏng dữ liệu (quay ngược thời gian, sửa block hỏng).

Ba lớp này bù đắp cho loại sự cố mà lớp kia không xử lý được.

Multitenant + HA (nhắc nhanh)

Oracle Multitenant (CDB/PDB) bổ sung thêm một mức linh hoạt: có thể relocate một PDB (di dời pluggable database) sang CDB/instance khác — kể cả gần như online — để tái cân bằng tải hoặc bảo trì mà ít gián đoạn. Kết hợp với RAC/Data Guard, đây là công cụ vận hành hữu ích cho các nền tảng nhiều tenant.

Use case thực tế — MAA cho core banking

Hình dung một ngân hàng chạy core banking trên Oracle. Yêu cầu: RPO = 0 (không được mất giao dịch nào) và RTO vài phút (gián đoạn tối thiểu), 24/7.

Kiến trúc:

• Site chính (DC1): cụm RAC 3 node trên shared storage ASM. Ứng dụng kết nối qua SCAN; nếu một node bảo trì hoặc chết, hai node còn lại tiếp tục phục vụ, session tự kết nối lại — người dùng gần như không nhận ra.
• Site DR (DC2): một physical standby (Active Data Guard) đồng bộ redo ở chế độ Maximum Availability / SYNC từ DC1 → RPO≈0. Standby này còn được mở read-only để gánh các báo cáo cuối ngày, giảm tải cho primary.
• Standby thứ hai ở xa (site địa lý khác): nhận redo ASYNC (Maximum Performance) để chống thảm hoạ diện rộng, chấp nhận RPO nhỏ cho lớp DR ngoài cùng.
• RMAN: backup level 0 hằng tuần + incremental level 1 hằng ngày (bật Block Change Tracking), cộng archive redo liên tục, tất cả đẩy sang lưu trữ tách biệt. Backup được VALIDATE định kỳ.

Kịch bản failover: 2h sáng, DC1 mất điện toàn bộ (mất luôn cụm RAC lẫn storage). Data Guard Broker + observer phát hiện primary không còn khả dụng; Fast-Start Failover tự động thăng cấp physical standby ở DC2 thành primary mới trong vài chục giây — không cần DBA gọi dậy lúc nửa đêm. Vì đang chạy SYNC, RPO = 0: mọi giao dịch đã commit đều còn. Ứng dụng, nhờ trỏ qua tên dịch vụ/observer, kết nối lại sang primary mới. Khi DC1 hồi phục, cụm RAC cũ được reinstate thành standby (Flashback giúp việc này nhanh) và ta có thể switchover có kế hoạch để trả vai trò về DC1 vào giờ thấp điểm.

Kịch bản lỗi logic: 10:05 một job batch chạy sai xoá nhầm dữ liệu — và lỗi này đã nhân bản sang mọi standby. Lúc này Data Guard vô dụng, ta dùng RMAN PITR (hoặc Flashback) khôi phục về 10:04, ngay trước sự cố.

Đối chiếu với PostgreSQL

Bức tranh HA của Oracle ánh xạ khá gọn sang thế giới PostgreSQL, dù triết lý khác nhau:

Khác biệt lớn nhất: PostgreSQL không có tương đương RAC dạng "nhiều node ghi cùng một storage" trong bản chuẩn — HA của Postgres thường là một primary + nhiều replica với công cụ failover ngoài như Patroni. Chi tiết xem Replication & High Availability của PostgreSQL.

Ghi nhớ

• RAC = nhiều instance dùng chung một database trên shared storage (ASM). Cache Fusion chuyển block giữa các buffer cache qua interconnect; GCS/GES giữ nhất quán cache & lock; SCAN là điểm vào duy nhất. Cho HA trong site + scale-out có giới hạn. Không phải sharding — không chia dữ liệu. Đắt và phức tạp.
• Data Guard = standby đồng bộ redo từ primary. Physical (byte-for-byte, Redo Apply, mở đọc = Active Data Guard) vs Logical (SQL Apply, linh hoạt hơn). Ba chế độ: Max Protection / Availability / Performance = đánh đổi giữa RPO và khả dụng primary, cốt lõi là SYNC vs ASYNC.
• Switchover có kế hoạch (không mất dữ liệu) ↔ Failover khi hỏng thật ↔ Fast-Start Failover tự động (Broker + observer, RTO thấp).
• RMAN = backup full/incremental/image copy, Block Change Tracking tăng tốc incremental, archived redo cho PITR, VALIDATE để kiểm tra, Data Recovery Advisor để chẩn đoán/sửa.
• MAA = RAC (lỗi node) + Data Guard (lỗi site) + RMAN (lỗi logic). Ba lớp bù cho nhau.
• Sandbox là PostgreSQL nên các lệnh trên chỉ để hiểu cơ chế; đối chiếu sang replication/HA của PostgreSQL để có bức tranh chung.