Khám phá MySQL và MariaDB

Hướng dẫn MySQL Replication: Cài đặt, Khắc lỗi, Quản trị

Nâng cao
目次

1. MySQL Replication là gì? Tổng quan và mục đích sử dụng

MySQL Replication là tính năng đồng bộ bản sao cơ sở dữ liệu theo thời gian thực tới các máy chủ khác. Nhờ đó, có thể tăng tính dự phòng và hiệu năng của cơ sở dữ liệu. Dưới đây, chúng tôi sẽ giải thích chi tiết về các trường hợp sử dụng MySQL Replication và cơ chế của nó.

Tổng quan về MySQL Replication

MySQL Replication chia sẻ nội dung cơ sở dữ liệu giữa nhiều máy chủ thông qua cấu hình máy chủ chính và máy chủ phụ. Cụ thể, máy chủ chính ghi lại các cập nhật dữ liệu vào binary log, và máy chủ phụ đọc và phản ánh chúng để đồng bộ dữ liệu. Nhờ đó, ngay cả khi máy chủ chính gặp sự cố, có thể chuyển sang máy chủ phụ để duy trì dịch vụ.

Mục đích sử dụng MySQL Replication

MySQL Replication được sử dụng rộng rãi trong các mục đích sau.
  • Đảm bảo tính sẵn sàng cao: Khi gặp sự cố, việc sử dụng máy chủ phụ giúp giảm thiểu thời gian ngừng hoạt động.
  • Phân tải: Phân phối các truy vấn chỉ đọc tới máy chủ phụ để giảm tải cho máy chủ chính.
  • Bảo vệ dữ liệu và sao lưu: Replication sao chép dữ liệu theo thời gian thực, do đó có thể được sử dụng làm sao lưu.

Các loại Replication

MySQL Replication có các loại sau tùy theo cách đồng bộ dữ liệu.
  • Replication không đồng bộ: Máy chủ chính tiếp tục xử lý mà không chờ máy chủ phụ nhận thông tin cập nhật, cho phép phản hồi nhanh. Tuy nhiên, khi có sự cố, một phần dữ liệu có thể không tới máy chủ phụ.
  • Replication bán đồng bộ: Tiến trình chỉ tiếp tục sau khi xác nhận dữ liệu đã được phản ánh trên máy chủ phụ, do đó đáng tin cậy hơn so với không đồng bộ, nhưng tốc độ phản hồi hơi chậm hơn.
Trong phần tiếp theo, chúng tôi sẽ giải thích về các khái niệm cơ bản của MySQL Replication như binary log và GTID.

2. Các khái niệm cơ bản của Replication MySQL

Để hiểu Replication MySQL, việc nắm bắt vai trò củabinary log vàGTID（Global Transaction ID） là quan trọng. Những yếu tố này là nền tảng để dữ liệu được sao chép một cách chính xác.

Vai trò của Master và Slave

Trong Replication MySQL, máy chủ Master và máy chủ Slave đảm nhận các vai trò khác nhau. Máy chủ Master ghi lại các thay đổi dữ liệu vào binary log và truyền nội dung này tới Slave. Máy chủ Slave áp dụng log nhận được từ Master và cập nhật dữ liệu. Nhờ đó, Slave có thể giữ nội dung dữ liệu mới nhất giống với Master.

Binary Log và Relay Log

Nền tảng của Replication MySQL sử dụng hai loại log sau:
  1. binary log（Binary Log）
  • Binary log là bản ghi các cập nhật dữ liệu (INSERT, UPDATE, DELETE, v.v.) trên máy chủ Master. Nhờ đó, máy chủ Slave có thể duy trì trạng thái dữ liệu giống như Master.
  1. relay log（Relay Log）
  • Relay log là bản sao của binary log mà máy chủ Slave nhận từ Master và lưu trên hệ thống của mình. Thread SQL của Slave thực thi relay log này theo thứ tự để phản ánh các thay đổi dữ liệu.

GTID（Global Transaction ID） là gì

GTID là cơ chế gán một ID duy nhất cho mỗi giao dịch, giúp duy trì tính nhất quán đồng bộ giữa nhiều Slave. Khi sử dụng GTID, không cần chỉ định vị trí binary log; chỉ các giao dịch chưa được lấy từ Master sẽ tự động được áp dụng trên Slave, do đó việc quản lý được đơn giản hoá đáng kể.

Lợi ích của GTID

  • Định danh duy nhất: Mỗi giao dịch được gán GTID duy nhất, vì vậy việc xác định giao dịch đã được áp dụng hay chưa trở nên rõ ràng.
  • Khôi phục dễ dàng: Khi sử dụng GTID, ngay cả khi Master hoặc Slave khởi động lại, chỉ các giao dịch chưa được áp dụng sẽ được áp dụng lại.
  • Hiệu quả quản lý vận hành: Ngay cả trong môi trường quy mô lớn với nhiều máy chủ Slave, vẫn có thể quản lý dễ dàng trong khi duy trì tính nhất quán của giao dịch.
Để sử dụng GTID, cần thiết lập gtid_mode=ON và enforce_gtid_consistency=ON. Khi cấu hình các thiết lập này trên Master và Slave, Replication dựa trên GTID sẽ được kích hoạt. Trong phần tiếp theo, chúng tôi sẽ giải thích các bước thiết lập cụ thể cho Replication MySQL.

3. Các bước thiết lập MySQL Replication

Ở đây, chúng tôi sẽ giải thích chi tiết các bước để thiết lập MySQL Replication. Bằng cách làm theo các bước dưới đây, bạn có thể cấu hình cơ bản master và slave, và thực hiện đồng bộ dữ liệu thời gian thực.

Cấu hình máy chủ Master

Đầu tiên, chỉnh sửa file cấu hình của máy chủ master (thường là my.cnf hoặc my.ini) để bật binary log và thiết lập server ID.
  1. Chỉnh sửa file cấu hình
  • Thêm các thiết lập sau vào phần [mysqld] và đặt server ID thành một giá trị duy nhất (ví dụ: 1).
   [mysqld]
   server-id=1
   log-bin=mysql-bin
  • server-id cần được chỉ định một số duy nhất khác nhau cho mỗi máy chủ, và log-bin có nghĩa là bật binary log.
  1. Tạo người dùng replication
  • Tạo một người dùng chuyên dụng cho replication trên máy chủ master và cấp quyền cần thiết.
   CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
   GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
   FLUSH PRIVILEGES;
  • Người dùng này cần thiết để máy chủ slave có thể truy cập dữ liệu trên master.
  1. Kiểm tra trạng thái master
  • Kiểm tra file binary log hiện tại và vị trí (position) của nó. Thông tin này cần thiết cho cấu hình máy chủ slave.
   SHOW MASTER STATUS;
  • Kết quả của lệnh này hiển thị File (tên file log) và Position (vị trí), sẽ được dùng trong cấu hình phía slave.

Cấu hình máy chủ Slave

Tiếp theo, chỉnh sửa file cấu hình của máy chủ slave, thiết lập server ID và thông tin master.
  1. Chỉnh sửa file cấu hình
  • Máy chủ slave cũng cần đặt server-id duy nhất (ví dụ: 2). Server ID phải khác với master.
   [mysqld]
   server-id=2
  • Để ngăn ghi dữ liệu trên slave, thường cũng thiết lập read_only=ON.
  1. Thiết lập thông tin master trên slave
  • Chạy lệnh sau trên slave để chỉ định hostname, user, tên file binary log và position của master.
   CHANGE MASTER TO
       MASTER_HOST='master_host',
       MASTER_USER='repl',
       MASTER_PASSWORD='password',
       MASTER_LOG_FILE='mysql-bin.000001',
       MASTER_LOG_POS=123;
  • Trong MASTER_LOG_FILE và MASTER_LOG_POS, nhập các giá trị đã kiểm tra trên master.
  1. Bắt đầu replication
  • Chạy lệnh sau trên slave để bắt đầu replication.
   START SLAVE;

Kiểm tra trạng thái replication

Kiểm tra xem replication giữa master và slave đã được cấu hình đúng chưa.
  • Kiểm tra trạng thái master
  SHOW MASTER STATUS;
  • Kiểm tra trạng thái slave
  SHOW SLAVE STATUSG;
  • Nếu Slave_IO_Running và Slave_SQL_Running hiển thị Yes, replication đang hoạt động bình thường.
Trong phần tiếp theo, chúng tôi sẽ giải thích các phương pháp cấu hình nâng cao cho MySQL replication. Sẽ đề cập đến sự khác nhau giữa replication bất đồng bộ và gần đồng bộ, cũng như các bước cấu hình sử dụng GTID.

4. Các loại và ứng dụng của Replication

MySQL replication có hai loại dựa trên cách đồng bộ dữ liệu: replication không đồng bộ và replication gần đồng bộ. Bằng cách hiểu các đặc điểm và tiêu chí lựa chọn phù hợp với từng cảnh sử dụng, bạn có thể nâng cao hiệu năng và độ tin cậy của hệ thống. Ngoài ra, ở đây cũng sẽ giải thích lợi ích của việc cấu hình replication sử dụng GTID (Global Transaction Identifier).

Sự khác biệt giữa replication không đồng bộ và replication gần đồng bộ

1. Replication không đồng bộ

Replication không đồng bộ trả lời client ngay khi master server hoàn thành giao dịch. Nghĩa là, ngay cả khi việc đồng bộ dữ liệu tới slave server bị trễ, master vẫn có thể xử lý các yêu cầu mới. Do đó, nó có hiệu năng phản hồi tốt và phù hợp với các hệ thống mục tiêu cân bằng tải. Tuy nhiên, cần lưu ý rằng khi có sự cố, dữ liệu chưa được phản ánh lên slave server có thể bị mất.

2. Replication gần đồng bộ

Replication gần đồng bộ chỉ trả lời client sau khi master xác nhận việc truyền dữ liệu tới slave đã hoàn tất. Điều này nâng cao tính nhất quán của dữ liệu, nhưng thời gian phản hồi của giao dịch có thể lâu hơn do phải chờ dữ liệu được phản ánh trên slave. Replication gần đồng bộ phù hợp với các hệ thống yêu cầu tính nhất quán dữ liệu cao hoặc môi trường ưu tiên độ tin cậy của dữ liệu.

Replication sử dụng GTID

GTID (Global Transaction Identifier) là cơ chế gán ID duy nhất cho mỗi giao dịch, giúp duy trì tính nhất quán của giao dịch trên master và slave. Khi bật GTID, việc quản lý replication trở nên dễ dàng hơn so với phương pháp replication dựa trên vị trí binary log truyền thống.

Lợi ích của GTID

  • cải thiện tính nhất quán dữ liệu: Nhờ GTID, slave có thể tự động nhận biết các giao dịch chưa được áp dụng, do đó tính nhất quán dữ liệu dễ được duy trì.
  • đơn giản hoá việc quản lý replication: Khi sử dụng GTID, việc chuyển đổi hoặc khôi phục master và slave trở nên hiệu quả. Không cần chỉ định vị trí binary log, nên quản lý trở nên đơn giản.

Cấu hình replication GTID

Để sử dụng GTID, cần thêm các tùy chọn sau vào file cấu hình của master và slave và bật chúng. Cấu hình máy chủ master
[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON
Cấu hình máy chủ slave
[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON
Trong môi trường đã bật GTID, chỉ cần sử dụng lệnh CHANGE MASTER TO để thiết lập thông tin master cho slave, replication dựa trên GTID sẽ tự động thực hiện. Trong phần tiếp theo, chúng tôi sẽ giải thích cách bảo trì MySQL replication và các điểm quan trọng trong việc giám sát quản trị vận hành.

5. Bảo trì và Giám sát Replication

Để vận hành MySQL Replication một cách thích hợp, việc bảo trì và giám sát định kỳ là không thể thiếu. Phần này sẽ giải thích các lệnh để kiểm tra xem replication có hoạt động bình thường không, cũng như cách xử lý các lỗi thường gặp.

Cách kiểm tra trạng thái Replication

Để nắm bắt trạng thái replication, sử dụng các lệnh dưới đây để kiểm tra tình trạng đồng bộ giữa master và slave.

Kiểm tra trạng thái Master

Trạng thái replication trên máy chủ master có thể được kiểm tra bằng lệnh SHOW MASTER STATUS. Lệnh này hiển thị tên file binary log hiện tại và vị trí (position), cho phép xác nhận các cập nhật mới nhất sẽ được truyền cho slave.
SHOW MASTER STATUS;
Kết quả của lệnh này bao gồm các mục sau.
  • File: Tên file binary log hiện tại mà master đang xuất.
  • Position: Vị trí hiện tại trong binary log.
  • Binlog_Do_DB và Binlog_Ignore_DB: Các cơ sở dữ liệu được replication.

Kiểm tra trạng thái Slave

Trạng thái replication trên máy chủ slave có thể được kiểm tra bằng lệnh SHOW SLAVE STATUS. Kết quả của lệnh này chứa thông tin để đánh giá xem slave có hoạt động bình thường không.
SHOW SLAVE STATUSG;
Các mục quan trọng bao gồm:
  • Slave_IO_Running và Slave_SQL_Running: Nếu cả hai đều là Yes, cho thấy slave đang hoạt động bình thường.
  • Seconds_Behind_Master: Thời gian (giây) slave chậm so với master. Thông thường, giá trị 0 là lý tưởng.

Khắc phục sự cố Replication

Các vấn đề thường gặp khi vận hành replication bao gồm lỗi kết nối và không đồng nhất dữ liệu. Dưới đây là các thông báo lỗi phổ biến và cách xử lý.

1. Lỗi kết nối

Nếu Slave_IO_Running là No, nghĩa là slave không thể kết nối tới master. Hãy thử các biện pháp sau.
  • Kiểm tra tên host hoặc địa chỉ IP của máy chủ master: Đảm bảo địa chỉ master đúng.
  • Kiểm tra cấu hình tường lửa: Đảm bảo cổng cần thiết (thường là 3306) được mở.

2. Không đồng nhất dữ liệu

Nếu Last_Error chứa nội dung lỗi, có khả năng dữ liệu giữa master và slave không đồng nhất. Khi xảy ra, cần dừng slave tạm thời và thực hiện sửa chữa.
STOP SLAVE;
# Khởi động lại sau khi sửa chữa
START SLAVE;

3. Giải quyết độ trễ

Nguyên nhân gây độ trễ cho slave có thể là hiệu năng phần cứng của slave hoặc vấn đề mạng. Khi cần, việc tăng cường cấu hình của slave có thể cải thiện. Trong phần tiếp theo, chúng ta sẽ đi sâu hơn vào chi tiết các sự cố trong replication và cách giải quyết chúng.

6. Các sự cố thường gặp và cách khắc phục

Trong MySQL Replication, có thể phát sinh nhiều sự cố trong quá trình vận hành. Ở đây, chúng tôi sẽ giải thích chi tiết về các sự cố thường gặp và cách khắc phục chúng. Bằng cách phát hiện sớm vấn đề và xử lý kịp thời, bạn có thể duy trì hoạt động ổn định của hệ thống.

1. Trường hợp Slave_IO_Running bị dừng

Hiện tượng：Nếu trong kết quả của lệnh SHOW SLAVE STATUS, Slave_IO_Running hiển thị No, điều này cho thấy slave không thể kết nối tới master. Nguyên nhân và biện pháp：
  • Vấn đề mạng：Khi có sự cố kết nối mạng, slave sẽ không thể truy cập master. Kiểm tra cấu hình tường lửa và đảm bảo có thể truy cập được master.
  • Lỗi cấu hình tên host hoặc địa chỉ IP của master：Hãy kiểm tra xem tên host hoặc địa chỉ IP được chỉ định trong CHANGE MASTER TO có đúng không.
  • Vấn đề quyền người dùng：Nếu người dùng replication được tạo trên master không có đủ quyền, kết nối sẽ thất bại. Kiểm tra quyền bằng cách sử dụng GRANT REPLICATION SLAVE.

2. Dữ liệu không đồng nhất trên slave

Hiện tượng：Khi dữ liệu giữa slave và master không khớp, dữ liệu trên slave có thể trở nên không đồng nhất. Nguyên nhân và biện pháp：
  • Sửa dữ liệu thủ công：Khi phát hiện không đồng nhất, dừng slave, sửa giao dịch gây lỗi bằng tay. Sau khi sửa, khởi động lại slave để khôi phục replication. STOP SLAVE; # Sửa dữ liệu nếu cần START SLAVE;
  • Đồng bộ lại dữ liệu：Nếu không đồng nhất quy mô lớn, lấy bản sao lưu toàn bộ dữ liệu từ master và thực hiện đồng bộ lại trên slave.

3. Độ trễ của replication

Hiện tượng：Nếu trong kết quả của SHOW SLAVE STATUS, Seconds_Behind_Master không phải 0, điều này cho thấy slave đang bị trễ so với master. Thông thường, giá trị càng nhỏ càng tốt. Nguyên nhân và biện pháp：
  • Hiệu năng phần cứng của slave：Nếu thông số máy chủ slave thấp, quá trình xử lý không kịp và gây ra độ trễ. Nâng cấp phần cứng là giải pháp hiệu quả.
  • Tối ưu hóa truy vấn：Khi các truy vấn từ master mất nhiều thời gian để thực thi trên slave, sẽ gây độ trễ. Thêm chỉ mục và tối ưu truy vấn để rút ngắn thời gian xử lý.

4. Lỗi quyền của người dùng replication

Hiện tượng：Nếu Last_Error hiển thị thông báo lỗi liên quan đến quyền, có thể slave không có quyền cần thiết để kết nối tới master. Nguyên nhân và biện pháp：
  • Gán quyền lại：Kiểm tra xem người dùng có quyền phù hợp đã được tạo trên master chưa, và nếu cần, thực hiện gán lại. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'địa chỉ IP của slave'; FLUSH PRIVILEGES;

5. Tăng kích thước log nhị phân

Hiện tượng：Log nhị phân trên master có tăng kích thước, gây áp lực lên dung lượng đĩa của server. Nguyên nhân và biện pháp：
  • Quay vòng log nhị phân：Xóa hoặc lưu trữ log nhị phân định kỳ để ngăn tăng kích thước. Bằng cách thiết lập expire_logs_days, các log đã qua thời gian nhất định sẽ tự động bị xóa. SET GLOBAL expire_logs_days = 7; # Xóa log cũ hơn 7 ngày
Như vậy, nắm bắt các sự cố thường gặp và giải pháp trong MySQL Replication sẽ giúp quản lý vận hành một cách suôn sẻ. Trong phần tiếp theo, chúng tôi sẽ tổng kết lại các điểm quan trọng của việc vận hành replication.

7. Tóm tắt

MySQL Replication là một chức năng quan trọng để nâng cao tính nhất quán dữ liệu và độ tin cậy của hệ thống. Bài viết này đã giải thích chi tiết từ khái niệm cơ bản của MySQL Replication, quy trình thiết lập, đến việc giám sát và khắc phục sự cố trong quản lý vận hành. Cuối cùng, chúng tôi tổng hợp các điểm quan trọng trong quản lý vận hành replication dưới đây.

Nhìn lại các điểm quan trọng

  1. Các loại replication và lựa chọn
  • Replication bất đồng bộ có ưu điểm về tốc độ phản hồi và tối ưu cho cân bằng tải, nhưng nếu cần độ tin cậy thì replication bán đồng bộ là phù hợp. Hãy chọn phương thức thích hợp dựa trên yêu cầu của hệ thống.
  1. Tận dụng GTID
  • Bằng cách sử dụng GTID, bạn có thể quản lý giao dịch một cách suôn sẻ mà không cần chỉ định vị trí của binary log. Đặc biệt hữu ích trong môi trường có nhiều slave hoặc hệ thống cần phục hồi sau sự cố.
  1. Kiểm tra trạng thái định kỳ
  • Việc sử dụng các lệnh SHOW MASTER STATUS và SHOW SLAVE STATUS để giám sát định kỳ tình trạng hoạt động của master và slave là rất quan trọng. Khi phát hiện bất thường, xử lý nhanh chóng sẽ giảm thiểu tối đa rủi ro không đồng bộ dữ liệu và độ trễ.
  1. Nắm vững các kỹ thuật khắc phục sự cố chung
  • Replication MySQL thường gặp các sự cố đặc thù như lỗi kết nối slave, không đồng bộ dữ liệu, độ trễ, v.v. Hiểu các phương pháp giải quyết cơ bản cho từng vấn đề sẽ giúp xử lý sự cố trong quá trình vận hành một cách suôn sẻ.
  1. Quản lý binary log
  • Khi binary log trở nên lớn, dung lượng đĩa của máy chủ sẽ bị áp lực, vì vậy nên sử dụng cài đặt expire_logs_days để tự động xóa và thực hiện bảo trì định kỳ.
MySQL Replication không chỉ dừng lại sau khi thiết lập một lần; việc giám sát hàng ngày và bảo trì thích hợp là không thể thiếu. Bằng cách kiểm tra trạng thái định kỳ và điều chỉnh cấu hình khi cần, bạn có thể xây dựng và duy trì hệ thống cơ sở dữ liệu có độ tin cậy cao. Hy vọng bài viết này sẽ hữu ích cho việc hiểu và triển khai MySQL Replication. Chúc việc vận hành replication trong tương lai của bạn diễn ra suôn sẻ.