MYSQL
Replication đƣợc sử dụng để sao lƣu tất cả các câu lệnh thực thi hoặc tập dữ liệu thay đổi đƣợc tạo ra trên một máy chủ (đƣợc gọi là master server hay ngắn gọn là master) đến các server khác, các server này đƣợc gọi là slave server (hay ngắn gọn là slave).
Đối với MySQLD thì một slave có duy nhất một master. Tuy nhiên, một master có thể có nhiều slave. Thêm vào đó, một master có thể là một slave của một master khác. Điều này phụ thuộc vào các mô hình replication đƣợc xắp đặt nhƣ thế nào.
Trong MySQL, quá trình tạo bản sao là quá trình một chiều và không đồng bộ. Bởi vì quá trình đồng bộ dữ liệu không xảy ra trong thời gian thực. Khi có sự thay đổi dữ liệu trên master thì master ghi các sự kiện vào file Binary log, và lập tức gửi file Binary log đến slave để đồng bộ dữ liệu với slave. Master không quan tâm đến trạng thái của bất kỳ slave nào, nó không biết đƣợc slave đã đƣợc đồng bộ dữ liệu hay chƣa. Điều này làm giảm đƣợc độ trễn giữa master và các slave do không cần mất thời gian các slave biên nhận việc đồng bộ dữ liệu trên chúng đã thành công hay chƣa gửi đến master.
3.2.1.Một số file log đƣợc sử dụng trong MySQLD Binary log
Binary log là một file log đƣợc MySQLD sử dụng trong máy chủ master để ghi lại những thay đổi và những câu lệnh làm thay đổi cơ sở dữ liệu, từ đó có thể sử dụng nó để phục hồi cơ sở dữ liệu. Nội dung của binary log chứa bất kỳ các câu lệnh nào mà xảy ra trong khi máy chủ đang sửa chữa cơ sở dữ liệu: CREATE, INSERT, UPDATE, DROP, DELETE. Các câu lệnh không làm thay đổi cơ sở dữ liệu nhƣ câu lệnh SELECT thì không đƣợc ghi vào file Binary log. Tuy nhiên, một câu lệnh không làm thay đổi cơ sở dữ liệu sẽ đƣợc ghi vào Binary log, nếu nó là một phần của giao dịch nhƣ giao dịch sửa dữ liệu, bởi vì giao dịch sẽ đƣợc ghi vào file Binary log.
Để kích hoạt binary log, sử dụng tùy chọn : log-bin. File binary-log-index là một file text đơn giản mà theo giõi các file Binary log hiện hành. Mặc định, nó có tên là
mysql-bin.index. Để thiết lập tên file và đƣờng dẫn của binary log và binary log index
file, làm theo tùy chọn sau:
38
# log-bin-index - /data/logs/relay/binarylog.index
Dữ liệu của binary log đƣợc chứa trong định dạng nhị phân. Do vậy, không thể mở file với một trình soạn thảo văn bản và đọc nó. Để hiển thị binary log trong định dạng văn bản hoặc có khả năng đọc đƣợc thì bạn phải sử dụng công cụ mysqlbinlog.Thao tác của công cụ mysqlbinlog khá đơn giản.
Trong ví dụ dƣới đây, nội dung ghi trong binary log: mysql-bin.00001 đƣợc chuyển sang định dạng văn bản và sao chép trong file mới là output.sql:
# mysqlbinlog mysql-bin.00001 > output.sql
Nếu để là > output.sql thì nội dung sẽ đƣợc gửi đến giao diện điều khiển.
Relay log
Relay log đƣợc sử dụng bởi slave để sao lƣu các sự kiện nhận đƣợc từ máy chủ master trƣớc khi thực thi trên máy chủ slave. Chúng dùng định dạng nhị phân giống nhƣ file Binary log và chúng có thể đƣợc hiển thị nhờ việc sử dụng công cụ mysqlbinlog. Mặc định một máy chủ slave lƣu trữ relay logs trong datadir. Ngoài file Relay log, trên máy chủ slave còn có file relay-log.index, và relay-log.info. Relay-log.index đƣợc sử dụng để theo dõi các relay log đang đƣợc sử dụng hiện hành. Relay-log.info ngoài việc cung cấp tài liệu về việc sử dụng file log hiện hành, nó còn cung cấp vị trí của nó, và vị trí của file
Binary log trong master.
3.2.2.Các mô hình replication:
Mô hình replication đề cập đến những cách khác nhau kết nối các máy sử dụng replication.
39
Mô hình đơn giản: master – slave
Hình 14: Mô hình replication đơn giản master – slave trong MySQL
Mô hình master – salve bao gồm một master và một slave. Tất cả những thay đổi về cơ sở dữ liệu trên master đƣợc gửi đến slave để đồng bộ dữ liệu. Khi client truy suất đến cơ sở dữ liệu, với những truy vấn ghi thì master sẽ đảm nhận, tất cả các truy vấn đọc sẽ đƣợc slave trả lời. MySQL proxy chịu trách nhiệm lọc các truy vấn ghi hay đọc để gửi đến master hay slave.
Mô hình master – multi slave
Hình 15: Mô hình replication master – multi slave trong MySQL
Mô hình master – multi slave là mô hình mà một master kết nối với nhiều slave. Khác với mô hình master – slave thì mô hình này master không chỉ đồng bộ dữ liệu với
40
một slave mà master phải gửi tất cả những dữ liệu thay đổi trên nó đến toàn bộ slave. Các slave đƣợc phân biệt với nhau bằng các server-id duy nhất (server-id là một số nguyên, mỗi slave có duy nhất một server-id). server-id đƣợc chỉ định trong file cấu hình của MySQLD. Trong mô hình này thì master sẽ trả lời tất cả các truy vấn ghi từ client và các truy vấn đọc sẽ đƣợc MySQL Proxy gửi đều đến tất cả slave.
Mô hình master – relay server
Hình 16: Mô hình master – relay slave trong MySQL
Trong hai mô hình trên, master vừa đảm nhận công việc là trả lời các truy vấn ghi từ client vừa phải ghi các sự kiện vào file Binary log để đồng bộ dữ liệu đến các slave. Khi số lƣợng truy cập của client lớn, nhu cầu thêm các slave là cần thiết để đáp ứng đƣợc tất cả các truy vấn của client. Nhƣng điều này cũng làm tăng công việc của master lên rất nhiều. Để giảm tải công việc cho master thì một relay slave đƣợc sử dụng. relay slave không chịu trách nhiệm trả lời các truy vấn từ client. Khi có sự thay đổi về cơ sở dữ liệu trên master, thay vì master phải đồng bộ đến tất cả slave thì master chỉ gửi file Binary log đến relay server. Công việc đồng bộ dữ liệu cho các slave bây giờ đƣợc giao cho relay server. Ngoài nhiệm vụ đồng bộ dữ liệu, relay slave đƣợc coi nhƣ một máy chủ hot- standby – máy chủ chờ nóng. Điều này có nghĩa là, khi master gặp sự cố, không thể tiếp tục hoạt động thì relay slave đƣợc MySQL proxy chỉ định ngay tức khắc thay thế cho master. Lúc này, relay slave đƣợc coi nhƣ là master mới. Tất cả các truy vấn ghi từ client đƣợc MySQL proxy gửi đến master mới này. Sau khi master cũ khắc phục đƣợc sự cố, nó tiếp tục hoạt động với vai trò của mình và relay slave quay về vị trí là hot-standby.
41
Mô hình master – master
Hình 17: Mô hình replication master – master trong MySQL
Mô hình này có hai master, server A vừa là master của server và đồng thời cũng là slave của server B, tƣơng tự cho server B. Cả hai máy chủ A và B nhận cả các truy vấn đọc và truy vấn ghi. Cả hai máy chủ có khả năng nhận đồng thời các truy vấn INSERT một hàng vào một bảng với một trƣờng là auto-increment. Điều này thực hiện đƣợc là do cả hai máy chủ A và B đều đƣợc cấu hình với:
auto_increment_increment = integer auto_increment_offset = integer
Giá trị của auto_increment_increment xác định khoảng tăng giữa các giá trị auto_increment và nên giống nhau ở mỗi máy chủ. Giá trị này ít nhất phải là số máy chủ trong mạng vòng – nếu mạng vòng có 2 máy chủ thì giá trị của auto_increment_increment nhỏ nhất là 2. Giá trị của auto_increment_offset nên khác nhau giữa các máy chủ.
Ví dụ: thiết lập giá trị của auto_increment cho hai máy chủ A và B nhƣ sau:
# Server A
auto_increment_increment = 10 auto_increment_offset = 1 # Server B
42
auto_increment_offset = 2
Trong ví dụ này thì khoảng tăng là 10, câu lệnh INSERT đầu tiên đến một bảng sẽ bắt đầu với giá trị 1 tại máy chủ A, tại máy chủ B sẽ có giá trị là 2 trong lệnh INSERT tiếp theo. Câu lệnh tiếp theo có giá trị là 11 tại máy chủ A và 12 tại máy chủ B.
Mô hình master-master có khả năng chuyển đổi dự phòng cao. Nếu máy chủ A bị lỗi thì máy chủ B sẽ thay thế ngay lập tức, do vậy tính sẵn sàng của mô hình này rất cao. Tuy nhiên, do cả hai máy chủ đều thực thi tất cả các câu lệnh ghi nên hiệu suất không cao [6].