Oracle CDC 3 — Oracle GoldenGate: Kiến trúc & Khái niệm

Oracle GoldenGate là gì

Oracle GoldenGate (GG) là một nền tảng sao chép và tích hợp dữ liệu theo cơ chế log-based CDC (Change Data Capture dựa trên nhật ký giao dịch). Thay vì truy vấn trực tiếp các bảng nguồn hay dùng trigger, GoldenGate đọc redo log / archived redo log của cơ sở dữ liệu nguồn để trích xuất các thay đổi (INSERT/UPDATE/DELETE và cả DDL), rồi vận chuyển và áp dụng chúng vào một hoặc nhiều đích với độ trễ rất thấp (near-real-time, thường ở mức giây hoặc dưới giây).

Ba đặc điểm cốt lõi làm nên giá trị của GoldenGate:

• Log-based, non-intrusive: capture từ redo log nên gần như không thêm tải lên các giao dịch nghiệp vụ trên nguồn (không cần trigger, không lock bảng nghiệp vụ).
• Đa nền tảng (heterogeneous): nguồn và đích có thể khác loại database — ví dụ Oracle sang Oracle, Oracle sang PostgreSQL/SQL Server/DB2, hoặc sang các đích non-RDBMS như Kafka, HDFS. GoldenGate chuẩn hoá thay đổi vào một định dạng trung gian độc lập nền tảng (trail).
• Near-real-time & giao dịch nhất quán: dữ liệu được áp dụng theo thứ tự cam kết (commit order), giữ tính toàn vẹn giao dịch, phù hợp cho HA/DR, migration không downtime, đồng bộ hai chiều và cấp dữ liệu cho hệ phân tích.

Lưu ý quan trọng ngay từ đầu: GoldenGate là sản phẩm thương mại tính phí (licensed). Đây không phải công cụ miễn phí đi kèm database. Chi tiết license được bàn ở cuối bài.

Các thành phần cốt lõi

Dù triển khai theo kiến trúc nào (Classic hay Microservices), luồng dữ liệu logic của GoldenGate luôn gồm bốn khối chức năng: capture (Extract) → trail → vận chuyển (Distribution/Pump) → apply (Replicat), có thêm thành phần điều phối/quản lý.

Extract — capture thay đổi từ nguồn

Extract là tiến trình chạy trên (hoặc gần) hệ thống nguồn, chịu trách nhiệm đọc thay đổi từ transaction log và ghi ra trail. Extract có thể chạy ở nhiều chế độ; hai loại quan trọng nhất với Oracle là:

• Classic Extract: Extract tự đọc redo/archived redo log ở mức file, tự parse cấu trúc log. Đây là cơ chế cũ, bị hạn chế với các tính năng Oracle hiện đại (compression, TDE, multitenant/CDB-PDB) và đã bị deprecated/loại bỏ cho nguồn Oracle ở các phiên bản gần đây.
• Integrated Extract: Extract tương tác với một logmining server chạy bên trong instance database nguồn (dùng hạ tầng LogMiner của Oracle). Database sẽ chủ động khai thác redo và trả về các bản ghi thay đổi dưới dạng LCR (Logical Change Record) cho Extract. Integrated Extract là chế độ khuyến nghị cho nguồn Oracle vì hỗ trợ đầy đủ nén, mã hoá, RAC, CDB/PDB và bám sát các thay đổi format redo theo phiên bản.

Extract cần bật supplemental logging ở mức database và/hoặc bảng để redo chứa đủ thông tin định danh hàng (key columns) phục vụ việc dựng lại câu lệnh apply ở đích.

Trail files — định dạng trung gian

Trail là chuỗi file chứa các bản ghi thay đổi ở định dạng nhị phân trung gian, độc lập nền tảng của GoldenGate (canonical format). Trail tách rời quá trình capture khỏi quá trình apply, cho phép:

• Đệm dữ liệu khi mạng hoặc đích tạm gián đoạn (buffering, độ bền).
• Chuyển đổi dị nền — vì trail không phụ thuộc loại database cụ thể.
• Nhiều tiến trình đọc lại cùng nguồn thay đổi.

Có hai vị trí trail thường gặp:

• Local trail (source trail): Extract ghi ra ngay trên hệ thống nguồn.
• Remote trail (target trail): bản trail được đẩy sang hệ thống đích, nơi Replicat đọc để apply.

Mỗi file trail có tên gồm tiền tố hai ký tự và số thứ tự (ví dụ aa000000, aa000001...), tự động cuộn (rollover) khi đạt kích thước cấu hình.

Distribution / Pump — vận chuyển trail qua mạng

Thành phần này đọc local trail và gửi dữ liệu qua mạng tới hệ thống đích, ghi vào remote trail.

• Trong Classic Architecture, đây là một Extract chạy chế độ đặc biệt gọi là Data Pump (một Extract phụ không capture từ log mà chỉ đọc trail và đẩy đi).
• Trong Microservices Architecture (MA), chức năng này do Distribution Service đảm nhiệm, dùng các giao thức mạng hiện đại (ví dụ đường ống dựa trên HTTP/WebSocket, hỗ trợ TLS) thay cho cấu hình TCP thủ công.

Vai trò của lớp này: cách ly nguồn khỏi sự cố mạng/đích, cho phép lọc/định tuyến, và tập trung việc mã hoá đường truyền.

Replicat — apply vào đích

Replicat đọc remote trail và áp dụng thay đổi vào database đích theo đúng thứ tự cam kết. Có nhiều biến thể tối ưu cho song song hoá và tính toàn vẹn:

• Classic Replicat: apply tuần tự bằng một luồng, SQL sinh ra qua đường dữ liệu thông thường. Đơn giản nhưng thông lượng thấp và khó bắt kịp tải cao.
• Coordinated Replicat: một Replicat điều phối chia công việc cho nhiều luồng (thread) theo các nhóm phân vùng do người dùng định nghĩa (ví dụ theo bảng/ range). Người vận hành phải tự lo tránh xung đột phụ thuộc giữa các thread.
• Integrated Replicat: Replicat gửi các LCR tới một inbound server (apply engine) bên trong database đích Oracle. Database tự phân tích phụ thuộc giữa các giao dịch và tự động áp dụng song song mà vẫn bảo đảm thứ tự, tận dụng tối ưu nội bộ của Oracle.
• Parallel Replicat: chia việc thành các thành phần mapper/master/applier, tự động phát hiện phụ thuộc và apply song song, có cơ chế read-ahead trên trail. Có hai kiểu: non-integrated (apply qua đường SQL thông thường, dùng được cho cả đích non-Oracle trong một số cấu hình) và integrated (kết hợp inbound server). Parallel Replicat là hướng khuyến nghị hiện đại vì cân bằng thông lượng cao và tự động hoá xử lý phụ thuộc.

Manager (Classic)

Trong Classic Architecture, Manager (MGR) là tiến trình điều khiển trung tâm trên mỗi cài đặt GoldenGate: khởi động/giám sát Extract và Replicat, phân bổ port, quản lý vòng đời trail (purge trail cũ theo chính sách), báo lỗi. Trong Microservices Architecture, vai trò điều khiển này được thay thế và mở rộng bởi các service (đặc biệt là Service Manager).

Bảng các loại Extract và Replicat

Loại	Vai trò	Cơ chế	Ghi chú
Classic Extract	Capture	Tự đọc redo log ở mức file	Cũ, deprecated cho nguồn Oracle
Integrated Extract	Capture	Dùng logmining server trong DB, nhận LCR	Khuyến nghị cho nguồn Oracle; hỗ trợ CDB/PDB, RAC, TDE
Data Pump (Classic)	Vận chuyển	Extract phụ đọc trail và đẩy qua mạng	Được thay bằng Distribution Service ở MA
Classic Replicat	Apply	Một luồng, tuần tự	Thông lượng thấp
Coordinated Replicat	Apply	Nhiều thread theo phân vùng người dùng định nghĩa	Phải tự tránh xung đột phụ thuộc
Integrated Replicat	Apply	Gửi LCR tới inbound server trong DB đích	Song song hoá tự động, chỉ cho đích Oracle
Parallel Replicat	Apply	Mapper/applier, tự phát hiện phụ thuộc, read-ahead	Hiện đại; có biến thể integrated và non-integrated

Microservices Architecture (MA) so với Classic Architecture

GoldenGate hỗ trợ hai kiểu triển khai. Classic Architecture (CA) là mô hình truyền thống dựa trên tiến trình + tiện ích dòng lệnh GGSCI và tiến trình Manager. Microservices Architecture (MA) là kiến trúc hiện đại dựa trên các dịch vụ REST/HTTP, có giao diện web và công cụ dòng lệnh adminclient. Oracle khuyến nghị MA cho các triển khai mới.

Các thành phần chính trong MA:

• Service Manager: điểm vào và giám sát toàn cục của một cài đặt; quản lý vòng đời các deployment và các service con, đóng vai trò watchdog.
• Administration Service: điều phối quản trị — tạo/khởi động/dừng các Extract và Replicat, quản lý cấu hình; là "não" quản trị thay cho GGSCI+Manager.
• Distribution Service: đẩy trail từ nguồn sang đích qua các giao thức mạng bảo mật (thay cho Data Pump).
• Receiver Service: đầu nhận ở phía đích, tiếp nhận luồng trail do Distribution Service gửi tới và ghi vào remote trail.
• Performance Metrics Service (PMSRVR): thu thập và phơi bày số liệu hiệu năng/giám sát cho các tiến trình.
• Web UI + adminclient: cổng web quản trị và CLI, giao tiếp với các service qua REST.

Bảng so sánh Classic vs Microservices

Tiêu chí	Classic Architecture	Microservices Architecture
Điều khiển trung tâm	Tiến trình Manager (MGR)	Service Manager
Quản trị	GGSCI (CLI)	Administration Service + Web UI + adminclient
Vận chuyển trail	Data Pump (Extract phụ)	Distribution Service + Receiver Service
Giao tiếp mạng	TCP cấu hình thủ công	REST/HTTP, hỗ trợ TLS, reverse proxy
Giám sát hiệu năng	Rời rạc theo tiến trình	Performance Metrics Service tập trung
Quản trị từ xa	Hạn chế	Thiết kế cho remote/nhiều deployment
Khuyến nghị	Legacy	Khuyến nghị cho triển khai mới

Điểm cần nhấn mạnh: luồng dữ liệu logic không đổi giữa hai kiến trúc — vẫn là Extract → trail → vận chuyển → Replicat. MA chỉ thay đổi cách các tiến trình đó được quản lý, giám sát và giao tiếp (dịch vụ hoá, bảo mật hoá, quản lý từ xa).

Checkpoint và recovery

Cơ chế checkpoint là nền tảng cho tính bền vững và khả năng khôi phục của GoldenGate. Mỗi tiến trình ghi lại vị trí đã xử lý:

• Extract ghi checkpoint vị trí đã đọc trong redo (theo SCN/RBA) và vị trí đã ghi vào trail. Khi khởi động lại, Extract tiếp tục từ đúng điểm dừng, không bỏ sót thay đổi.
• Replicat ghi checkpoint vị trí đã đọc/áp dụng trong trail. Với Replicat, checkpoint có thể được lưu trong checkpoint table ở database đích để phối hợp checkpoint với chính giao dịch apply, bảo đảm exactly-once (không apply trùng, không mất) khi phục hồi sau sự cố.

Nhờ trail (dữ liệu đã bền hoá) + checkpoint (vị trí đã bền hoá), một tiến trình dừng đột ngột có thể khởi động lại và resume chính xác. Đây là lý do GoldenGate thích hợp cho các luồng đồng bộ liên tục dài hạn.

Replication DDL

Ngoài thay đổi dữ liệu (DML), GoldenGate có thể sao chép cả thay đổi cấu trúc (DDL) như CREATE/ALTER/DROP TABLE, tạo index, v.v. Điều này giúp schema ở đích bám theo nguồn mà không cần can thiệp thủ công. Với nguồn Oracle dùng Integrated Extract, việc capture DDL được tích hợp qua hạ tầng logmining; người dùng cấu hình phạm vi DDL cần bắt (theo object, theo loại lệnh) và có thể áp dụng quy tắc ánh xạ/lọc. Cần cân nhắc: replication DDL hữu ích cho môi trường đồng nhất, nhưng khi nguồn và đích khác loại database (heterogeneous) thì DDL thường không tương thích trực tiếp và hay bị vô hiệu hoá, thay bằng quản lý schema tách biệt.

GoldenGate for Big Data — đích không phải RDBMS

Ngoài phiên bản cho database quan hệ, Oracle có dòng GoldenGate for Big Data (và các bộ adapter/Stream Analytics liên quan) cho phép apply vào đích không phải RDBMS. Ở đây, thay cho Replicat apply SQL vào database, GoldenGate dùng các handler/adapter để đẩy thay đổi tới:

• Apache Kafka (mỗi thay đổi thành message/event, thường theo format JSON/Avro; hữu ích cho kiến trúc event-driven và streaming ETL).
• HDFS, object store, và các hệ phân tán khác (ghi file thay đổi để nạp vào data lake/warehouse).
• Nhiều đích big data/analytics khác qua adapter tương ứng.

Phần capture (Extract từ redo Oracle) vẫn giữ nguyên; điểm khác nằm ở phía apply — biến các LCR/trail record thành sự kiện hoặc file cho hệ đích. Đây là cầu nối phổ biến giữa CDC trên OLTP truyền thống và nền tảng dữ liệu hiện đại.

Topology thường gặp

GoldenGate hỗ trợ nhiều mô hình triển khai:

• Unidirectional (một chiều): nguồn → đích. Dùng cho DR/standby báo cáo, feed data warehouse, offload đọc. Đơn giản và phổ biến nhất.
• Bidirectional (hai chiều / active-active): hai site đều ghi và đồng bộ cho nhau. Cần cơ chế loop detection (tránh dội ngược thay đổi) và chiến lược conflict detection & resolution (CDR) khi cùng một hàng bị sửa ở cả hai bên.
• Hub / consolidation / broadcast: một nguồn phân phát cho nhiều đích (broadcast) hoặc nhiều nguồn gom về một đích (consolidation), hoặc mô hình hub trung tâm định tuyến giữa nhiều site. Distribution/Receiver Service ở MA giúp mô hình hub sạch sẽ hơn.

Việc chọn topology quyết định độ phức tạp cấu hình (đặc biệt là loop detection và CDR trong active-active) và yêu cầu hạ tầng mạng.

Vấn đề license

Cần nêu rõ để tránh ngộ nhận khi lập kế hoạch dự án:

• GoldenGate là sản phẩm thương mại, tính phí riêng — không nằm trong license database mặc định và không miễn phí như một số công cụ CDC nguồn mở.
• License thường tính theo processor/core và tách theo cạnh nguồn và đích; các dòng như GoldenGate for Big Data, GoldenGate for Oracle vs non-Oracle có thể có điều khoản khác nhau.
• Vì chi phí đáng kể, khi đánh giá giải pháp CDC cần cân nhắc GoldenGate so với các lựa chọn khác (ví dụ Debezium/Kafka Connect nguồn mở, hoặc dịch vụ CDC quản lý trên cloud) dựa trên yêu cầu về heterogeneity, độ trễ, quy mô giao dịch và ngân sách.

Bài viết này mô tả khái niệm kiến trúc; luôn tra cứu tài liệu và bảng giá chính thức của Oracle cho phiên bản cụ thể trước khi ra quyết định mua và triển khai.

Tóm tắt

Oracle GoldenGate thực hiện CDC log-based, đa nền tảng, near-real-time qua bốn khối logic: Extract capture từ redo (khuyến nghị dùng Integrated Extract với logmining server), trail làm định dạng trung gian bền và độc lập nền tảng, lớp Distribution/Data Pump vận chuyển qua mạng, và Replicat apply vào đích (với các biến thể classic, coordinated, integrated, và parallel hiện đại). Classic Architecture dùng Manager + GGSCI, còn Microservices Architecture dịch vụ hoá bằng Service Manager, Administration/Distribution/Receiver/Performance Metrics Service cùng Web UI + adminclient — cùng luồng dữ liệu nhưng quản trị và bảo mật tốt hơn. Checkpoint + trail cho phép resume chính xác; GG còn hỗ trợ DDL replication, dòng GoldenGate for Big Data cho đích như Kafka/HDFS, và nhiều topology (unidirectional, bidirectional, hub). Cuối cùng, GoldenGate là sản phẩm tính phí, cần cân nhắc license khi thiết kế giải pháp.

Tự kiểm tra

1. Phân biệt Classic Extract và Integrated Extract: mỗi loại đọc thay đổi từ đâu, và tại sao Integrated Extract được khuyến nghị cho nguồn Oracle hiện đại?
2. Vì sao trail file được thiết kế ở định dạng trung gian độc lập nền tảng, và điều đó giúp gì cho việc sao chép dị nền (heterogeneous)?
3. So sánh Integrated Replicat và Parallel Replicat về cách xử lý phụ thuộc giữa giao dịch và khả năng song song hoá.
4. Trong Microservices Architecture, thành phần nào thay thế vai trò của Manager và của Data Pump trong Classic Architecture?
5. Checkpoint và checkpoint table đóng vai trò gì trong việc bảo đảm khôi phục chính xác (exactly-once) khi một Replicat khởi động lại?
6. Khi đích là Apache Kafka thay vì một database quan hệ, phần nào trong luồng GoldenGate thay đổi và phần nào giữ nguyên?

Đọc tiếp

Oracle CDC 4 — Lab GoldenGate