NGHIÊN CỨU THỬ NGHIỆM GIẢI PHÁP CÂN BẰNG TẢI VÀ CHỊU LỖI CHO HỆ QUẢN TRỊ CSDL MYSQL VỚI MYSQL REPLICATION VÀ MYSQL CLUSTER

HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI THỰC TẬP CƠ SỞ

NGHIÊN CỨU THỬ NGHIỆM GIẢI
PHÁP CÂN BẰNG TẢI VÀ CHỊU LỖI
CHO HỆ QUẢN TRỊ CSDL MYSQL
Cán bộ hướng dẫn: Nguyễn Hồng Việt
Sinh viên thực hiện:
-

Vũ Xuân Sơn
Lương Văn Chưởng
Nguyễn Thị Thêu

Lớp: AT9B

HÀ NỘI 2015

HÀ NỘI 12/2013
1


HỌC VIỆN KỸ THUẬT MẬT MÃ
KHOA CÔNG NGHỆ THÔNG TIN

ĐỀ TÀI THỰC TẬP CƠ SỞ

NGHIÊN CỨU THỬ NGHIỆM GIẢI
PHÁP CÂN BẰNG TẢI VÀ CHỊU LỖI

CHO HỆ QUẢN TRỊ CSDL MYSQL

Nhận xét của cán bộ hướng dẫn:.........................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
.............................................................................................................................................
Điểm chuyên cần:..................................................................................................................
Điểm báo cáo:.......................................................................................................................

Xác nhận của cán bộ hướng dẫn

2


MỤC LỤC

Danh sách các từ viết tắt
STT
1
2
3
4

Từ viết tắt Từ Tiếng Anh
Từ Tiếng Việt
CPU
Central Processing Unit Đơn vị xử lý trung tâm
RAM
Random Access Memory Bộ nhớ truy cập ngẫu

nhiên
CSDL
Database
Cơ sở dữ liệu
MGM
Management
Quản lý
3


Danh sách các bảng:
Bảng 1: Cấu hình máy sử dụng cho mô hình Replication kết hợp keepalived ...…30
Bảng 2: Kết quả truy vấn trường hợp client gửi truy vấn trực tiếp đến 1 server….32
Bảng 3: Kết quả truy vấn trường hợp client gửi truy vấn ip ảo do keepalived sinh
ra……………………………………………………………………………….…..32
Bảng 4: Cấu hình máy sử dụng cho mô hình Cluster kết hợp keepalived……….. 34
Bảng 5: Kết quả truy vấn trường hợp client gửi truy vấn trực tiếp đến 1 server (mô
hình cluster) …………………………………………………………………….…36
Bảng 6: Kết quả truy vấn trường hợp client gửi truy vấn đến ip ảo do keepalived
sinh ra. (mô hình cluster) …………………………………………………………36

Danh sách hình vẽ:
Hình 1:Mô tả cuộc tấn công từ chối dịch vụ ……………………………….….10
Hình 2:Mô hình Replication master-slave:…………………………………….19
Hình 3:Mô hình Replication master- multi slave ……………………………..20
Hình 4:Mô hình Replication master- relay server ……..………………………21
Hình 5:Mô hình Replication master- master …………………………………..22
Hình 6:Mô hình sử dụng kết hợp Replication và keepalived ………………….23
Hình 7:Mô hình sử dụng MySQL-Cluster kết hợp keepalived ………………..28
4

Hình 8:Mô hình sử dụng giải pháp replication kết hợp keepalived …………...29
Hình 9:Trạng thái của master ………………………………………………….31
Hình 10:Cấu hình trên salve …………………………………………………...31
Hình 11: Mô hình giải pháp clustering kết hợp keepalived …………………...32
Hình 12: Cấu hình file my.cnf trên 2 node ………………………………….....35
Hình 13: Cấu hình file config.ini trên Management …………………………...36
Hình 14: Kiểm tra kết nối ……………………………………………………...36
Hình 15: Mô hình thực tiễn ứng dụng kết hợp replication + clustering với
keepalived ……………………………………………………………………...37

Lời nói đầu
Sự bùng nổ của internet trong những năm gần đây khiến số lượng người dùng
truy cập qua internet đến các máy chủ cơ sở dữ liệu ngày càng tăng mạnh. Với
hàng triệu lượt truy cập mỗi ngày thì đòi hỏi hệ thống máy chủ cơ sở dữ liệu phải
cực kỳ mạnh mẽ, nếu không máy chủ sẽ bị quá tải. Một hệ thống máy chủ mạnh
mẽ là hệ thống có khả năng đáp ứng được tất cả các truy vấn của client trong
khoảng thời gian nhanh nhất – hệ thống có khả năng cân bằng tải. Bên cạnh khả
năng cân bằng tải, thì hệ thống cũng cần có khả năng mở rộng và tính sẵn sàng
cao.Ba yếu tố này liên hệ chặt chẽ với nhau để đảm bào hệ thống hoạt động ổn
5


định.Nếu một hệ thống không đảm bảo được ba yếu tố trên thì thảm họa sẽ xảy ra
bất cứ lúc nào.Cụ thể đề tài sẽ nghiên cứu về giải pháp cân bằng tải cho máy chủ
cơ sở dữ liệu MySQL
Hệ quản trị CSDL MySQL đã trở thành hệ quản trị CSDL mã nguồn mở phổ
biến nhất thế giới. Bởi vì MySQL có hiệu suất cao, độ tin cậy cao và dễ sử dụng .
MySQL chạy trên hơn 20 nền tảng bao gồm cả Linux, Windows, Mac OS, Solaris,

IBM AIX, tạo ra sự linh hoạt để kiểm soát. Bên cạnh đó, MySQL cung cấp một
loạt các công cụ cơ sở dữ liệu, hỗ trợ, đào tạo và các dịch vụ tư vấn để quản trị cơ
sở dữ liệu thành công. Nó cũng là hệ quản trị CSDL của sự lựa chọn cho một thế
hệ ứng dụng mới được xây dụng trên LAMP (Linux, Apache, MySQL / Perl /
Python). Nhiều tổ chức lớn nhất thế giới và phát triển nhanh nhất bao gồm
Facebook, Google, Adobe, Alcatel Lucent, Youtube, và Zappos đều dựa trên
MySQL để tiết kiệm thời gian, tiền bạc và cung cấp hiệu suất cao cho các Website,
các hệ thống kinh doanh quan trọng và các phần mềm đóng gói.
Đã có rất nhiều phương pháp cân bằng tải được đưa ra cho hệ quản trị CSDL
MySQL. Tuy nhiên nhiều phương pháp không giải quyết được triệt để cả ba yếu tố
trên cho máy chủ cơ sở dữ liệu MySQL.Vì vậy,trong đề tài nghiên cứu này sẽ đưa
ra hai giải pháp sử dụng mô hình MySQL-Replication và MySQL-Cluster kết hợp
sử dụng Keepalived để cân bằng tải cho các máy chủ cơ sở dữ liệu MySQL.Các
giải pháp này không chỉ đáp ứng được yêu cầu cân bằng tải mà còn đáp ứng được
nhu cầu mở rộng và đảm bảo tính sẵn sàng cao của hệ thống. Ngoài ra, nó còn có ý
nghĩa trong việc nghiên cứu và phát triển các giải pháp cân bằng tải tốt hơn khi số
lượng người dùng truy cập tăng lên rất nhiều. Do các truy cập đến máy chủ cơ sở
dữ liệu chủ yếu là đọc dữ liệu, nên khóa luận tập trung nghiên cứu về giải
pháp cân bằng tải cho máy chủ cơ sở dữ liệu MySQL cho các truy vấn đọc.
Từ đó đưa ra nhiều lựa chọn cho người dùng,doanh nghiệp…v.v
Chương 1: Trình bày về các nguyên nhân gây quá tải máy chủ, từ đó xác định
tínhcần thiết của việc cân bằng tải cho các hệ quản trị CSDL nói chung và cho

6


hệ quản trịCSDL MySQL. Chương 1 cũng giới thiệu về các tiêu chí đánh giá tải
và hiệu năng của máy chủ.
Chương 2: Trình bày các giải pháp cân bằng tải-chịu lỗi cho hệ quản trị CSDL
MySQL

CHƯƠNG I: Sự cần thiết của việc cân bằng tải,chịu
lỗi cho hệ quản trị CSDL MySQL
Nguyên nhân gây ra quá tải máy chủ
1.1.1 Số lượng truy cập hợp lệ đến máy chủ quá lớn

1.1

Trong một khoảng thời gian ngắn có thể có đến hàng nghìn hoặc thậm chí là
hành triệu client kết nối đến server. Do vậy, nếu hệ thống server không mạnh thì
việc quá tải server là không thể tránh khỏi.
Những yêu cầu truy cập từ client đến server đƣợc phân chia thành hai loại:
- Truy vấn ghi: các client gửi yêu cầu ghi vào cơ sở dữ liệu của server. Các yêu
cầu ghi này là: CREATE (cơ sở dữ liệu, bảng,..), UPDATE (dữ liệu), INSERT
7


(dữ liệu vào bảng) và DELETE (hàng, trường dữ liệu) hay DROP (bảng, cơ sở dữ
liệu,...)
- Truy vấn đọc: các client gửi yêu cầu đọc một hoặc nhiều đối tượng trong cơ sở
dữ liệu của server. Các yêu cầu đọc này là: SELECT.
Trong số các truy vấn từ client đến server thì phần lớn là các truy vấn đọc. Bởi
vì đối với các ứng dụng web thì người dùng thường yêu cầu hiển thị dữ liệu nhiều
hơn là cập nhật dữ liệu.
Bên cạnh đó, nếu server được bảo dưỡng, hoặc nâng cấp một phần cứng hay một
phần mềm bị thất bại thì một tài nguyên nào đó của server không có sẵn. Khi
client kết nối đến server và cần dùng tài nguyên này thì nó sẽ phải chờ và với một
lượng truy cập lớn server sẽ bị quá tải.

1.1.2

Máy chủ bị tấn công

-Tấn công từ chối phân tán dịch vụ (Distributed Denial of Service attacks)
Một tấn công từ chối dịch vụ (DoS attack) hay tấn công từ chối phân tán dịch
vụ (DDoS attack) là một xâm phạm để làm cho một tài nguyên máy tính hoặc
tài nguyên mạng không có sẵn đối với người sử dụng.
Thủ phạm của cuộc tấn công DoS thường nhằm đến mục tiêu là các website
hoặc các dịch vụ lưu trữ trên web server cấu hình cao như ngân hàng, cổng
thanh toán thẻ tín dụng hay thậm chí là cả root nameserver.

Hình 1:Mô tả cuộc tấn công từ chối dịch vụ

8


Một phương pháp phổ biến của cuộc tấn công liên quan đến bão hòa server
với các yêu cầu thông tin liên lạc bên ngoài. Nó buộc server phải thiết lập lại
hoặc tiêu thụ tài nguyên của server để server không thể cung cấp dịch vụ dự
định của mình, cản trở các phương tiện truyền thông giao tiếp giữa client với
server. Do vậy, server không thể đáp ứng được các truy vấn hợp lệ của client
hoặc đáp ứng rất chậm. Các cuộc tấn công như vậy thường dẫn đến tình trạng
quá tải của server.
-Phần mềm độc hại (Sâu máy tính,Viruss XSS)
Là những phần mềm độc hại,một chương trình độc hại mà nó có thể tự tái tạo
để lây lan ra các máy tính khác.Thông thường các phần mềm độc hại này sử
dụng một mạng lưới để lây lan,do vậy mạng lưới có đó có thể bị kiểm soát bởi
tác giả.Các phần mềm độc hại này gây ra sự gián đoạn lớn bằng cách làm tăng
9

lưu lượng mạng,gây ra lượng truy cập cao trong khoảng thời gian rất ngắn.Hơn
nữa,mạng lưới này có thể được sử dụng cho một cuộc tấn công từ chối dịch
vụ,gây thiệt hại lớn cho người sử dùng.
1.1.3. Internet
- Internet bots
Internet bots (Botnet) còn được gọi là web robots, WWW robots hay đơn
giản là bots, là ứng dụng phần mềm tự động thực thi các nhiệm vụ trên mạng
Internet. Thông thường Bot thực hiện các nhiệm vụ đơn giản được lập trình
sẵn và có cấu trúc lặp đi lặp lại với tốc độ cao hơn một người bình thường.
Một Botnet được định nghĩa là một “mạng gồm rất nhiều máy tính bị xâm
nhập và có thể được kẻ tấn công điều khiển từ xa”. “Máy tính bị xâm nhập”
là máy tính bị lây nhiễm phần mềm độc hại (Bot). Như vậy, Botnet là tập hợp
các Bot được sử dụng với mục đích xấu. Botmaster là một người hoặc một
nhóm người điều khiển Botnet.
Mục đích kiểm soát Botnets của tin tặc là một số hình thức hoạt động bất hợp
pháp. Những hoạt động này bao gồm, tấn công từ chối dịch vụ phân tán
(DDoS), phát tán thư giác (spamming), theo dõi lưu lượng dữ liệu trên hệ
thống mạng (sniffing network traffic), theo dõi bàn phím (keylogging), phát
tán mã độc (spreading malware), v.v.. [2]
Nếu lưu lượng không được lọc hoặc giới hạn trên các web site lớn với
rất ít tài nguyên (như băng thông, v.v…) thì sẽ gây ra tình trạng quá tải cho
server.

1.2

Khái niệm cân bằng tải và chịu lỗi-Sự cần thiết đối với hệ quản
trị CSDL MySQL

10

1.2.1 Khái niệm cân bằng tải.
Cân bằng tải là một phương pháp phân phối khối lượng tải trên nhiều máy tính
hoặc một cụm máy tính để có thể sử dụng tối ưu các nguồn lực, tối đa hóa thông
lượng, giảm thời gian đáp ứng và tránh tình trạng quá tải trên máy chủ.

1.2.2 Khái niệm chịu lỗi trên CSDL. (High Availability)
High Availability có nghĩa là “Độ sẵn sàng cao“,Các tài nguyên mạng phải luôn
sẵn sàng trong khả năng cao nhất để cung cấp và phục vụ các người dùng cuối và
giảm thiểu sự ngưng hoạt động hệ thống ngoài ý muốn. Để đảm bảo được điều đó,
tối thiểu có một cặp máy, thiết bị chạy song song, liên tục liên lạc với nhau, cái
chính hỏng, cái phụ sẽ lập tức biết và tự động thay thế.

1.2.3 Sự cần thiết của việc cân bằng tải và chịu lỗi đối với hệ quản
trị CSDL.
Hệ quản trị CSDL MySQL đã trở thành hệ quản trị CSDL mã nguồn mở phổ
biến nhất thế giới. Bởi vì MySQL có hiệu suất cao, độ tin cậy cao và dễ sử dụng.
MySQL chạy trên hơn 20 nền tảng bao gồm cả Linux, Windows, Mac OS, Solaris,
IBM AIX, tạo ra sự linh hoạt để kiểm soát. Bên cạnh đó, MySQL cung cấp một
loạt các công cụ cơ sở dữ liệu, hỗ trợ, đào tạo và các dịch vụ tư vấn để quản trị cơ
sở dữ liệu thành công. Nó cũng là hệ quản trị CSDL của sự lựa chọn cho một thế
hệ ứng dụng mới được xây dụng trên LAMP (Linux, Apache, MySQL / Perl /
Python). Nhiều tổ chức lớn nhất thế giới và phát triển nhanh nhất bao gồm
Facebook, Google, Adobe, Alcatel Lucent, Youtube, và Zappos đều dựa trên
MySQL để tiết kiệm thời gian, tiền bạc và cung cấp năng lượng cao cho các
Website, các hệ thống kinh doanh quan trọng và các phần mềm đóng gói.
Cũng như các hệ quản trị CSDL khác, với sự phổ biến của mình, hệ quản trị
CSDL MySQL cần thiết phải được cân bằng tải. Ban đầu khi triển khai hệ thống
Website các doanh nghiệp, tổ chức thường hay chọn giải pháp Webserver và

Database Server trên cùng một server. Giải pháp này giúp các doanh nghiệp tiết
11


kiệm được khá nhiều chi phí đầu tư thiết bị phần cứng, nhưng sau thời gian đưa
vào vận hành thì server hiện tại không thể đáp ứng được nhu cầu truy cập rất lớn
của người dùng hoặc quá trình truy cập rất chậm. Ngoài ra, khi server gặp sự cố thì
tất cả các hoạt động của nó bị ngừng lại làm cho các hoạt động của doanh nghiệp
cũng bị ảnh hưởng nghiêm trọng và có thể gây ra tổn thất rất lớn đến uy tín và tài
chính của doanh nghiệp.
Doanh nghiệp đã nghĩ đến giải pháp sao lưu và phục hồi dữ liệu. Một phần hay
toàn bộ cơ sở dữ liệu của doanh nghiệp được sao lưu, hay chỉ sao lưu các thông tin
biểu diễn cấu trúc cơ sở dữ liệu như tạo cơ sở dữ liệu (CREAT DATABASE), tạo
bảng (CREAT TABLE) và nội dung của các câu lệnh làm thay đổi cơ sở dữ liệu
như câu lệnh INSERT. Nếu các sự kiện như nguồn điện, hỏng thiết bị có thể làm
cho hỏng hoặc mất dữ liệu, thì giải pháp này tránh được tình trạng đó bằng cách
phục hồi dữ liệu đã được sao lưu. Tuy nhiên, giải pháp này chưa giải quyết được
vấn đề cân bằng tải cho server.
Hai giải pháp trên đều không khả thi khi thì giải pháp Replication cơ sở dữ liệu
và giải pháp sử dụng Cluster với bộ cân bằng tải Keepalived đã được đưa ra cho hệ
quản trị CSDL MySQL. Hai Giải pháp này đang được các doanh nghiệp ưu tiên
hàng đầu vì nó giải quyết được các vấn đề mà hai giải pháp trên chưa làm được:
cân bằng tải, khả năng mở rộng và tính sẵn sàng cao.Với sự vận dụng, kết hợp 2
giải pháp này,người dùng và doanh nghiệp sẽ giải quyết được các vấn đề trên một
cách tốt nhất
1.3

Một số tiêu chí đánh giá tải và hiệu năng của máy chủ.

1.3.1 CPU Utilization

CPU – đơn vị xử lý trung tâm – được xem như là bộ não của máy tính, nó là tài
nguyên quan trọng nhất vì nó liên quan trực tiếp đến khả năng xử lý, tính toán của
hệ thống. Tốc độ xử lý của CPU thường được tính theo số xung nhịp đồng hồ hoặc
số lượngphép tình cơ bản được thực hiện trong một giây. Đơn vị tốc độ được tính
theo MHz (tần số xung nhịp của đồng hồ trong một giây) hoặc MIPS (Million
Instruction Per Second – triệu phép tính cơ bản trong một giây).
12


CPU Utilization (hay còn được gọi là CPU usage) là tổng thời gian mà CPU
được sử dụng cho quá trình tính toán và xử lý một chương trình máy tính. CPU
Utilization là một trong những yếu tố đánh giá hiệu năng của máy chủ. Nếu tỉ lệ
phần trăm của CPU là cao thì thời gian xử lý một chương trình máy tính là lớn,
những chương trình khác muốn thực thi thì phải chờ cho đến khi CPU được giải
phóng, do vậy hiệu suất của máy chủ là thấp. Nếu tỉ lệ phần trăm của CPU thấp, thì
thời gian xử lý một chương trình máy tính là nhỏ, hiệu suất của máy tính là cao.
1.3.2. Memory usage
Memory – bộ nhớ - là một thành phần quan trọng của máy tính, được sử dụng để
lưu trữ các chương trình và dữ liệu trước khi chương trình được thi hành. Các đặc
trưng cơ bản của bộ nhớ là thời gian truy cập dữ liệu và dung lượng bộ nhớ. Thời
gian truy cập là khoảng thời gian cần thiết kể từ khi phát tín hiệu điều khiển
đọc/ghi đến khi việc đọc/ghi hoàn thành. Tốc độ truy cập là một yếu tố quyết định
đến tốc độ chung của máy tính. Dung lượng bộ nhớ chỉ khối lượng dữ liệu mà bộ
nhớ có thể lưu trữ đồng thời. Trong linux, yếu tố quan trọng trong việc xác định
hiệu suất là dung lượng bộ nhớ sẵn có trong RAM – bộ nhớ vật lý – và bộ nhớ ảo –
SWAP space.
1.3.3. Thời gian phản hồi.
Thời gian phản hồi các truy vấn của client gửi đến server chính là một yếu tố để
đánh giá tải và hiệu năng của máy chủ. Nếu thời gian phản hồi các truy vấn là thấp
thì hiệu suất của máy chủ cao, các truy vấn của client được đáp ứng nhanh mà

không có sự chậm chễ. Ngược lại, nếu thời gian phản hồi các truy vấn là lớn thì
hiệu suất của máy chủ giảm, client sẽ phải đợi một thời gian lâu để có kết quả trả
về từ máy chủ.

1.4. Xác định mục tiêu là tìm hiểu là các ứng dụng quá tải truy vấn
đọc.
Trong hầu hết các ứng dụng web như các website báo điện tử (dantri,
vnexpress,…), website chia sẻ trực tuyến (Youtube,…) hay các mạng xã hội thì
yêu cầu truy vấn dữ liệu của người dùng chủ yếu là truy vấn đọc (đọc tin tức,
13


xem video,…). Giả sử các truy vấn đọc xảy ra hàng giây thì truy vấn ghi xảy ra
hàng phút hoặc có thể là hàng giờ. Vì thế, tần suất các truy vấn đọc xảy ra là lớn
hơn rất nhiều so với các truy vấn ghi.
Do nhu cầu trên, nên tập trung tìm hiểu và thử nghiệm giải pháp cân bằng tải cho
các truy vấn đọc.

CHƯƠNG 2: Các giải pháp cân bằng tải-chịu lỗi cho
hệ quản trị CSDL MySQL
1.Giới thiệu về keepalived
Là 1 phần mềm định tuyến được viết bằng C, cung cấp 1 công cụ đơn giản và
mạnh mẽ cho việc cần bằng tải và HA cho hệ thống. Nói đơn giản hơn là
keepalived dùng để cung cấp IP Failover cho 1 cluster

2.Giải thuật cân bằng tải
Trong bài toán cân bằng tải, để chỉ định một trong số nhiều server nhận một truy
vấn của client và các server phải nhận được số truy vấn đều nhau đồng thời việc
chỉ định diễn ra nhanh nhất thì cần phải có một thuật toán để xác định server đó.
Giải thuật thuật Roun-robin

14


Giải thuật Roun-robin là giải thuật xoay vòng, đƣợc phát biểu nhƣ sau:
Input: Có N số lƣợng truy vấn đến server
K database server
Output: mỗi server nhận đƣợc N/K số truy vấn
Cách thực hiện:
Vòng 1
Query1 gửi về server1
Query2 gửi về server2
……
Queryk gửi về serverk

Vòng 2
Queryk+1 gửi về server1
Queryk+2 gửi về server2
….

….

Query2k gửi về serverk

Cứ tiếp tục quay vòng các server cho đến khi tất cả các truy vấn của client đƣợc
đáp ứng.
int roundRobin(int N, int K) {
for (i=0; ifor(j=0; jsend query[i] to server[j];

}
Đánh giá thuật toán:
Thuật toán đƣợc cài đặt đơn giản, do đó, thời gian để chỉ định server trả lời truy
vấn là rất nhanh, không làm tăng thời gian chờ của client. Đặc biệt, đối với thuật
toán này thì các server nhận được đồng đều các truy vấn của các client

15


2.Giải pháp sử dụng Replication với keepalived cho hệ quản trị CSDL
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ễ 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.
2.1 Một số filelog được sử dụng
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.
16


Để 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:
# log-bin - /data/logs/binary/changelog
# 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.(có thể
dùng vi,nano… để đọc
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.
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.
Mô hình đơn giản: master – slave:
Hình 2:Mô hình Replication master-slave:

17


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.
Mô hình master – multi slave:
Hình 3:Mô hình Replication master- multi slave:

18


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 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 MySQL

Mô hình master – relay server

Hình 4:Mô hình Replication master- relay server

19


Trong 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ủ hotstandby –
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 chỉ định ngay tức khắc thay thế cho master.
Lúc này, relay slave được coi như là master mới. 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.
20


Mô hình master – master
Hình 5:Mô hình Replication master- master:

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.
Mô hình sử dụng kết hợp Replication và keepalived :
Hình 6:Mô hình sử dụng kết hợp Replication và keepalived :

21


Trong mô hình trên,2 server sẽ được cấu hình theo kiểu master-master.Do đó khi
có sự thay đổi dữ liệu trên 1 server thì server còn lại cũng update theo.
Khi ứng dụng (người dùng cuối) truy vấn dữ liệu thì sẽ kết nối tới ip ảo
(192.168.88.101 ) do keepalived tạo ra dùng chung cho 2 server,từ đó chia đều
lượng truy vấn cần sử lý.
Trong trường hợp 1 server bị lỗi,truy vấn sẽ được dồn đến server còn lại.

3. Giải pháp sử dụng Clustering với keepalived cho hệ quản trị
CSDL MySQL
3.1. Khái niệm
Clustering là một kiến trúc nhằm đảm bảo nâng cao khả năng sẵn sàng cho
các hệ thống mạng máy tính. Clustering cho phép sử dụng nhiều máy chủ kết hợp
22


với nhau tạo thành một cụm và có khả năng chịu được lỗi nhằm nâng cao độ sẵn
sàng cho hệ thống. Nó có thể bao gồm nhiều máy chủ kết nối với nhau theo dạng
song song hoặc phân tán, nếu một máy chủ ngừng hoạt động do bị sự cố hoặc để
nâng cấp bảo trì thì luôn luôn có một bản sao dự phòng tương tự của máy chủ đó sẽ
đảm nhiệm công việc giúp.
MySQL-Cluster là một công cụ lưu trữ dữ liệu dựa trên giải pháp clustering,
được thiết kế cho khả năng chịu lỗi, dự phòng, khả năng sẵn sàng, khả năng mở
rộng và hiệu suất cao. Dữ liệu được lưu trữ và nhân rộng trên các nút dữ liệu riêng

biệt, mỗi nút dữ liệu cài đặt trên một máy chủ và luôn luôn có chứa một bản sao dữ
liệu giống hệt nó trong hệ thống. Mỗi cụm chứa các nút quản lý, giúp quản lý,
kiểm tra, giám sát toàn hệ thống. Các phiên bản ban đầu của MySQL Cluster lưu
trữ tất cả các thông tin trong bộ nhớ chính với khả năng lưu trữ không ổn định.
Nhưng các phiên bản sau này đã khắc phục được nhược điểm này của MySQL
Cluster cho phép lưu trữ dữ liệu trên đĩa giúp MySQL Cluster có thể làm việc với
lượng dữ liệu lưu trữ rất lớn, lớn hơn bộ nhớ chính của máy. Sự quan trọng của
MySQL Cluster còn ở khả năng sử dụng máy chủ MySQL như là một cộng cụ truy
vấn để truy vấn đến cơ sở dữ liệu nằm trên các nút chứa dữ liệu. Vì thế, có thể di
chuyển các ứng dụng thiết kế để tương tác với MySQL sang MySQL Cluster tốt.
Ngoài ra khái niệm nút ngang hàng cho phép một cập nhật được thực hiện trên một
máy chủ sẽ được nhìn thấy ngay lập tức trên các máy chủ khác. Và việc truyền tải
các thay đổi sử dụng một cơ chế thông tin liên lạc tinh vi được thiết kế cho việc
truyền thông qua mạng hiệu quả rất cao. Mục đích của tất cả các việc đó là để
MySQL Cluster đạt được một hiệu suất cao nhất có thể, để phân phối tải, và thỏa
mãn khả năng sẵn sàng cao và tính dự phòng.
Việc thiết kế và lắp đặt các cluster cần thoả mãn các yêu cầu sau:


Yêu cầu về tính sẵn sàng cao (High availability). Các tài nguyên mạng
phải luôn sẵn sàng trong khả năng cao nhất để cung cấp và phục vụ các người
dùng cuối và giảm thiểu sự ngưng hoạt động hệ thống ngoài ý muốn.

23


Yêu cầu về độ tin cậy cao (reliability). Độ tin cậy cao của cluster được
hiểu là khả năng giảm thiểu tần số xảy ra các sự cố, và nâng cao khả năng
chịu đựng sai sót của hệ thống.


Yêu cầu về khả năng mở rộng được (scalability). Hệ thống phải có khả
năng dễ dàng cho việc nâng cấp, mở rộng trong tương lai. Việc nâng cấp mở
rộng bao hàm cả việc thêm các thiết bị, máy tính vào hệ thống để nâng cao
chất lượng dịch vụ, cũng như việc thêm số lượng người dùng, thêm ứng dụng,
dịch vụ và thêm các tài nguyên mạng khác
Ba yêu cầu trên được gọi tắt là RAS (Reliability-Availability-Scalability), những
hệ thống đáp ứng được ba yêu cầu trên được gọi là hệ thống RAS


3.2 Nguyên tắc hoạt động của Clustering
Mỗi máy chủ trong cluster được gọi là một node (cluster node), và có thể được
thiết lập ở chế độ chủ động (active) hay thụ động (passive). Khi một node ở chế độ
chủ động, nó sẽ chủ động xử lý các yêu cầu. Khi một node là thụ động, nó sẽ nằm
ở chế độ dự phòng nóng (standby) chờ để sẵn sàng thay thế cho một node khác nếu
bị hỏng.
Trong một cluster có nhiều node có thể kết hợp cả node chủ động và node thụ
động. Trong những mô hình loại này việc quyết định một node được cấu hình là
chủ động hay thụ động rất quan trọng. Để hiểu lý do tại sao, hãy xem xét các tình
huống sau:
-

Nếu một node chủ động bị sự cố và có một node thụ động đang sẵn sàng, các ứng
dụng và dịch vụ đang chạy trên node hỏng có thể lập tức được chuyển sang node
thụ động. Vì máy chủ đóng vai trò node thụ động hiện tại chưa chạy ứng dụng hay
dịch vụ gì cả nên nó có thể gánh toàn bộ công việc của máy chủ hỏng mà không
ảnh hưởng gì đến các ứng dụng và dịch vụ cung cấp cho người dùng cuối.

-

Nếu tất cả các máy chủ trong cluster là chủ động và có một node bị sự cố, các ứng

dụng và dịch vụ đang chạy trên máy chủ hỏng sẽ phải chuyển sang một máy chủ
khác cũng đóng vai trò node chủ động. Vì là node chủ động nên bình thuờng máy
chủ này cũng phải đảm nhận một số ứng dụng hay dịch vụ gì đó, khi có sự cố xảy
ra thì nó sẽ phải gánh thêm công việc của máy chủ hỏng. Do vậy để đảm bảo hệ
thống hoạt động bình thường kể cả khi có sự cố thì máy chủ trong cluster cần phải

24


có cấu hình dư ra đủ để có thể gánh thêm khối lượng công việc của máy chủ khác
khi cần.
3.3 Sự khác nhau giữa Loadbalancing và Cluster.
Network Load Balancing .
- Các Node có thể lưu trữ cùng một nơi , hoặc lưu trữ riêng biệt.
- Cân bằng tải Transmission Control Protocol (TCP) và UDP (UDP) lưu lượng truy
cập.
- Không cần phần cứng chuyên dụng, ( chú ý về Card mạng ).
- Thường được dùng cho máy chủ Web, Máy chủ ISA , Máy chủ VPS , Máy chủ
Media, Máy chủ , Máy chủ Teminal, di động,...
- Chạy ở chế độ Active.
Cluster.
- Các Node lưu trữ cùng một nơi.
- Failover và failback của các ứng dụng.
- Phải dùng thiết bị lưu trữ chuyên dụng đắt tiền kiểu SCSI , Fibre Chanel , Seria
Attach SCSI , ISCSI.
- Thường được chạy cho các máy chủ MS SQL Server, MS Exchange Server, File
Server ,....
- Chạy ở 2 chế độ Active và Passive.

Mô hình sử dụng MySQL-Cluster kết hợp keepalived (mô hình sẽ thực hiện):

Hình 7:Mô hình sử dụng MySQL-Cluster kết hợp keepalived

25