Thiết Lập Master – Slave PostgreSQL: Hướng Dẫn Chi Tiết A-Z

PostgreSQL, một trong những hệ quản trị cơ sở dữ liệu quan hệ mã nguồn mở mạnh mẽ nhất, thường được sử dụng trong các ứng dụng quan trọng, nơi tính sẵn sàng và khả năng phục hồi dữ liệu là yếu tố then chốt. Việc thiết lập kiến trúc Master – Slave PostgreSQL là một giải pháp hiệu quả để đạt được điều này. Bài viết này sẽ cung cấp một hướng dẫn chi tiết, từ A đến Z, về cách thiết lập kiến trúc này, giúp bạn đảm bảo dữ liệu luôn an toàn và hệ thống hoạt động ổn định.

Vì Sao Cần Thiết Lập Master – Slave PostgreSQL?

Trước khi đi sâu vào các bước thiết lập, hãy cùng tìm hiểu lý do tại sao kiến trúc Master – Slave lại quan trọng đến vậy. Trong môi trường sản xuất, việc mất dữ liệu hoặc thời gian chết của hệ thống có thể gây ra hậu quả nghiêm trọng. Kiến trúc Master – Slave giúp giảm thiểu rủi ro này bằng cách:

  • Tăng tính sẵn sàng: Khi máy chủ Master gặp sự cố, máy chủ Slave có thể nhanh chóng được nâng cấp thành Master, đảm bảo hệ thống tiếp tục hoạt động.
  • Cải thiện hiệu suất: Máy chủ Slave có thể được sử dụng để đọc dữ liệu, giảm tải cho máy chủ Master, đặc biệt hữu ích trong các ứng dụng có nhiều truy vấn đọc.
  • Sao lưu và phục hồi: Máy chủ Slave cung cấp một bản sao dữ liệu gần như thời gian thực, giúp việc sao lưu và phục hồi dữ liệu trở nên dễ dàng hơn.
  • Bảo vệ dữ liệu: Ngay cả khi có sự cố vật lý hoặc lỗi logic trên máy chủ Master, dữ liệu vẫn được an toàn trên máy chủ Slave.

Hiểu Rõ Kiến Trúc Master – Slave PostgreSQL

Kiến trúc Master – Slave PostgreSQL, còn được gọi là replication, hoạt động dựa trên nguyên tắc:

  • Master (Primary): Là máy chủ chính, nơi tất cả các thao tác ghi (INSERT, UPDATE, DELETE) được thực hiện.
  • Slave (Standby/Replica): Là máy chủ sao lưu, nhận dữ liệu từ máy chủ Master và áp dụng các thay đổi để đồng bộ hóa dữ liệu.

Có hai loại replication chính:

  • Asynchronous Replication: Máy chủ Master không đợi xác nhận từ máy chủ Slave trước khi hoàn thành một giao dịch. Điều này có nghĩa là có thể có một khoảng thời gian nhỏ dữ liệu chưa được đồng bộ hóa, nhưng hiệu suất của máy chủ Master được cải thiện.
  • Synchronous Replication: Máy chủ Master đợi xác nhận từ ít nhất một máy chủ Slave trước khi hoàn thành một giao dịch. Điều này đảm bảo dữ liệu luôn được đồng bộ hóa giữa các máy chủ, nhưng có thể ảnh hưởng đến hiệu suất của máy chủ Master.

Trong hướng dẫn này, chúng ta sẽ tập trung vào Asynchronous Replication vì nó phổ biến và dễ cấu hình hơn. Tuy nhiên, các nguyên tắc cơ bản có thể áp dụng cho cả hai loại.

Chuẩn Bị Môi Trường

Trước khi bắt đầu, bạn cần chuẩn bị môi trường sau:

  1. Hai máy chủ: Cần có hai máy chủ riêng biệt, một cho Master và một cho Slave. Đảm bảo cả hai máy chủ đều đáp ứng các yêu cầu phần cứng và phần mềm tối thiểu của PostgreSQL.
  2. Hệ điều hành: Chọn hệ điều hành phù hợp (ví dụ: Ubuntu, CentOS, Debian). Các hướng dẫn sau đây sẽ dựa trên Ubuntu Server.
  3. PostgreSQL: Cài đặt cùng phiên bản PostgreSQL trên cả hai máy chủ. Đảm bảo rằng PostgreSQL đã được cấu hình và hoạt động bình thường.
  4. Mạng: Cả hai máy chủ phải kết nối được với nhau qua mạng. Đảm bảo rằng tường lửa không chặn các kết nối giữa hai máy chủ trên cổng PostgreSQL (mặc định là 5432).
  5. Quyền truy cập: Cần có quyền truy cập root hoặc sudo trên cả hai máy chủ.

Cấu Hình Máy Chủ Master (Primary)

Bây giờ, chúng ta sẽ bắt đầu cấu hình máy chủ Master.

Bước 1: Chỉnh Sửa File postgresql.conf

Mở file postgresql.conf bằng trình soạn thảo văn bản yêu thích của bạn. Vị trí của file này có thể khác nhau tùy thuộc vào hệ điều hành và phiên bản PostgreSQL. Thông thường, nó nằm ở /etc/postgresql/<version>/main/postgresql.conf.

Tìm và chỉnh sửa các dòng sau:

listen_addresses = '*'  # Cho phép kết nối từ bất kỳ địa chỉ IP nào.  Có thể thay đổi thành địa chỉ IP cụ thể để bảo mật hơn.
wal_level = replica       # Bật WAL archiving (Write-Ahead Logging)
archive_mode = on        # Bật chế độ lưu trữ WAL
archive_command = 'cp %p /path/to/archive/%f' # Lệnh lưu trữ WAL files.  Thay '/path/to/archive' bằng đường dẫn thư mục lưu trữ WAL.
max_wal_senders = 10     # Số lượng tối đa các kết nối đồng thời từ các máy chủ Slave.
wal_keep_size = 2GB       # Dung lượng WAL tối thiểu giữ lại trên Master.

Giải thích:

  • listen_addresses: Xác định địa chỉ IP mà PostgreSQL sẽ lắng nghe kết nối. '*' có nghĩa là lắng nghe trên tất cả các giao diện mạng.
  • wal_level: Xác định mức độ WAL (Write-Ahead Logging). replica là mức cần thiết cho replication.
  • archive_mode: Bật chế độ lưu trữ WAL files, cần thiết cho việc phục hồi điểm thời gian (Point-in-Time Recovery – PITR) và replication.
  • archive_command: Xác định lệnh để lưu trữ WAL files. Trong ví dụ trên, chúng ta sử dụng lệnh cp để sao chép các WAL files vào thư mục /path/to/archive. Hãy nhớ thay đổi đường dẫn này thành một đường dẫn hợp lệ trên hệ thống của bạn.
  • max_wal_senders: Xác định số lượng tối đa các kết nối đồng thời từ các máy chủ Slave. Điều chỉnh số này dựa trên số lượng Slave bạn có.
  • wal_keep_size: Xác định dung lượng tối thiểu của các WAL files cần giữ lại trên Master. Điều này đảm bảo rằng Slave có thể bắt kịp nếu nó bị tụt lại phía sau.

Lưu ý: Hãy thay đổi /path/to/archive thành một đường dẫn hợp lệ trên hệ thống của bạn. Bạn có thể tạo một thư mục mới, ví dụ: /var/lib/postgresql/<version>/main/archive.

Bước 2: Chỉnh Sửa File pg_hba.conf

File pg_hba.conf kiểm soát quyền truy cập của client vào cơ sở dữ liệu. Mở file này (thường nằm ở /etc/postgresql/<version>/main/pg_hba.conf) và thêm dòng sau để cho phép máy chủ Slave kết nối:

host    replication     all             <slave_ip_address>/32         md5

Giải thích:

  • host: Xác định rằng chúng ta đang cấu hình quyền truy cập cho các kết nối TCP/IP.
  • replication: Xác định rằng quy tắc này áp dụng cho các kết nối replication.
  • all: Xác định rằng quy tắc này áp dụng cho tất cả các user.
  • <slave_ip_address>/32: Thay thế bằng địa chỉ IP của máy chủ Slave. /32 chỉ định rằng chỉ địa chỉ IP cụ thể này mới được phép kết nối.
  • md5: Xác định phương thức xác thực. Trong trường hợp này, chúng ta sử dụng xác thực MD5, yêu cầu mật khẩu.

Quan trọng: Thay thế <slave_ip_address> bằng địa chỉ IP thực tế của máy chủ Slave của bạn. Nếu bạn có nhiều máy chủ Slave, hãy thêm một dòng riêng biệt cho mỗi máy chủ.

Bước 3: Tạo User Replication

Tạo một user dành riêng cho replication. Kết nối với cơ sở dữ liệu PostgreSQL bằng user postgres:

sudo -u postgres psql

Sau đó, chạy lệnh sau để tạo user:

CREATE ROLE replicator WITH REPLICATION LOGIN PASSWORD '<password>';

Giải thích:

  • CREATE ROLE replicator: Tạo một role mới có tên là replicator. Bạn có thể chọn một tên khác nếu muốn.
  • WITH REPLICATION: Cấp quyền REPLICATION cho role này, cho phép nó kết nối để thực hiện replication.
  • LOGIN: Cho phép role này đăng nhập vào cơ sở dữ liệu.
  • PASSWORD '<password>': Đặt mật khẩu cho role này. Thay thế <password> bằng một mật khẩu mạnh.

Quan trọng: Hãy nhớ thay thế <password> bằng một mật khẩu mạnh và ghi lại mật khẩu này, bạn sẽ cần nó sau này.

Bước 4: Khởi Động Lại PostgreSQL

Sau khi thực hiện các thay đổi, hãy khởi động lại PostgreSQL để áp dụng chúng:

sudo systemctl restart postgresql

Cấu Hình Máy Chủ Slave (Standby/Replica)

Bây giờ, chúng ta sẽ cấu hình máy chủ Slave.

Bước 1: Dừng PostgreSQL

Trước khi bắt đầu, hãy dừng PostgreSQL trên máy chủ Slave:

sudo systemctl stop postgresql

Bước 2: Sao Lưu Thư Mục Dữ Liệu

Sao lưu thư mục dữ liệu hiện tại của PostgreSQL. Thư mục này thường nằm ở /var/lib/postgresql/<version>/main.

sudo mv /var/lib/postgresql/<version>/main /var/lib/postgresql/<version>/main.bak

Giải thích:

Lệnh này đổi tên thư mục dữ liệu hiện tại thành main.bak. Điều này cho phép bạn khôi phục lại dữ liệu gốc nếu có vấn đề xảy ra.

Bước 3: Sao Chép Dữ Liệu từ Máy Chủ Master

Sử dụng công cụ pg_basebackup để sao chép dữ liệu từ máy chủ Master.

sudo pg_basebackup -h <master_ip_address> -U replicator -p 5432 -D /var/lib/postgresql/<version>/main -P -v -w

Giải thích:

  • -h <master_ip_address>: Chỉ định địa chỉ IP của máy chủ Master. Thay thế <master_ip_address> bằng địa chỉ IP thực tế của máy chủ Master.
  • -U replicator: Chỉ định user để kết nối với máy chủ Master. Sử dụng user replicator mà bạn đã tạo ở bước trước.
  • -p 5432: Chỉ định cổng PostgreSQL. Mặc định là 5432.
  • -D /var/lib/postgresql/<version>/main: Chỉ định thư mục đích để lưu trữ dữ liệu đã sao chép.
  • -P: Hiển thị tiến trình sao chép.
  • -v: Bật chế độ verbose để hiển thị thêm thông tin.
  • -w: Yêu cầu nhập mật khẩu cho user replicator.

Khi được yêu cầu, hãy nhập mật khẩu mà bạn đã đặt cho user replicator.

Bước 4: Tạo File recovery.conf

Tạo một file có tên là recovery.conf trong thư mục dữ liệu PostgreSQL (thường là /var/lib/postgresql/<version>/main). File này chứa thông tin cấu hình cần thiết để máy chủ Slave kết nối với máy chủ Master.

sudo nano /var/lib/postgresql/<version>/main/recovery.conf

Thêm nội dung sau vào file:

standby_mode = 'on'
primary_conninfo = 'host=<master_ip_address> port=5432 user=replicator password=<password>'
trigger_file = '/tmp/trigger.txt'

Giải thích:

  • standby_mode = 'on': Bật chế độ standby, cho biết đây là máy chủ Slave.
  • primary_conninfo: Chỉ định thông tin kết nối đến máy chủ Master.
    • host: Địa chỉ IP của máy chủ Master.
    • port: Cổng PostgreSQL.
    • user: User để kết nối với máy chủ Master.
    • password: Mật khẩu cho user.
  • trigger_file: Chỉ định file trigger. Khi file này tồn tại, máy chủ Slave sẽ được nâng cấp lên thành máy chủ Master (failover).

Quan trọng: Hãy thay thế <master_ip_address> và <password> bằng địa chỉ IP và mật khẩu thực tế của bạn.

Lưu ý: Từ PostgreSQL 12 trở lên, recovery.conf đã được thay thế bằng postgresql.auto.conf. Tuy nhiên, việc sử dụng recovery.conf vẫn được hỗ trợ. Để sử dụng postgresql.auto.conf, bạn cần tạo file này và thêm các cấu hình tương tự như trên, sau đó chỉnh sửa postgresql.conf để bao gồm dòng include 'postgresql.auto.conf'.

Bước 5: Khởi Động Lại PostgreSQL

Khởi động lại PostgreSQL trên máy chủ Slave:

sudo systemctl start postgresql

Bước 6: Kiểm Tra Trạng Thái Replication

Kiểm tra trạng thái replication bằng cách kết nối với cơ sở dữ liệu trên máy chủ Slave và chạy truy vấn sau:

sudo -u postgres psql -c "SELECT * FROM pg_stat_replication;"

Nếu replication hoạt động bình thường, bạn sẽ thấy một hàng kết quả hiển thị thông tin về kết nối replication, bao gồm địa chỉ IP của máy chủ Master, trạng thái kết nối và độ trễ (lag) của replication.

Kiểm Tra và Giám Sát

Sau khi Thiết Lập Master – Slave Postgresql, việc kiểm tra và giám sát thường xuyên là rất quan trọng để đảm bảo hệ thống hoạt động ổn định.

Kiểm Tra Replication

  • Kiểm tra dữ liệu: Tạo một bản ghi mới trên máy chủ Master và kiểm tra xem nó có được sao chép sang máy chủ Slave hay không.
  • Kiểm tra trạng thái replication: Sử dụng truy vấn SELECT * FROM pg_stat_replication; trên máy chủ Slave để kiểm tra trạng thái kết nối và độ trễ.

Giám Sát Hệ Thống

  • Sử dụng công cụ giám sát: Sử dụng các công cụ giám sát như Nagios, Zabbix, Prometheus để theo dõi hiệu suất và trạng thái của cả hai máy chủ.
  • Thiết lập cảnh báo: Thiết lập cảnh báo để thông báo khi có sự cố xảy ra, chẳng hạn như mất kết nối replication, độ trễ quá cao hoặc tài nguyên hệ thống quá tải.

Failover (Chuyển Đổi Dự Phòng)

Trong trường hợp máy chủ Master gặp sự cố, bạn cần thực hiện failover để chuyển đổi máy chủ Slave thành máy chủ Master.

Bước 1: Dừng Máy Chủ Master (Nếu Có Thể)

Nếu máy chủ Master vẫn hoạt động, hãy dừng nó để tránh xung đột dữ liệu.

Bước 2: Tạo File Trigger

Tạo file trigger trên máy chủ Slave:

sudo touch /tmp/trigger.txt

Khi file này tồn tại, máy chủ Slave sẽ tự động được nâng cấp lên thành máy chủ Master.

Bước 3: Khởi Động Lại PostgreSQL trên Máy Chủ Mới (trước đây là Slave)

Khởi động lại PostgreSQL trên máy chủ mới (trước đây là Slave)

sudo systemctl restart postgresql

Máy chủ này sẽ tự động nhận vai trò Master và chấp nhận các kết nối ghi.

Bước 4: Cấu Hình Lại Ứng Dụng

Cấu hình lại ứng dụng của bạn để kết nối với máy chủ Master mới.

Bước 5: Thiết Lập Máy Chủ Master Cũ Làm Slave (Sau Khi Khôi Phục)

Sau khi máy chủ Master cũ được khôi phục, bạn có thể thiết lập nó làm Slave cho máy chủ Master mới. Quá trình này tương tự như quá trình thiết lập Slave ban đầu.

Lời Khuyên từ Chuyên Gia

“Việc thiết lập Master – Slave PostgreSQL là một bước quan trọng để đảm bảo tính sẵn sàng và bảo vệ dữ liệu. Tuy nhiên, điều quan trọng là phải hiểu rõ các khái niệm cơ bản và thực hiện các bước cấu hình một cách cẩn thận. Đồng thời, việc kiểm tra và giám sát thường xuyên là rất cần thiết để phát hiện và giải quyết các vấn đề kịp thời,” ông Nguyễn Văn An, chuyên gia quản trị cơ sở dữ liệu với hơn 15 năm kinh nghiệm.

Các Vấn Đề Thường Gặp và Cách Xử Lý

Trong quá trình thiết lập và vận hành Master – Slave PostgreSQL, bạn có thể gặp một số vấn đề sau:

  • Kết nối replication bị lỗi: Kiểm tra lại cấu hình mạng, tường lửa và quyền truy cập. Đảm bảo rằng máy chủ Slave có thể kết nối đến máy chủ Master trên cổng PostgreSQL.
  • Độ trễ replication quá cao: Điều này có thể do nhiều nguyên nhân, chẳng hạn như tải hệ thống quá cao, cấu hình phần cứng không đủ hoặc cấu hình PostgreSQL không tối ưu.
  • Dữ liệu không đồng bộ: Kiểm tra lại cấu hình replication và đảm bảo rằng tất cả các thay đổi trên máy chủ Master đều được sao chép sang máy chủ Slave.
  • Failover không thành công: Kiểm tra lại cấu hình trigger và đảm bảo rằng máy chủ Slave có thể được nâng cấp lên thành máy chủ Master một cách tự động.

“Một trong những lỗi phổ biến nhất khi thiết lập replication là sai sót trong file pg_hba.conf. Hãy chắc chắn rằng bạn đã cấu hình đúng địa chỉ IP và phương thức xác thực cho máy chủ Slave,” bà Trần Thị Bình, kiến trúc sư giải pháp cơ sở dữ liệu.

Các Phương Pháp Tối Ưu Hóa Hiệu Suất

Để tối ưu hóa hiệu suất của hệ thống Master – Slave PostgreSQL, bạn có thể áp dụng các phương pháp sau:

  • Sử dụng ổ cứng SSD: Ổ cứng SSD có tốc độ đọc/ghi nhanh hơn nhiều so với ổ cứng HDD, giúp cải thiện hiệu suất tổng thể của hệ thống.
  • Tăng bộ nhớ RAM: Tăng bộ nhớ RAM giúp giảm thiểu số lần truy cập ổ cứng, cải thiện hiệu suất truy vấn và replication.
  • Tối ưu hóa cấu hình PostgreSQL: Điều chỉnh các tham số cấu hình của PostgreSQL, chẳng hạn như shared_buffers, work_mem và maintenance_work_mem, để phù hợp với tải hệ thống.
  • Sử dụng connection pooling: Sử dụng connection pooling để giảm thiểu thời gian thiết lập kết nối đến cơ sở dữ liệu.
  • Phân vùng dữ liệu: Phân vùng dữ liệu có thể giúp cải thiện hiệu suất truy vấn, đặc biệt là đối với các bảng lớn.

Kết Luận

Thiết lập kiến trúc Master – Slave PostgreSQL là một giải pháp hiệu quả để tăng tính sẵn sàng, cải thiện hiệu suất và bảo vệ dữ liệu. Bằng cách làm theo hướng dẫn chi tiết này, bạn có thể thiết lập một hệ thống Master – Slave PostgreSQL ổn định và đáng tin cậy. Hãy nhớ rằng, việc kiểm tra và giám sát thường xuyên là rất quan trọng để đảm bảo hệ thống hoạt động bình thường. Chúc bạn thành công! Việc thiết lập master – slave PostgreSQL không khó như bạn nghĩ, chỉ cần cẩn thận và làm theo từng bước!

FAQ (Câu Hỏi Thường Gặp)

  1. Sự khác biệt giữa Asynchronous và Synchronous replication là gì?

    Asynchronous replication không đợi xác nhận từ Slave trước khi commit giao dịch, nhanh hơn nhưng có thể mất dữ liệu nếu Master gặp sự cố. Synchronous replication đảm bảo dữ liệu được đồng bộ, an toàn hơn nhưng chậm hơn.

  2. Tôi có thể có nhiều hơn một Slave không?

    Có, bạn có thể có nhiều Slave cho một Master. Điều này giúp tăng khả năng đọc và tính sẵn sàng của hệ thống.

  3. File recovery.conf có bắt buộc không?

    Có, file recovery.conf (hoặc postgresql.auto.conf từ PostgreSQL 12 trở lên) là bắt buộc để máy chủ Slave biết cách kết nối và đồng bộ hóa dữ liệu từ máy chủ Master.

  4. Làm thế nào để kiểm tra xem replication có hoạt động không?

    Sử dụng truy vấn SELECT * FROM pg_stat_replication; trên máy chủ Slave để kiểm tra trạng thái kết nối và độ trễ.

  5. Tôi nên sử dụng loại xác thực nào trong pg_hba.conf?

    Nên sử dụng md5 hoặc scram-sha-256 để bảo mật hơn. Không nên sử dụng trust trong môi trường sản xuất.

  6. wal_keep_size có ý nghĩa gì?

    wal_keep_size xác định dung lượng WAL tối thiểu cần giữ lại trên Master để Slave có thể bắt kịp nếu bị tụt lại. Điều chỉnh tham số này dựa trên tốc độ tạo WAL và thời gian tối đa mà Slave có thể bị ngắt kết nối.

  7. Tôi có thể sử dụng Master – Slave PostgreSQL cho mục đích sao lưu không?

    Có, máy chủ Slave cung cấp một bản sao dữ liệu gần như thời gian thực, có thể được sử dụng cho mục đích sao lưu và phục hồi. Tuy nhiên, nên kết hợp với các phương pháp sao lưu khác để đảm bảo an toàn dữ liệu tuyệt đối.