Greenplum Database - Bài học 3: Master Node (Coordinator) & Standby Master: Bộ não điều phối truy vấn và quản lý Metadata

Ở Bài học 2, chúng ta đã biết một cụm Greenplum hoạt động theo mô hình "Chỉ huy và Quân đoàn". Trong đó, hàng chục đến hàng trăm Segment phía dưới gánh vác phần nặng nhất là lưu trữ dữ liệu và tính toán cơ bắp. Tuy nhiên, một đội quân hùng hậu sẽ trở nên hỗn loạn nếu thiếu đi người chỉ huy. Đó chính là vai trò của Master Node (từ phiên bản Greenplum 7 trở đi được đổi tên chính thức thành Coordinator Node).

Trong bài học này, chúng ta sẽ giải phẫu chi tiết bên trong Master Node: nó thực sự chứa cái gì, làm cách nào nó giữ được tính toàn vẹn dữ liệu (ACID) trên hàng trăm máy chủ độc lập, và cơ chế dự phòng Standby Master cứu hệ thống thoát khỏi thảm họa "mất não" ra sao.

1. Master Node (Coordinator) thực chất là gì?

Về bản chất vật lý, Master Node cũng chính là một tiến trình cơ sở dữ liệu PostgreSQL đã được chỉnh sửa sâu, chạy trên một máy chủ riêng biệt (Master Host) và lắng nghe kết nối ở cổng mặc định 5432.

Tuy nhiên, điểm khác biệt sống còn giữa Master Node và một PostgreSQL thông thường nằm ở quy tắc bất di bất dịch:

Master Node TUYỆT ĐỐI KHÔNG chứa bất kỳ dữ liệu nghiệp vụ (User Data) nào của các bảng.

Khi bạn chạy lệnh CREATE TABLE orders (...), trên ổ cứng của Master Node có tạo ra file vật lý tương ứng với bảng orders, nhưng dung lượng file đó luôn bằng 0 byte. Toàn bộ hàng tỷ dòng dữ liệu thực tế của bảng orders đều nằm rải rác dưới ổ cứng của các Segment Instances.

Vậy ổ cứng và RAM của Master Node chứa cái gì?

Master Node là nơi lưu trữ Global System Catalog (Kho siêu dữ liệu toàn cục) và Cluster State (Trạng thái cụm):

1. System Catalog chuẩn của PostgreSQL (pg_class, pg_attribute, pg_namespace...): Lưu danh sách các Database, Schema, tên bảng, kiểu dữ liệu các cột, View, Function, User/Role và quyền truy cập.

2. System Catalog đặc thù của Greenplum (gp_segment_configuration, gp_distribution_policy...):

   • Bản đồ địa chỉ IP, Port, thư mục lưu trữ và trạng thái sống/chết của toàn bộ các Primary Segment và Mirror Segment trong cụm.

   • Chính sách phân phối dữ liệu của từng bảng (bảng nào băm theo cột nào, bảng nào Replicated).

3. Thống kê dữ liệu (Data Statistics - pg_statistic): Số lượng dòng ước tính, giá trị lớn nhất/nhỏ nhất, biểu đồ phân bổ dữ liệu (Histogram) để phục vụ việc lập kế hoạch truy vấn.

2. Năm nhiệm vụ cốt lõi của "Bộ não" Master Node

Khi một ứng dụng Backend hoặc công cụ BI kết nối vào Greenplum, nó chỉ nói chuyện duy nhất với Master Node. Master đảm nhận 5 trọng trách:

[ Ứng dụng Client / BI Tool ]
              │
              ▼ (1. Auth & Session)
┌──────────────────────────────────────────────────────────┐
│                 MASTER NODE (COORDINATOR)                │
│                                                          │
│  ┌─────────────────────┐      ┌───────────────────────┐  │
│  │ Global System       │◄────►│ 2. GPORCA Optimizer   │  │
│  │ Catalog (Metadata)  │      │    (Lập Query Plan)   │  │
│  └─────────────────────┘      └───────────┬───────────┘  │
│                                           │              │
│  ┌─────────────────────┐                  ▼              │
│  │ 4. Distributed      │◄────►┌───────────────────────┐  │
│  │    Transaction Mgr  │      │ 3. Query Dispatcher   │  │
│  │    (2PC & GXID)     │      │    (QD Process)       │  │
│  └─────────────────────┘      └───────────┬───────────┘  │
└───────────────────────────────────────────┼──────────────┘
                                            │
              ==============================╪=============== [ Interconnect ]
                     │                      │                      │
                     ▼                      ▼                      ▼
              [ QE - Seg 1 ]         [ QE - Seg 2 ]         [ QE - Seg N ]

2.1. Quản lý kết nối và xác thực (Connection & Authentication)

Master kiểm tra file pg_hba.conf, xác thực tài khoản/mật khẩu và tạo ra một tiến trình phục vụ phiên làm việc đó gọi là QD (Query Dispatcher).

2.2. Tối ưu hóa truy vấn và Lập kế hoạch phân tán (Query Optimization)

Khi nhận câu lệnh SQL, Master tra cứu System Catalog để biết bảng đó nằm ở đâu, có bao nhiêu dòng, được băm theo khóa nào. Sau đó, bộ tối ưu hóa GPORCA trên Master sẽ tính toán hàng ngàn phương án để chọn ra đường đi có chi phí thấp nhất (ít tốn I/O và ít di chuyển dữ liệu qua mạng nhất).

2.3. Điều phối tiến trình thực thi (Query Dispatching - QD vs QE)

• Tiến trình trên Master nhận câu lệnh từ Client được gọi là QD (Query Dispatcher).

• QD sẽ chia nhỏ kế hoạch truy vấn và gửi lệnh qua mạng Interconnect xuống các Segments.

• Tại mỗi Segment, các tiến trình con được sinh ra để trực tiếp đọc đĩa và tính toán theo lệnh của QD, được gọi là QE (Query Executor).

• Khi các QE làm xong việc, QD trên Master sẽ thu thập các mảnh kết quả (Gather Motion), sắp xếp lần cuối (nếu có ORDER BY) và trả về cho Client.

2.4. Quản lý Giao dịch Phân tán (Distributed Transaction Management - 2PC)

Làm thế nào Greenplum đảm bảo tính ACID khi một lệnh INSERT hoặc UPDATE ghi dữ liệu lên 50 máy chủ khác nhau cùng lúc? Nếu 49 máy ghi thành công, nhưng máy thứ 50 bị đầy ổ cứng thì sao?

Master giải quyết bài toán này bằng Global Transaction ID (GXID) kết hợp với giao thức Two-Phase Commit (2PC - Cam kết hai pha):

• Pha 1 (Prepare Phase): Khi bạn gõ COMMIT, Master gửi lệnh "Chuẩn bị Commit nhé!" xuống cả 50 Segments. Mỗi Segment kiểm tra xem mình có ghi xuống WAL (Write-Ahead Log) an toàn chưa. Nếu ổn, nó trả lời "OK". Nếu 1 trong 50 máy báo lỗi, nó trả lời "ABORT".

• Pha 2 (Commit/Rollback Phase):

  • Chỉ khi 100% các Segments tham gia đều trả lời "OK", Master mới phát lệnh "COMMIT THẬT" xuống toàn cụm.

  • Nếu có bất kỳ Segment nào báo lỗi (hoặc mất kết nối), Master lập tức phát lệnh "ROLLBACK" cho tất cả 49 máy còn lại để hủy bỏ thao tác, đảm bảo dữ liệu không bao giờ bị rơi vào trạng thái "nửa nạc nửa mỡ".

2.5. Quản lý câu lệnh DDL (Data Definition Language)

Khi bạn chạy lệnh ALTER TABLE ADD COLUMN... hoặc CREATE INDEX..., bạn chỉ gõ 1 lần trên Master. Master sẽ tự động cập nhật System Catalog của mình, đồng thời đóng vai trò người nhân bản câu lệnh đó gửi xuống bắt tất cả các Segments cùng tạo bảng/cột tương ứng trong một Distributed Transaction.

3. Khám phá thực tế: Bảng hệ thống gp_segment_configuration

Để thấy rõ vai trò quản lý cụm của Master, bảng quan trọng bậc nhất mà mọi kỹ sư làm việc với Greenplum đều phải thuộc lòng là gp_segment_configuration. Bảng này chỉ nằm trên Master:

SQL

SELECT dbid, content, role, preferred_role, mode, status, port, hostname 
FROM gp_segment_configuration 
ORDER BY content, role;

Kết quả trả về sẽ có cấu trúc tương tự như sau:

Cách đọc bảng "bản đồ" này:

• content = -1: Đây là định danh dành riêng cho Master Node và Standby Master (chúng không chứa dữ liệu người dùng nên content mang số âm). Các Segment chứa dữ liệu sẽ được đánh số từ 0, 1, 2... trở đi.

• role & preferred_role: p là Primary (Chính), m là Mirror (Dự phòng).

• mode: s (Synchronized - Đã đồng bộ hoàn toàn), n (Not in sync - Đang lệch dữ liệu).

• status: u (Up - Đang sống khỏe), d (Down - Đã chết).

4. Standby Master: Cơ chế chống "Mất não" (High Availability)

Vì mọi kết nối và toàn bộ bản đồ System Catalog đều nằm ở Master Node, nên nếu máy chủ Master bị cháy nguồn hay hỏng ổ cứng, toàn bộ cụm Greenplum sẽ tê liệt ngay lập tức — dù 100 máy Segment bên dưới vẫn đang sống khỏe mạnh! Hiện tượng này gọi là Single Point of Failure (SPOF - Điểm lỗi đơn).

Để xóa bỏ tử huyệt này, kiến trúc Production của Greenplum luôn bắt buộc phải có Standby Master (hoặc Standby Coordinator) đặt trên một máy chủ vật lý khác hoàn toàn với Master chính.

┌──────────────────────────────┐            ┌──────────────────────────────┐
│      MASTER NODE (Active)    │            │    STANDBY MASTER (Passive)  │
│         Host: mdw            │            │         Host: smdw           │
│                              │            │                              │
│  ┌────────────────────────┐  │            │  ┌────────────────────────┐  │
│  │ System Catalog & Files │  │            │  │ System Catalog & Files │  │
│  └───────────┬────────────┘  │            │  └───────────▲────────────┘  │
│              ▼               │            │              │               │
│  ┌────────────────────────┐  │            │  ┌───────────┴────────────┐  │
│  │      WAL (Nhật ký)     │  │            │  │      WAL Receiver      │  │
│  └───────────┬────────────┘  │            │  │   & Replay Process     │  │
│              │               │            │  └───────────▲────────────┘  │
│              ▼               │            │              │               │
│  ┌────────────────────────┐  │  WAL Stream│              │               │
│  │   WAL Sender Process   ├──┼────────────┼──────────────┘               │
│  └────────────────────────┘  │ (Đồng bộ)  │                              │
└──────────────────────────────┘            └──────────────────────────────┘

Cơ chế đồng bộ giữa Master và Standby Master:

1. WAL Streaming Replication: Vì Master không chứa dữ liệu người dùng, lượng dữ liệu thay đổi trên Master rất nhỏ (chỉ phát sinh khi bạn tạo bảng mới, thêm cột, tạo User hoặc cập nhật Transaction Log).

2. Mọi thay đổi trên System Catalog của Master đều được ghi vào nhật ký WAL (Write-Ahead Log).

3. Tiến trình WAL Sender trên Master sẽ bắn luồng dữ liệu WAL này theo thời gian thực (Synchronous Replication) sang tiến trình WAL Receiver trên máy chủ Standby Master.

4. Standby Master liên tục áp dụng (Replay) các bản ghi WAL này để giữ cho bộ System Catalog của nó giống hệt 100% với Master chính từng giây.

Chuyện gì xảy ra khi Master chính bị sập?

• Ở trạng thái bình thường, Standby Master ở chế độ Warm Standby (Thụ động) — nghĩa là nó không nhận kết nối truy vấn từ người dùng mà chỉ âm thầm nhận bản sao WAL từ Master.

• Khi máy chủ Master chính gặp sự cố phần cứng và chết hẳn, quản trị viên (hoặc công cụ tự động hóa HA như Keepalived/Pacemaker) sẽ kích hoạt lệnh gpactivatestandby trên máy Standby.

• Ngay lập tức, Standby Master ngắt chế độ nhận WAL, tự thăng cấp mình lên thành Primary Master mới, tiếp quản toàn bộ quyền chỉ huy các Segments. Ứng dụng Backend chỉ cần trỏ sang IP của Master mới (hoặc thông qua Virtual IP - VIP) là hệ thống hoạt động trở lại bình thường mà không mất một byte dữ liệu nào!

5. Lưu ý thực chiến cho Kỹ sư Hệ thống

Vì Master là "cổ chai" duy nhất mà mọi câu lệnh đều phải đi qua, hãy luôn ghi nhớ 3 nguyên tắc vàng để bảo vệ Master Node:

1. Không kéo hàng triệu dòng dữ liệu thô về Master: Nếu bạn chạy lệnh SELECT * FROM billion_rows_table mà không có LIMIT hay GROUP BY, toàn bộ 100 Segments sẽ bơm hàng tỷ dòng qua mạng dồn về một mình cổng mạng của Master để trả cho Client, gây nghẽn mạng và tràn RAM Master ngay lập tức. (Để xuất/nhập dữ liệu lớn, ta sẽ dùng gpfdist hoặc PXF ở Phần 3).

2. Dùng Connection Pooler (PgBouncer): Mỗi kết nối mở vào Master sẽ khiến Master phải đẻ ra các tiến trình con trên toàn bộ các Segments. Nếu ứng dụng Backend mở 1.000 kết nối trực tiếp vào Master trên cụm có 50 Segments, hệ thống sẽ phải gánh tới 1.000 * 50 = 50.000 tiến trình nhàn rỗi! Hãy luôn đặt PgBouncer trước Master Node.

3. Không cài chung các ứng dụng nặng (BI Server, Airflow, Kafka) lên máy chủ Master: Hãy để dành toàn bộ CPU và RAM của Master cho việc lập kế hoạch truy vấn (GPORCA) và điều phối kết quả.

Tóm tắt Bài học 3

• Master Node (Coordinator) là cổng giao tiếp duy nhất với Client, chỉ lưu trữ System Catalog (Metadata) và hoàn toàn không chứa dữ liệu người dùng.

• Master sử dụng bộ tối ưu GPORCA để lập kế hoạch, dùng tiến trình QD (Query Dispatcher) để giao việc cho các QE (Query Executor) dưới Segment, và dùng cơ chế Two-Phase Commit (2PC) để đảm bảo tính toàn vẹn giao dịch (ACID) toàn cụm.

• Bảng hệ thống gp_segment_configuration trên Master là nơi theo dõi toàn bộ sức khỏe và vai trò của từng Node trong cụm (Master có content = -1).

• Standby Master luôn đồng bộ Metadata theo thời gian thực với Master chính thông qua WAL Streaming Replication, sẵn sàng tiếp quản quyền chỉ huy khi Master chính gặp sự cố phần cứng.

Ở bài học tiếp theo (Bài học 4), chúng ta sẽ xuống dưới tầng "cơ bắp" của cụm: Segment Instances (Primary & Mirror) để khám phá nơi dữ liệu thực sự sinh sống, cách bố trí các cặp Primary - Mirror chéo nhau giữa các máy chủ vật lý để dù cháy cả một server thì cụm Greenplum vẫn chạy tiếp mà không hề hấn gì.