Posted inDatabase

Nhân bản Cơ sở dữ liệu: Giải thích các thiết lập Master-Slave & Multi-Master

Database tutorial - IT technology blog
Database tutorial - IT technology blog

Cuộc gọi pager lúc 2 giờ sáng: Khi cơ sở dữ liệu của bạn ngừng hoạt động

Đã 2 giờ sáng. Tiếng pager đáng sợ réo lên, lôi bạn ra khỏi giấc ngủ sâu. Tim bạn chùng xuống khi thấy cảnh báo: CRITICAL - Production Database Offline. Bạn vội vã bật laptop, các ngón tay lướt nhanh trên bàn phím, cố gắng chẩn đoán vấn đề. Người dùng gặp lỗi 500, các giao dịch thất bại và doanh nghiệp mất tiền từng phút trôi qua. Tất cả chúng ta đều đã từng trải qua cảm giác khó chịu đó khi một điểm lỗi duy nhất làm sập toàn bộ ứng dụng, phải không?

Sau một giờ khắc phục sự cố điên cuồng, bạn đã khởi động lại được dịch vụ. Nhưng thiệt hại đã xảy ra rồi. Báo cáo sau sự cố (post-mortem) cho thấy một thực tế phũ phàng: một máy chủ cơ sở dữ liệu đơn lẻ, nguyên khối đang xử lý tất cả mọi thứ. Khi nó gặp trục trặc – dù là do lỗi phần cứng, một truy vấn kém hiệu quả, hay lưu lượng truy cập tăng đột biến không mong muốn – thì không có gì để dự phòng. Dẫn đến việc hệ thống ngừng hoạt động hoàn toàn.

Phân tích nguyên nhân gốc rễ: Hội chứng điểm lỗi duy nhất

Sự cố lúc 2 giờ sáng đó không chỉ là xui xẻo; đó là một triệu chứng của điểm yếu kiến trúc cơ bản. Việc phụ thuộc vào một máy chủ cơ sở dữ liệu duy nhất cho mọi hoạt động giống như xây một ngôi nhà chỉ với một cây cột trụ. Nó sẽ hoạt động cho đến khi cây cột đó hỏng, và rồi mọi thứ sụp đổ. Các vấn đề cốt lõi mà chúng ta phải đối mặt là thiếu đi:

  • Khả năng sẵn sàng cao (HA): Khả năng hệ thống của bạn tiếp tục hoạt động ngay cả khi một thành phần quan trọng, như cơ sở dữ liệu chính của bạn, ngừng hoạt động.
  • Phục hồi sau thảm họa (DR): Một chiến lược mạnh mẽ để khôi phục dữ liệu và dịch vụ của bạn khi xảy ra các sự cố lớn, chẳng hạn như sự cố mất toàn bộ trung tâm dữ liệu.
  • Khả năng mở rộng: Khả năng xử lý tải trọng ngày càng tăng, đặc biệt là lưu lượng đọc, mà không làm quá tải máy chủ chính và giảm hiệu suất.

Nếu không có các biện pháp bảo vệ này, cơ sở dữ liệu của bạn rất dễ bị tổn thương. Replication đóng vai trò là tuyến phòng thủ chính của chúng ta chống lại các kịch bản này, đảm bảo chúng ta luôn có nhiều bản sao dữ liệu được cập nhật sẵn sàng để tiếp quản.

So sánh các giải pháp: Nhân bản Master-Slave so với Multi-Master

Về cốt lõi, nhân bản cơ sở dữ liệu liên quan đến việc sao chép dữ liệu từ một máy chủ cơ sở dữ liệu sang một hoặc nhiều máy chủ khác. Kỹ thuật cơ bản này giúp tăng cường đáng kể khả năng sẵn sàng, phục hồi sau thảm họa và khả năng mở rộng đọc. Hãy cùng khám phá hai loại chính.

Nhân bản Master-Slave: Con ngựa thồ

Đây có lẽ là thiết lập nhân bản phổ biến nhất mà bạn sẽ gặp. Đây là một giải pháp đơn giản và cực kỳ hiệu quả cho nhiều trường hợp sử dụng.

Cách hoạt động:

Trong thiết lập này, một máy chủ đóng vai trò là máy chủ chính, hay còn gọi là Master. Máy chủ master này xử lý tất cả các thao tác ghi (chèn, cập nhật, xóa). Sau đó, nó gửi các thay đổi này một cách bất đồng bộ (hoặc đôi khi đồng bộ, mặc dù ít phổ biến hơn vì lý do hiệu suất) đến một hoặc nhiều máy chủ khác, được gọi là Slaves. Các máy chủ slave này thường xử lý các thao tác đọc. Hãy hình dung nó như một tờ báo: master là biên tập viên viết các câu chuyện, và các slave là các máy in phân phối bản sao đến độc giả.

Lợi ích:

  • Mở rộng khả năng đọc (Read Scaling): Bạn có thể phân phối các truy vấn đọc trên nhiều máy chủ slave, giảm đáng kể tải cho master. Điều này có thể cải thiện hiệu suất ứng dụng tổng thể từ 2 đến 5 lần đối với các tác vụ nặng về đọc.
  • Khả năng sẵn sàng cao/Phục hồi sau thảm họa: Nếu máy chủ master của bạn gặp sự cố, bạn có thể thăng cấp một trong các slave để trở thành master mới, giảm thiểu thời gian ngừng hoạt động xuống chỉ còn vài giây hoặc vài phút. Điều này rất quan trọng để phục hồi sau sự cố lúc 2 giờ sáng đó.
  • Báo cáo & Phân tích: Chạy các truy vấn phân tích nặng, tốn nhiều tài nguyên hoặc tạo báo cáo trên các máy chủ slave mà không ảnh hưởng đến hiệu suất của master giao dịch của bạn.

Hạn chế:

  • Điểm ghi duy nhất: Master vẫn là một điểm lỗi duy nhất cho các thao tác ghi. Nếu nó ngừng hoạt động, các thao tác ghi mới sẽ dừng lại cho đến khi một master mới được thăng cấp thành công.
  • Độ phức tạp của Failover: Mặc dù một slave có thể được thăng cấp, nhưng quá trình này, đặc biệt là failover tự động, có thể phức tạp để thiết lập đúng cách. Đảm bảo tính nhất quán của dữ liệu trong quá trình chuyển đổi đòi hỏi kế hoạch cẩn thận.
  • Độ trễ Replication: Replication bất đồng bộ có thể gây ra một độ trễ nhỏ, hay còn gọi là ‘lag’, giữa master và các slave của nó, thường dao động từ vài mili giây đến vài giây dưới tải nặng. Điều này có nghĩa là các slave có thể không phải lúc nào cũng có dữ liệu mới nhất tuyệt đối. Điều này có thể là một vấn đề đối với các ứng dụng yêu cầu tính nhất quán đọc ngay sau khi ghi.

Ví dụ thực tế: Thiết lập nhân bản MySQL Master-Slave

Hãy cùng xem xét một ví dụ đơn giản cho MySQL. Hãy tưởng tượng bạn có hai máy chủ: db-master.yourdomain.com và db-slave.yourdomain.com.

1. Cấu hình Master (db-master.yourdomain.com)

Chỉnh sửa tệp cấu hình MySQL của bạn (ví dụ: /etc/mysql/my.cnf hoặc /etc/my.cnf):


# Cấu hình Master
[mysqld]
server-id = 1
log_bin = mysql-bin
binlog_do_db = your_database_name # Tùy chọn: Chỉ nhân bản một cơ sở dữ liệu cụ thể
# Đối với replication bán đồng bộ, đảm bảo master đợi ít nhất một slave xác nhận đã nhận các sự kiện binlog trước khi commit
# rpl_semi_sync_master_enabled = 1
# rpl_semi_sync_master_timeout = 5000 # Mili giây

Khởi động lại MySQL trên master:


sudo systemctl restart mysql

Sau đó, tạo một người dùng replication và lấy trạng thái master:


mysql -u root -p

# Tạo người dùng replication
CREATE USER 'repl_user'@'%' IDENTIFIED BY 'your_secure_password';
GRANT REPLICATION SLAVE ON *.* TO 'repl_user'@'%';
FLUSH PRIVILEGES;

# Khóa các bảng và lấy trạng thái master (thực hiện điều này trong khoảng thời gian bảo trì hoặc khi lưu lượng truy cập thấp để có một snapshot nhất quán)
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
# Ghi lại File và Position (ví dụ: mysql-bin.000001 và 123)

# Mở khóa các bảng sau khi lấy trạng thái
UNLOCK TABLES;
EXIT;
2. Cấu hình Slave (db-slave.yourdomain.com)

Chỉnh sửa tệp cấu hình MySQL của bạn:


# Cấu hình Slave
[mysqld]
server-id = 2
relay_log = mysql-relay-bin
read_only = 1 # Tùy chọn, nhưng rất khuyến nghị để ngăn chặn các thao tác ghi ngoài ý muốn trên slave

Khởi động lại MySQL trên slave:


sudo systemctl restart mysql

Sau đó, kết nối slave với master bằng cách sử dụng các chi tiết bạn đã ghi lại trước đó:


mysql -u root -p

CHANGE MASTER TO
  MASTER_HOST='db-master.yourdomain.com',
  MASTER_USER='repl_user',
  MASTER_PASSWORD='your_secure_password',
  MASTER_LOG_FILE='mysql-bin.000001', -- Sử dụng File từ SHOW MASTER STATUS
  MASTER_LOG_POS=123;                -- Sử dụng Position từ SHOW MASTER STATUS

START SLAVE;

SHOW SLAVE STATUS\G
EXIT;

Kiểm tra SHOW SLAVE STATUS\G trên slave. Bạn muốn thấy Slave_IO_Running: Yes và Slave_SQL_Running: Yes, và Seconds_Behind_Master: 0 (hoặc một số rất nhỏ, cho thấy độ trễ tối thiểu).

Nhân bản Multi-Master: Cường quốc phân tán

Nhân bản multi-master nâng cao những lợi ích này, cung cấp khả năng sẵn sàng cao hơn nữa và khả năng mở rộng các thao tác ghi. Nó cung cấp một cách tiếp cận tiên tiến hơn để dự phòng dữ liệu.

Cách hoạt động:

Không giống như master-slave, nơi chỉ có một máy chủ chấp nhận các thao tác ghi, trong thiết lập multi-master, tất cả các máy chủ tham gia đều có thể chấp nhận các thao tác ghi. Các thay đổi được thực hiện trên bất kỳ master nào sẽ tự động được truyền đến tất cả các master khác. Điều này tạo ra một môi trường active-active thực sự, nơi bất kỳ node nào cũng có thể phục vụ cả thao tác đọc và ghi.

Lợi ích:

  • Không có điểm lỗi duy nhất (cho các thao tác ghi): Nếu một master ngừng hoạt động, các master khác có thể tiếp tục xử lý các thao tác ghi một cách liền mạch. Đây là một lợi ích lớn cho các ứng dụng yêu cầu thời gian hoạt động cực cao.
  • Cải thiện khả năng mở rộng ghi: Có thể phân phối tải ghi của bạn trên nhiều máy chủ, điều này có thể có lợi cho các ứng dụng có thông lượng cao xử lý hàng nghìn giao dịch mỗi giây.
  • Phân phối địa lý: Thiết lập các master ở các trung tâm dữ liệu khác nhau để phục hồi sau thảm họa mạnh mẽ. Điều này cũng cung cấp độ trễ thấp hơn cho người dùng ở các khu vực khác nhau khi truy cập phiên bản cơ sở dữ liệu gần nhất của họ.

Hạn chế:

  • Giải quyết xung đột: Đây là thách thức lớn nhất. Điều gì xảy ra nếu cùng một phần dữ liệu được sửa đổi trên hai master khác nhau cùng một lúc? Ví dụ, nếu hai người dùng cập nhật cùng một số lượng hàng tồn kho trên các master khác nhau từ 10 thành 9 và 10 thành 8. Để duy trì tính nhất quán của dữ liệu, bạn cần các chiến lược giải quyết xung đột tinh vi, chẳng hạn như ‘last-writer-wins’ (người ghi cuối cùng thắng), các phương pháp dựa trên dấu thời gian, hoặc logic ứng dụng tùy chỉnh. Điều này làm tăng đáng kể độ phức tạp cho hệ thống.
  • Tăng lưu lượng mạng: Nhiều dữ liệu cần được đồng bộ hóa giữa tất cả các master, có khả năng dẫn đến sự gia tăng đáng kể chi phí mạng, đặc biệt với khối lượng ghi cao.
  • Độ phức tạp cao hơn: Việc thiết lập, quản lý và khắc phục sự cố phức tạp hơn đáng kể so với master-slave. Bạn đang làm việc với các mô hình đồng thuận phân tán và nhất quán, đòi hỏi chuyên môn sâu rộng.

Ví dụ về khái niệm: Nhân bản logic PostgreSQL (Ý tưởng Multi-Master đơn giản hóa)

Trong khi multi-master thực sự với việc giải quyết xung đột tự động thường được xử lý bởi các giải pháp chuyên biệt (như Galera Cluster cho MySQL hoặc các tiện ích mở rộng PostgreSQL cụ thể), nhân bản logic của PostgreSQL có thể được cấu hình để đạt được một dạng thiết lập multi-master hai chiều. Tuy nhiên, việc xử lý xung đột thủ công có thể cần thiết tùy thuộc vào ứng dụng.

Trên Master 1:


CREATE PUBLICATION my_publication FOR TABLE my_table;

Trên Master 2:


CREATE PUBLICATION my_publication FOR TABLE my_table;

Sau đó, mỗi master đăng ký publication của master kia. Trên Master 1:


CREATE SUBSCRIPTION my_subscription_to_m2
  CONNECTION 'host=master2_ip port=5432 user=repl_user password=your_password dbname=your_db'
  PUBLICATION my_publication;

Trên Master 2:


CREATE SUBSCRIPTION my_subscription_to_m1
  CONNECTION 'host=master1_ip port=5432 user=repl_user password=your_password dbname=your_db'
  PUBLICATION my_publication;

Điều này tạo ra một đường dẫn cho các thay đổi chảy theo cả hai chiều. Tuy nhiên, bạn sẽ cần quản lý cẩn thận các sequence, trigger hoặc logic ứng dụng để ngăn chặn xung đột ghi hoặc đảm bảo chúng được giải quyết một cách nhẹ nhàng.

Chọn phương pháp tiếp cận tốt nhất của bạn: Ngăn chặn các cuộc gọi lúc 2 giờ sáng trong tương lai

Khi đối mặt với quyết định kiến trúc tiếp theo của bạn, làm thế nào để bạn chọn chiến lược nhân bản phù hợp? Quyết định của bạn phụ thuộc vào nhu cầu cụ thể, khả năng chịu đựng thời gian ngừng hoạt động của ứng dụng và năng lực vận hành của nhóm bạn.

Khi nào nên sử dụng nhân bản Master-Slave:

  • Hầu hết các ứng dụng web phổ biến: Nơi khả năng mở rộng đọc là mối quan tâm chính của bạn, và thời gian ngừng hoạt động ghi ngắn hạn (ví dụ: vài phút) là chấp nhận được trong quá trình failover.
  • Chiến lược chính rõ ràng: Khi bạn cần một cơ sở dữ liệu chính được xác định rõ ràng cho tất cả các thao tác ghi và một chiến lược phục hồi sau thảm họa mạnh mẽ.
  • Các thiết lập đơn giản hơn: Nếu bạn muốn giảm thiểu chi phí vận hành và độ phức tạp, master-slave thường dễ triển khai và quản lý hơn.

Khi nào nên sử dụng nhân bản Multi-Master:

  • Khả năng sẵn sàng ghi cực cao: Đối với các ứng dụng yêu cầu thời gian ngừng hoạt động gần bằng không cho các thao tác ghi, ngay cả khi một máy chủ gặp sự cố. Hãy nghĩ đến các hệ thống tài chính quan trọng hoặc nền tảng trò chơi thời gian thực.
  • Tải ghi phân tán: Khi bạn cần phân phối các thao tác ghi trên nhiều máy chủ, có thể ở các khu vực địa lý khác nhau, để phục vụ người dùng trên toàn cầu.
  • Hệ thống doanh nghiệp cao cấp: Nơi độ phức tạp và chi phí quản lý giải quyết xung đột được biện minh bởi các yêu cầu kinh doanh nghiêm ngặt về thời gian hoạt động và phân phối dữ liệu.

Hãy chuẩn bị cho sự phức tạp đáng kể về kiến trúc và vận hành với multi-master. Đây không phải là một giải pháp thần kỳ và thường đòi hỏi sự hiểu biết sâu sắc về các yêu cầu nhất quán của ứng dụng và cách cơ sở dữ liệu bạn chọn xử lý xung đột. Điều này thường đòi hỏi các cân nhắc thiết kế ở cấp độ ứng dụng.

Khi bạn làm việc với nhân bản cơ sở dữ liệu, các tác vụ như chuẩn bị dữ liệu để gieo hạt ban đầu cho một bản sao (replica) hoặc để báo cáo phân tích là phổ biến. Để chuyển đổi dữ liệu nhanh chóng, đặc biệt là chuyển đổi tệp CSV sang JSON để nhập, tôi thường sử dụng toolcraft.app/vi/tools/data/csv-to-json.

Nó chạy ngay trong trình duyệt, điều này rất tuyệt vì nó có nghĩa là không có dữ liệu nhạy cảm nào rời khỏi máy của tôi. Nó là một tiện ích nhỏ, nhưng thực sự là cứu cánh khi tôi cần nhanh chóng chuẩn bị dữ liệu kiểm thử hoặc dữ liệu cấu hình cho một slave mới hoặc chỉ để gieo hạt dữ liệu ban đầu.

Tóm lại, nhân bản cơ sở dữ liệu tạo thành nền tảng của các hệ thống mạnh mẽ, có khả năng sẵn sàng cao. Đó là điều ngăn chặn những cuộc gọi hoảng loạn lúc nửa đêm và đảm bảo dịch vụ của bạn luôn hoạt động, ngay cả khi mọi thứ chắc chắn đi chệch hướng. Luôn kiểm tra các quy trình failover của bạn một cách nghiêm ngặt – đừng đợi đến 2 giờ sáng để phát hiện ra kế hoạch phục hồi sau thảm họa của bạn có lỗ hổng!

Share:
Tags: