phan tai csdl mysql GiangTT_53_DH.pdf
94
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƢỜNG ĐẠI HỌC CÔNG NGHỆ Trần Thị Giang NGHIÊN CỨU THỬ NGHIỆM GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL MYSQL VỚI MYSQL PROXY KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC CHÍNH QUY Ngành: Công nghệ Thông tin HÀ NỘI – 2012
-
Upload
hai-pham-van -
Category
Documents
-
view
235 -
download
1
Transcript of phan tai csdl mysql GiangTT_53_DH.pdf
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
Trần Thị Giang
NGHIÊN CỨU THỬ NGHIỆM GIẢI PHÁP CÂN
BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL MYSQL VỚI
MYSQL PROXY
KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC CHÍNH QUY
Ngành: Công nghệ Thông tin
HÀ NỘI – 2012
ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƢỜNG ĐẠI HỌC CÔNG NGHỆ
Trần Thị Giang
NGHIÊN CỨU THỬ NGHIỆM GIẢI PHÁP CÂN
BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL MYSQL VỚI
MYSQL PROXY
KHÓA LUẬN TỐT NGHIỆP ĐẠI HỌC CHÍNH QUY
Ngành: Công nghệ Thông tin
Cán bộ hƣớng dẫn: TS Nguyễn Hải Châu
HÀ NỘI – 2012
VIETNAM NATIONAL UNIVERSITY, HANOI
UNIVERSITY OF ENGINEERING AND TECHNOLOGY
Tran Thi Giang
RESEARCH INTO EXPERIMENT OF LOAD
BALANCING SOLUTION FOR MYSQL DATABASE
MANAGEMENT SYSTEM WITH MYSQL PROXY
Major: Information technology
Supervisor: Nguyen Hai Chau, PhD
HA NOI – 2012
LỜI CẢM ƠN
Lời đầu tiên, tôi xin gửi lời cảm ơn và lòng biết ơn sâu sắc nhất tới Tiến sĩ Nguyễn
Hải Châu, ngƣời đã tận tình hƣớng dẫn và chỉ bảo tôi trong suốt quá trình thực hiện khóa
luận tốt nghiệp.
Tôi chân thành cảm ơn các thầy, cô trong bộ môn Hệ thống thông tin đã tạo điều
kiện thuận lợi để tôi tiến hành thực nghiệm khóa luận của mình. Tôi cũng xin gửi lời cảm
ơn đến tất cả các thầy cô trong trƣờng Đại học Công nghệ đã cho tôi một môi trƣờng rất
tốt để học tập và nghiên cứu. Các thầy cô đã giảng dạy và cho tôi những kiến thức quý
báu, làm nền tảng để tôi hoàn thành khóa luận cũng nhƣ công việc trong tƣơng lai.
Tôi cũng xin gửi lời tri ân tới các bạn trong lớp K53CC và K53CLC đã luôn bên
cạnh, ủng hộ và giúp đỡ tôi trong suốt quá trình học tập tại trƣờng.
Cuối cùng, tôi muốn gửi lời cảm ơn vô hạn tới gia đình và bạn bè – những ngƣời
thân yêu luôn ở bên, khuyến khích và động viên tôi trong cuộc sống cũng nhƣ trong học
tập.
Tôi xin chân thành cảm ơn.
Hà nội, tháng 5 năm 2012
Sinh viên
Trần Thị Giang
NGHIÊN CỨU THỬ NGHIỆM GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN
TRỊ CSDL MYSQL VỚI MYSQL PROXY
Trần Thị Giang
Khóa QH-2008-I/CQ, ngành Công nghệ thông tin
Tóm tắt Khóa luận tốt nghiệp:
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ệ mật thiết với nhau để đảm bảo hệ thống hoạt động ổn định. Nếu một hệ thống mà
không đáp ứng đƣợc một trong ba yêu cầu trên thì thảm họa có thể xảy ra bất cứ lúc nào. Điều
này gây ra một tổn thất vô cùng nặng nề cho doanh nghiệp. Do vậy, cân bằng tải, khả năng mở
rộng và tính sẵn sàng cao quyết định đến yếu tố sống còn của một doanh nghiệp.
Đã có rất nhiều giải pháp cân bằng tải đƣợc các nhà nghiên cứu đƣa ra cho các hệ quản trị
CSDL. Tuy nhiên nhiều giải pháp không giải quyết đƣợc đầy đủ cả ba yếu tố trên cho hệ thống
máy chủ. Vì vậy, khóa luận lựa chọn giải pháp sử dụng MySQL proxy để cân bằng tải cho các
máy chủ cơ sở dữ liệu MySQL. MySQL proxy nhận các truy vấn từ phía client, lọc ra các truy
vấn để gửi đến các máy chủ phù hợp dựa trên thuật toán cân bằng tải, sau đó nhận dữ liệu từ các
máy chủ để trả lại cho khách hàng. Không chỉ đáp ứng đƣợc yêu cầu cân bằng tải, giải pháp này
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 nhờ việc sử dụng
phƣơng pháp Replication cho MySQL.
Thực nghiệm đƣợc tiến hành với hai mô hình, một mô hình chỉ có hai máy chủ - mô hình
với một master và một slave, và một mô hình mở rộng hơn với ba máy chủ – mô hình một
master và hai slave. Kết quả thu đƣợc từ các tham số đánh giá tải và hiệu năng của server cho
thấy rằng, giải pháp đƣợc kiểm nghiệm là khả quan và áp dụng đƣợc trong thực tế.
Từ khóa: MySQL Proxy, cân bằng tải
RESEARCH INTO EXPERIMENT OF LOAD BALANCING SOLUTION
FOR MYSQL DATABASE MANAGEMENT SYSTEM WITH MYSQL PROXY
Tran Thi Giang
QH-2008-I/CQ course, Information Technology major
Abstract of thesis:
In recent years, the boost of internet cause the number of user who access to database
server through Internet increase rapidly. With millions of clients access every day, this require
server system powerfull, otherwise the system will be overload. A powerfull server system is
system can be satisfy all clients requests within the shortest possible time – the system is capable
of load balancing. In addition, the system also need scalability and high availability. These three
factors combine together closely to ensure stable system operation. If the system is lacks of one
factor, disater will happen any time. This cause an extremely heavy loss for businesses.
Therefore, load balancing, scalability and high availability factors determine survival of
businesses.
The researchers in over the world gave a lot of load balancing solutions for database
mannagement systems. However, there are some solutions do not satisfy fully three factors
above. So the thesis chooses a load balancing solution for MySQL database management system
that uses a load balancer, called MySQL Proxy. MySQL Proxy is a program that sits between
clients and MySQL servers. All of MySQL Proxy‟s activities based on the Lua scripting
language and Load Balancing Algorithms. It receives queries from clients, monitors, analyzes
them, passes them to the MySQL server and returns the responses from the MySQL Server to the
appropriate client. Not only load balancing, this solution also solves the scalability and high
availability problem base on the Replication MySQL method.
The experiment based on three models of Replication, the first model there is only one
MySQL server, the second model is the simple replication model (one master and one slave), and
last model is the master – multi slaves replication model (one master and two slaves). The load
parameters assessment and the performance of the servers show that the results is satisfactory
and this solution can apply in fact.
Keywords: MySQL Proxy, Load balancing
LỜI CAM ĐOAN
Tôi xin cam đoan giải pháp cân bằng tải hệ quản trị CSDL MySQL sử dụng
MySQL Proxy và thực nghiệm đƣợc trình bày trong khóa luận này là do tôi thực hiện
dƣới sự hƣớng dẫn và chỉ bảo của Tiến sĩ Nguyễn Hải Châu.
Tất cả các tài liệu tham khảo từ các nghiên cứu liên quan đều đƣợc nêu nguồn gốc
một cách rõ ràng từ danh mục Tài liệu tham khảo trong khóa luận. trong khóa luận,
không có việc sao chép tài liệu, công trình nghiên cứu của ngƣời khác mà không chỉ rõ về
tài liệu tham khảo
Hà nội, tháng 5 năm 2012
Sinh viên
Trần Thị Giang
MỤC LỤC
MỞ ĐẦU ............................................................................................................................. 1
CHƢƠNG 1: SỰ CẦN THIẾT CỦA VIỆC CÂN BẰNG TẢI TRUY VẤN ĐỌC CHO
HỆ QUẢN TRỊ CSDL MYSQL .......................................................................................... 3
1.1. CÁC KIỂU QUÁ TẢI MÁY CHỦ [8] .................................................................... 3
1.1.1. Số lƣợng truy cập hợp lệ đến máy chủ quá lớn................................................ 3
1.1.2. Máy chủ bị tấn công ......................................................................................... 3
1.1.3. Internet ............................................................................................................. 4
1.2. SỰ CẦ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À MYSQL NÓI RIÊNG ................................................................ 5
1.2.1. Sự cần thiết của việc cân bằng tải cho các hệ quản trị nói chung .................... 5
1.2.2. Sự cần thiết của việc cân bằng tải hệ quản trị CSDL MySQL với việc sử
dụng bộ cân bằng tải là MySQL Proxy ....................................................................... 6
1.3. MỘT SỐ TIÊU CHÍ ĐÁNH GIÁ TẢI VÀ HIỆU NĂNG CỦA MÁY CHỦ ......... 7
1.3.1. CPU Utilization ................................................................................................. 7
1.3.2. Memory usage ................................................................................................... 8
1.3.3. Thời gian phản hồi ............................................................................................. 8
1.4. XÁC ĐỊNH MỤC TIÊU NGHIÊN CỨU CỦA KHÓA LUẬN LÀ CÁC ỨNG
DỤNG QUÁ TẢI TRUY VẤN ĐỌC ................................................................................. 8
CHƢƠNG 2: CÁC GIẢI PHÁP CÂN BẰNG TẢI CHO CÁC HỆ QUẢN TRỊ CSDL. . 10
2.1. CÁC GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL MYSQL ....... 10
2.1.1. Giải pháp sử dụng Replication cơ sở dữ liệu với MySQL Proxy ................... 10
2.1.2. Giải pháp sử dụng Clustering [3] .................................................................... 10
2.2. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL POSTGRESQL ..... 12
2.2.1. Giải pháp sử dụng Replication cơ sở dữ liệu .................................................. 12
2.2.2. Giải pháp sử dụng Partitioning cơ sở dữ liệu - Cân bằng tải các truy vấn ghi
với PL/Proxy .............................................................................................................. 17
2.3. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL ORACLE .............. 18
2.3.1. Giải pháp cân bằng tải phía client ................................................................... 18
2.3.2. Giải pháp cân bằng tải phía server .................................................................. 19
2.3.3. Giải pháp Oracle Real Application Cluster ..................................................... 19
2.4. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL SQL ....................... 21
2.4.1. Giải pháp sử dụng Replication cơ sở dữ liệu .................................................. 21
2.4.2. Giải pháp Database mirroring ......................................................................... 26
2.4.3. Giải pháp Network Load Balancing ................................................................ 27
2.5. Các thuật toán cân bằng tải .................................................................................... 29
2.5.1. Giải thuật thuật Roun-robin ........................................................................... 29
2.5.2. Hàm băm ........................................................................................................ 30
2.5.3. Giải thuật xác định tổng số kết nối nhỏ nhất ................................................. 32
CHƢƠNG 3: BÀI TOÁN CÂN BẰNG TẢI READ CHO HỆ QUẢN TRỊ CSDL
MYSQL VỚI MYSQL PROXY. ...................................................................................... 33
3.1. GIỚI THIỆU VỀ MYSQL PROXY VÀ NGÔN NGỮ KỊCH BẢN LUA............ 33
3.1.1. Giới thiệu về mysql proxy ............................................................................... 33
3.1.2. Giới thiệu về ngôn ngữ kịch bản Lua .............................................................. 34
3.1.3. Nguyên lý hoạt động của MySQL Proxy với ngôn ngữ kịch bản Lua [25] .... 35
3.2. GIỚI THIỆU VỀ GIẢI PHÁP REPLICATION TRONG HỆ QUẢN TRỊ CSDL
MYSQL ............................................................................................................................. 37
3.3. GIỚI THIỆU VỀ CÔNG CỤ MYSQLSLAP ........................................................ 42
3.4. PHÁT BIỂU BÀI TOÁN ....................................................................................... 43
3.5. MÔ HÌNH GIẢI QUYẾT BÀI TOÁN .................................................................. 44
3.4.1. Mô hình MySQL Proxy – một master – một slave ......................................... 44
3.4.2. Mô hình MySQL Proxy – một master – multi slave ....................................... 44
CHƢƠNG 4: THỰC NGHIỆM VÀ ĐÁNH GIÁ ............................................................. 46
4.1. MÔI TRƢỜNG THỰC NGHIỆM ......................................................................... 46
4.2. TIẾN HÀNH THỰC NGHIỆM ............................................................................. 46
4.2.1. Cài đặt MySQL Proxy ..................................................................................... 46
4.2.2. Cấu hình cho giải pháp replication trong hệ quản trị CSDL MySQL [7] ....... 49
4.2.3. Kịch bản Lua ................................................................................................... 51
4.2.4. Thử nghiệm...................................................................................................... 53
4.3. PHÂN TÍCH, ĐÁNH GIÁ KẾT QUẢ THỰC NGHIỆM ..................................... 55
4.3.1. Client gửi truy vấn trực tiếp đến máy chủ MySQL ......................................... 55
4.3.2. Mô hình MySQL Proxy – một master – một slave ......................................... 56
4.3.3. Mô hình MySQL Proxy – một master – hai slave ........................................... 64
4.4. NHẬN XÉT ........................................................................................................... 74
4.4.1. Khả năng chịu tải của server .......................................................................... 74
4.4.2. Khả năng mở rộng .......................................................................................... 74
4.4.3. Tính sẵn sàng cao ........................................................................................... 75
KẾT LUẬN ....................................................................................................................... 76
DANH SÁCH CÁC BẢNG
Bảng 1: Cấu hình các máy ................................................................................................. 46
Bảng 2: Kết quả thời gian chạy các truy vấn trong mô hình chỉ có một MySQL server .. 56
Bảng 3: Kết quả thời gian chạy các truy vấn trong mô hình MySQL Proxy-master-slave
........................................................................................................................................... 64
Bảng 4: Kết quả thời gian chạy các truy vấn trong mô hình MySQL Proxy-master-multi
slave ................................................................................................................................... 72
DANH SÁCH CÁC HÌNH VẼ
Hình 1: Mô hình PGCluster trong giải pháp cân bằng tải ................................................. 12
Hình 2: Mô hình của Slony-I trong cân bằng tải ............................................................... 14
Hình 3: Mô hình pgpool-II trong cân bằng tải .................................................................. 15
Hình 4: Giải pháp cân bằng tải hệ quản trị CSDL PostgreSQL với PL/Proxy ................. 17
Hình 5: Giải pháp cân bằng tải cho hệ quản trị CSDL Oracle phía client ........................ 18
Hình 6: Giải pháp cân bằng tải phía server cho hệ quản trị CSDL Oracle ....................... 19
Hình 7: Giải pháp cân bằng tải cho hệ quản trị CSDL Oracle Real Application Cluster . 20
Hình 8: Giải pháp Merge replication cân bằng tải cho hệ quản trị CSDL SQL ................ 22
Hình 9: Giải pháp Transaction replication cân bằng tải cho hệ quản trị CSDL SQL ....... 24
Hình 10: Giải pháp Log shipping để cân bằng tải cho hệ quản trị CSDL SQL ................ 25
Hình 11: Giải pháp Database Mirroring cân bằng tải cho hệ quản trị CSDL SQL ........... 27
Hình 12: Giải pháp Network load balancing cân bằng tải cho hệ quản trị CSDL SQL .... 29
Hình 13: Các thủ tục cần thực hiện khi client gửi một truy vấn đến server qua MySQL
Proxy .................................................................................................................................. 36
Hình 14: Mô hình replication đơn giản master – slave trong MySQL .............................. 39
Hình 15: Mô hình replication master – multi slave trong MySQL ................................... 39
Hình 16: Mô hình master – relay slave trong MySQL ...................................................... 40
Hình 17: Mô hình replication master – master trong MySQL .......................................... 41
Hình 18: Mô hình master-slave replication với MySQL Proxy ........................................ 44
Hình 19: Mô hình master – multi salve replication với MySQL Proxy ............................ 45
Hình 20: Hiệu năng của server trong mô hình chỉ có duy nhất MySQL server ................ 56
Hình 21: Hiệu năng CPU của master ................................................................................ 73
Hình 22: Hiệu năng về Processes ...................................................................................... 73
Hình 23: Hiệu năng trung bình tải ..................................................................................... 74
DANH SÁCH CÁC TỪ VIẾT TẮT
STT Từ viết tắt Từ tiếng anh Từ Tiếng Việt
1 CPU Central Processing Unit Đơn vị xử lý trung tâm
2 RAM Random Access Memory Bộ nhớ truy cập ngẫu nhiên
3 RAC Real Application Cluster Cụm ứng dụng thực
4 CSDL Database Cơ sở dữ liệu
DANH SÁCH CÁC THUẬT NGỮ
STT Thuật ngữ Tiếng Anh Thuật ngữ Tiếng Việt
1 Load balance Cân bằng tải
2 Load balancer Bộ cân bằng tải
3 Replication Nhân rộng
4 Database Server Máy chủ cơ sở dữ liệu
5 Web server Máy chủ web
6 Server Máy chủ
7 Client Khách hàng
8 Website Trang web
9 CPU Utilization Sử dụng CPU
10 Memory usage Sử dụng bộ nhớ
11 Cluster Cụm
12 failover Chuyển đổi dự phòng
13 Partitioning Phân mảnh
14 Stored procedure Thủ tục lƣu trữ
15 Real Application Cluster
16 Merge replication Nhân rộng hợp nhất
17 Snapshot Agent Đại lý chụp ảnh
18 Merge Agent Đại lý hợp nhất
19 Publication Sự xuất bản
20 Subscriber Ngƣời mua
21 Publisher Nhà xuất bản
22 Transactional replication Nhân rộng giao dịch
23 Distribution Agent Đại lý phân phối
24 CREATE Tạo
25 UPDATE Cập nhật
26 INSERT Chèn
27 DELETE / DROP Xóa
28 SELECT Chọn
29 Log Reader Agent
30 transaction log Bản ghi giao dịch
31 Log shipping
32 primary server Máy chủ chính
33 secondary server Máy chủ thứ
34 monitor server Máy chủ theo dõi
35 primary database Cơ sở dữ liệu chính
36 secondary databases Cơ sở dữ liệu thứ
37 Database mirroring Cơ sở dữ liệu phản ánh
38 hot standby server Máy chủ chờ nóng
39 Binary log Bản ghi nhị phân
1
MỞ ĐẦ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ệ mật thiết với nhau để đảm bảo
hệ thống hoạt động ổn định. Nếu một hệ thống mà không đáp ứng đƣợc một trong ba yêu
cầu trên thì thảm họa có thể xảy ra bất cứ lúc nào. Điều này gây ra một tổn thất vô cùng
nặng nề cho doanh nghiệp. Do vậy, cân bằng tải, khả năng mở rộng và tính sẵn sàng cao
quyết định đến yếu tố sống còn của một doanh nghiệp.
Đã có rất nhiều phƣơng pháp cân bằng tải đƣợc đƣa ra cho các hệ quản trị CSDL.
Tuy nhiên nhiều phƣơng pháp không giải quyết đƣợc đầy đủ cả ba yếu tố trên cho hệ
thống máy chủ. Vì vậy, khóa luận đƣa ra phƣơng pháp sử dụng MySQL proxy để cân
bằng tải cho các máy chủ cơ sở dữ liệu MySQL. MySQL proxy 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 nhờ việc sử dụng phƣơng pháp Replication cho MySQL. Do vậy, ý
nghĩa thực tiễn của giải pháp này là rất lớn. 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 sử dụng MySQL Proxy cho các truy vấn đọc.
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ính
cầ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 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: Giới thiệu một số giải pháp cân bằng tải cho các hệ quản trị CSDL:
MySQL, PostgreSQL, Oracle và SQL. Trình bày một số thuật toán đƣợc sử dụng trong
các giải pháp cân bằng tải.
2
Chƣơng 3: Trình bày bài toán cân bằng tải cho hệ quản trị CSDL MySQL với Load
Balancer là MySQL Proxy. Chƣơng này tìm hiểu về giải pháp replication trong hệ quản
trị CSDL MySQL, nguyên lý hoạt động của MySQL Proxy, ngôn ngữ kịch bản Lua đƣợc
sử dụng để điều khiển các hành động của MySQL Proxy và công cụ mysqlslap để giả lập
các client, sinh truy vấn đến các máy chủ.
Chƣơng 4: Thực nghiệm và đánh giá. Tiến hành thực nghiệm cân bằng tải các truy
đọc cho các máy chủ với hai mô hình MySQL Proxy – một master – một slave và mô
hình MySQL Proxy – một master – multi slave. Công cụ đƣợc sử dụng để sinh ra các truy
vấn là mysqlslap.
Phần kết luận và hƣớng phát triển khóa luận: Tóm lƣợc những điểm chính của khóa
luận. Chỉ ra những điểm cần khắc phục, đồng thời đƣa ra hƣớng nghiên cứu trong thời
gian tiếp theo.
3
CHƢƠNG 1: SỰ CẦN THIẾT CỦA VIỆC CÂN BẰNG TẢI TRUY VẤN
ĐỌC CHO HỆ QUẢN TRỊ CSDL MYSQL
1.1. CÁC KIỂU QUÁ TẢI MÁY CHỦ [8]
1.1.1. Số lƣợng truy cập hợp lệ đến máy chủ quá lớn
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 (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
a) 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 namserver.
4
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.
b) Sâu máy tính (computer worms):
Một con sâu máy tính là một phần mềm dộ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, sâu máy tính sử dụng một
mạng lƣới máy tính để lây lan. Vì thế, mạng lƣới ấy bị nhiễm sâu và đƣợc kiểm soát bởi
tác giả sâu. Sâu máy tính gây ra sự gián đoạn lớn bằng cách làm tăng lƣu lƣợng mạng và
các hiệu ứng không mong muốn khác, nó còn có thể xóa các tập tin trên server.
c) Viruss XSS
Một virus máy tính là một chƣơng trình máy tính có thể tự tái tạo và lây lan từ một
máy tính khác. Virus có thể làm tăng nguy cơ lây lan sang máy tính khác bằng cách lây
nhiễm các tập tin trên một hệ thống tập tin mạng hoặc một hệ thống tập tin đƣợc truy cập
bởi các máy tính khác.
Virus XSS có thể gây ra lƣợng truy cập cao có thể đến hàng triệu truy cập trong một
khoảng thời gian rất ngắn, vì hàng triệu các trình duyệt bị nhiễm bệnh và/hoặc ngay cả
các server cũng bị nhiễm bệnh. Do vậy, nó gây ra tình trạng quá tải của server.
1.1.3. Internet
a) 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.
5
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.
b) Mạng chậm
Khi mạng chậm thì các yêu cầu của khách hàng đƣợc phục vụ chậm hơn và số
lƣợng kết nối tăng lên rất nhiều vƣợt quá giới hạn server đạt đƣợc. Do vậy, nguy cơ máy
chủ bị quá tải là rất cao.
1.2. SỰ CẦ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À MYSQL NÓI RIÊNG
1.2.1. Sự cần thiết của việc cân bằng tải cho các hệ quản trị nói chung
Sự phát triển của internet khiến cho số lƣợng ngƣời dùng truy cập đến các web
server ngày càng tăng mạnh, đặc biệt là các mạng xã hội hoặc các website chia sẻ trực
tuyến. Các website này không chỉ cho phép ngƣời dùng trao đổi và chia sẻ thông tin, giao
lƣu và kết bạn mà còn cho phép ngƣời dùng lƣu trữ tài liệu với dung lƣợng khá lớn. Đầu
năm 2012, hãng nghiên cứu thị trƣờng Nielsen1 đã công bố 10 website đƣợc truy cập
nhiều nhất vào năm 2011, trong đó, đứng đầu là Google2 trung bình có khoảng 153,44
triệu ngƣời dùng Mỹ truy cập mỗi tháng; đứng thứ hai trên bảng xếp hạng là Facebook3
với 137,64 triệu ngƣời dùng; Apple4 là 61,6 triệu ngƣời dùng [9]. Với hàng triệu lƣợt truy
cập mỗi ngày đòi hỏi hệ thống máy chủ 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 hoạt động tốt khiến ngƣời dùng hài lòng, từ đó số lƣợng ngƣời
dùng ngày càng tăng lên, gây quá tải máy chủ, dẫn đến yêu cầu nâng cấp hệ thống. Cứ
nhƣ vậy, hệ thống đƣợc nâng cấp và ngƣời dùng ngày càng tăng. Vòng tuần hoàn này dẫn
đến nhu cầu phải xây dựng một hệ thống có khả năng đáp ứng đƣợc số lƣợng lớn ngƣời
dùng trong thời gian dài, và khi ngƣời dùng tăng lên thì có thể mở rộng hệ thống một
cách dễ dàng mà không ảnh hƣởng đến hoạt động của hệ [1].
Bên cạnh sự bùng nổ của các website chia sẻ trực tuyến, một số đơn vị nhƣ các
hãng hàng không, ngân hàng, các doanh nghiệp lớn thì mạng máy tính có thể ví nhƣ hệ
thần kinh điều khiển hoạt động của toàn doanh nghiệp và máy chủ là trái tím của mạng
6
máy tính. Sự ngƣng hoạt động của máy chủ làm tê liệt toàn bộ các hoạt động chính của
doanh nghiệp, và thiệt hại khó có thể lƣờng trƣớc đƣợc. Ngoài ra, nhƣ đã giới thiệu ở
trên, kẻ xấu lợi dụng khi các máy chủ của doanh nghiệp quá tải sẽ tấn công doanh nghiệp,
lấy đi những tài liệu quan trọng hay những khoản tiền lớn – ví dụ nhƣ trong ngân hàng.
Nếu điều này xảy ra thì tổn thất cho doanh nghiệp là rất lớn, có thể bị phá sản.
Với các tình trạng trên, nhu cầu cân bằng tải hệ thống máy chủ, đặc biệt là cân bằng
tải cho các máy chủ cơ sở dữ liệu là điều kiện tất yếu. Ngoài nhu cầu cân bằng tải, nhu
cầu mở rộng hệ thống và tính sẵn sàng cao của các máy chủ cũng rất cần thiết. Cân bằng
tải là khả năng chia tải cho các database server của hệ thống để đáp ứng đƣợc tất cả các
yêu cầu của ngƣời dùng một cách nhanh nhất, không bị bất kỳ một thời gian trễ nào. Khi
ngƣời dùng tăng và phạm vi ngƣời dùng mở rộng ra, do vậy hệ thống phải đƣợc triển
khai trên quy mô rộng lớn nhƣ trên một quốc gia hay toàn cầu. Với khả năng cân bằng tải
và khả năng mở rộng quy mô nhƣ vậy làm tính sẵn sàng của hệ thống cao hơn rất nhiều.
Khi một database server bị lỗi, thì một server khác thay thế server bị lỗi ngay tức khắc.
Ba yếu tố này liên hệ mật thiết với nhau, hỗ trợ nhau để đảm bảo hệ thống hoạt động tốt,
ổn định trong thời gian dài.
1.2.2. Sự cần thiết của việc cân bằng tải hệ quản trị CSDL MySQL với việc sử dụng
bộ cân bằng tải là MySQL Proxy
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 [9].
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 kiệm đƣợc khá nhiều chi phí
7
đầ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ới
bộ cân bằng tải MySQL Proxy đã đƣợc đƣa ra cho hệ quản trị CSDL MySQL. 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.
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ƣợng
phé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).
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.
8
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.
RAM – bộ nhớ truy cập ngẫu nhiên – là một loại bộ nhớ chính của máy tính để lƣu
trữ mã chƣơng trình và dữ liệu trong suốt thời gian thực thi, chúng sẽ bị xóa khi mất
nguồn điện. Đây là loại bộ nhớ có thể ghi và đọc dữ liệu và thời gian truy cập đến bất kỳ
ô nhớ nào cũng nhƣ nhau.
Bộ nhớ ảo là một không gian trong đĩa cứng, đƣợc sử dụng khi dung lƣợng của
RAM đã đầy. Bộ nhớ ảo là một kỹ thuật cho phép xử lý một chƣơng trình không đƣợc
nạp toàn bộ vào RAM. Trong RAM chỉ lƣu trữ các lệnh và dữ liệu phục vụ cho hoạt động
của chƣơng trình tại một thời điểm nhất định. Khi cần tới các lệnh hoặc dữ liệu mới hệ
thống sẽ nạp chúng vào bộ nhớ tại vị trí trƣớc đó bị chiếm giữ bởi các lệnh không dùng
vào thời điểm này. Các lệnh và dữ liệu không dùng đến đƣợc chuyển vào bộ nhớ ảo.
Thông số “free” trong RAM và “swap” trong bộ nhớ ảo cho biết dung lƣợng bộ nhớ
có sẵn trong là bao nhiêu, từ đó có thể đánh giá hiệu suất của máy chủ. Nếu dung lƣợng
bộ nhớ càng lớn thì hiệu suất của máy chủ càng cao và ngƣợc lại.
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 NGHIÊN CỨU CỦA KHÓA LUẬN LÀ CÁC ỨNG
DỤNG QUÁ TẢI TRUY VẤN ĐỌC
9
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, 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 khóa luận tập trung nghiên cứu và thử nghiệm giải pháp cân
bằng tải cho các truy vấn đọc.
10
CHƢƠNG 2: CÁC GIẢI PHÁP CÂN BẰNG TẢI CHO CÁC HỆ QUẢN
TRỊ CSDL.
2.1. CÁC GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL MYSQL
2.1.1. Giải pháp sử dụng Replication cơ sở dữ liệu với MySQL Proxy
Giải pháp này là mục tiêu nghiên cứu của khóa luận, chi tiết đƣợc trình bày trong
chƣơng 3 và chƣơng 4.
2.1.2. Giải pháp sử dụng Clustering [3]
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 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.
11
Mô hình MySQL Cluster trong bài toán cân bằng tải
Trên máy 192.168.1.50 sẽ cài đặt Load balancer mà cụ thể là các chƣơng trình
ldirectord và ipvsadm. Chƣơng trình ipvsadm có nhiệm vụ phân tải khi có yêu cầu
truy vấn đến máy chủ cơ sở dữ liệu thì sẽ phân phối đều đến các máy chủ thành viên
để xử lý. Chƣơng trình ldirectord có nhiệm vụ giám sát và kiểm tra tín hiệu của các
máy chủ cơ sở dữ liệu thành viên thông qua các truy vấn kiểm tra. Trong trƣờng hợp
dịch vụ của một máy chủ cơ sở dữ liệu bị lỗi thì máy chủ đó sẽ bị loại ra khỏi danh
sách và các truy vấn sẽ đƣợc dồn đến các máy chủ còn lại.
Máy Load balancer sẽ tạo ra một dịa chỉ ip ảo 192.168.1.100 và các ứng dụng sẽ
truy cập tới địa chỉ này, Load balancer sau đó sẽ tự động gửi yêu cầu của ứng dụng tới
các MySQLD (192.168.1.70 và 192.168.1.80) thật. MySQLD nhận truy vấn, xử lý và
gửi lại kết quả cho ứng dụng.
12
2.2. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL POSTGRESQL
PostgreSQL là hệ quản trị CSDL đối tƣợng - quan hệ mạnh mẽ và mã nguồn mở.
Nó đã đƣợc phát triển 15 năm, và đã đƣợc chứng mình là hệ quản trị CSDL có độ bền
mạnh, tính toàn vẹn dữ liệu và tính đúng đắn [11]. PostgreSQL cũng đƣa ra một số giải
pháp cân bằng tải cho hệ thống:
2.2.1. Giải pháp sử dụng Replication cơ sở dữ liệu
Bốn phƣơng pháp replication phổ biến trong hệ quản trị CSDL PostgreSQL đại diện
cho bốn phƣơng thức hoạt động của replication: multi-master đồng bộ, multi-master
không đồng bộ, master to multi-salve không đồng bộ và statement-based middelware là:
a) PGCluster
PGCluster là hệ thống replication đồng bộ của các thành phần multi-master cho
PostgreSQL. PGCluster bao gồm ba kiểu server, một Load Balancer, Cluster DB và một
Replication server.
Hình 1: Mô hình PGCluster trong giải pháp cân bằng tải
Chức năng của PGCluster: PGCluster có hai chức năng chính:
13
- Chức năng cân bằng tải
Các yêu cầu tham chiếu của client đƣợc Load Balancer phân phối đến các
Cluster DB. Nó hiệu quả với các ứng dụng Web với yêu cầu tham chiếu
lớn.
Một đối tƣợng replication có thể đƣợc chỉ định cho mỗi bảng. Khi các bảng
nhận đƣợc một yêu cầu cập nhật và các yêu cầu tham chiếu là khác nhau,
PGCluster có thể phân phối các bảng để nhận các yêu cầu cập nhật và có
thể chỉ sao chép các bảng mà nhận yêu cầu tham chiếu.
- Tính sẵn sàng cao
Khi thất bại xảy ra trong cơ sở dữ liệu Cluster, Load Balancer và
Replication server tách cơ sở dữ liệu bị lỗi từ hệ thống và tiếp tục dịch vụ
với việc sử dụng các cơ sở dữ liệu còn lại.
Dữ liệu đƣợc sao chép tự động vào cơ sở dữ liệu phục hồi hoặc bổ sung từ
cơ sở dữ liệu khác. Trong quá trình phục hồi, các truy vấn nhận đƣợc sẽ
đƣợc thực thi từ Replication server. [12]
b) Bucardo
Bucardo là một hệ thống replication không đồng bộ, cho phép cả hai phƣơng pháp
multi-master và multi-slave. Nó đƣợc phát triển ở Backcountry.com bởi Jon Jensen và
Greg Sabino Mullane của End Point Corporation, và hiện tại nó đƣợc sử dụng ở nhiều tổ
thức khác nhau. Bucardo là phần mềm mã nguồn mở và miễn phí [13].
Bucardo là không đồng bộ. Thay vào đó, hy vọng rằng các nút thƣờng xuyên liên
lạc với nhau nhƣ hầu hết các giải pháp replication trong các hệ quản trị CSDL, Bucardo
cho phép một master ngắt kết nối để thực hiện một số lƣợng công việc tùy ý và sau đó tái
đồng bộ khi master kết nối lại với các server còn lại. Điều này làm cho nó thích hợp với
kịch bản mà cơ sở dữ liệu lƣu trữ trên một hệ thống điện thoại di động. Một máy tính
xách tay có thể chạy các server cơ sở dữ liệu, trƣớc khi bắt đầu chuyến đi, công việc đồng
bộ hóa đƣợc thực hiện, sau đó cập nhật theo cả hai hƣớng với tất cả các thay đổi đƣợc
thực hiện khi quay trở lại văn phòng.
Bucardo không phải là một giải pháp replication thích hợp cho hầu hết các yêu cầu
chuyển đổi dự phòng và tính sẵn sàng cao. Nhƣng nó có thể phù hợp với việc phân chia
14
tải giữa các máy chủ trong nhiều địa điểm, đặc biệt là nếu liên các liên kết giữa chúng
không đáng tin cậy – một tình huống mà Slony không xử lý đƣợc tốt [5].
c) Slony-I
Slony-I là một hệ thống replication master - multiple slaves không đồng bộ, nó hỗ
trợ phân tầng và failover.
Hình 2: Mô hình của Slony-I trong cân bằng tải
Slony-I có những tính năng sau:
- Replication: Slony-I đƣợc trang bị với một hệ thống không đồng bộ, master có
thể thực hiện truy vấn mà không đợi cho quá trình đồng bộ diễn ra ở slave, thậm
chí đặt một slave ở một vị trí từ xa trong một mạng chậm, nhƣ mạng WAN, thì
hiệu suất xử lý của master không hề giảm xuống. Điều này rất hữu ích khi sử
dụng replication cho các mục đích sao lƣu.
- Phân tầng: trong Slony-I có thể kết nối giữa slave với các slave khác. Khi đó,
một slave có thể vừa là một master của một số slave và vừa là một slave của một
master khác. Nếu chỉ có một master thì tải trọng trên master là rất lớn. Giải pháp
Slony-I với cơ chế phân tầng sẽ giảm tải cho master, làm tăng hiệu suất của
master nói riêng và của toàn bộ hệ thống nói chung. Tuy nhiên, khi dữ liệu đƣợc
cập nhật, thông tin về dữ liệu đó phải thông qua nhiều server nên sự khác biệt về
cơ sở dữ liệu tại một số điểm trở nên lớn hơn.
15
- Chuyển đổi dự phòng: là khả năng chuyển vai trò từ master sang slave. Master cũ
có các hành vi tƣơng đƣơng nhƣ slave sau khi quá trình failover diễn ra. Chức
năng Switchover là rất hữu ích trong trƣờng hợp khi master server bảo trì hay bị
lỗi. Do vậy, không làm gián đoạn các dịch vụ cung cấp cho client.
- Cân bằng tải: Với tất cả các tính năng trên, thì Slony-I có một đặc tính quan trọng
là cân bằng tải. Các truy vấn từ ứng dụng của client sẽ đƣợc phân phối đến các
server: truy vấn ghi đƣợc gửi đến master và truy vấn đọc đƣợc gửi đến các slave.
Do vậy, sự quá tải hệ thống là không còn và hiệu suất của hệ thống đƣợc nâng
cao[14].
d) Pgpool-II
pgpool-II là một trung gian giữa PostgreSQL server và một PostgreSQL client.
Hình 3: Mô hình pgpool-II trong cân bằng tải
pgpool-II cung cấp các tính năng sau:
- Kết nối Pooling: pgpool-II duy trì các kết nối đã đƣợc thiết lập đến PostgreSQL
server, và sử dụng lại chúng bất cứ khi nào mà một kết nối mới với cùng một
thuộc tính kết nối đến (ví dụ nhƣ cùng thuộc tính username, database, protocol
version). Nó làm giảm chi phí kết nối và cải thiện thông lƣợng tổng thể của hệ
thống.
16
- Replication: pgpool-II có thể quản lý nhiều PostgreSQL server. Kích hoạt tính
năng replication làm cho nó có thể tạo ra một bản sao lƣu thời gian thực trên hai
hay nhiều hơn PostgreSQL cluster, để dịch vụ có thể tiếp tục mà không bị gián
đoạn nếu một trong số các cluster bị lỗi.
- Load Balancing: Khi một cơ sở dữ liệu đƣợc nhân rộng, thực hiện một truy vấn
SELECT trên bất kỳ server nào cũng sẽ trả lại cùng một kết quả. pgpool-II mang
lại những lợi thế của tính năng replication để giảm tải trên mỗi PostgreSQL
server. Nó thực hiện điều đó bằng cách phân phối các truy vấn SELECT giữa các
server có sẵn, do đó cải thiện hiệu suất tổng thể của hệ thống. Trong một kịch
bản lý tƣởng, hiệu suất đọc có thể nâng cao tỉ lệ thuận với số lƣợng PostgreSQL
server. Cân bằng tải hoạt động tốt nhất trong một kịch bản mà có rất nhiều ngƣời
dùng thực hiện nhiều truy vấn đọc cùng một lúc.
- Hạn chế kết nối khi quá nhiều kết nối: có một giới hạn về số lƣợng tối đa các kết
nối đồng thời tới PostgreSQL server, và các kết nối mới bị từ chối khi mà số
lƣợng này đạt đƣợc. Có thể nâng cao số lƣợng tối đa các kết nối này, tuy nhiên,
điều này sẽ làm tăng tiêu thụ tài nguyên và có tác động tiêu cực đến hiệu suất
tổng thể. pgpool-II cũng có một giới hạn kết nối về số lƣợng tối đa các kết nối,
nhƣng các kết nối mới sẽ đƣợc thêm vào hàng đợi thay vì trả lại một lỗi ngay lập
tức.
- Truy vấn song song: sử dụng tính năng truy vấn song song, dữ liệu có thể đƣợc
phân chia giữa nhiều server, do đó một truy vấn có thể đƣợc thực thi đồng thời
trên tất cả các server, điều này làm giảm thời gian thực hiện tổng thể. Truy vấn
song song hoạt động tốt nhất khi tìm kiếm dữ liệu với quy mô lớn. pgpool-II cho
biết giao thức của PostgreSQL back-end và front-end và tiếp nhận các thông điệp
giữa một back-end và một front-end. Vì vậy, một ứng dụng cơ sở dữ liệu (front-
end) nghĩ rằng pgpool-II là một PostgreSQL thật sự và server (back-end) nhìn
pgpool-II nhƣ một trong số các client của mình. Bởi vì pgpool-II là minh bạch
cho cả server và client, một ứng dụng cơ sở dữ liệu hiện có có thể đƣợc sử dụng
với pgpool-II mà gần nhƣ không có một sự thay đổi về mã nguồn của nó [15].
Nhƣ vậy, pgpool-II không chỉ là một phƣơng pháp replication của hệ quản trị CSDL
PostgreSQL mà nó còn đóng vai trò là một Load Balancer.
17
2.2.2. Giải pháp sử dụng Partitioning cơ sở dữ liệu - Cân bằng tải các truy vấn ghi
với PL/Proxy
PL/Proxy là một ngôn ngữ thủ tục đƣợc thiết kế đặc biệt để phù hợp với nhu cầu mở
rộng quy mô cơ sở dữ liệu của Skype, trong đó bao gồm một mục tiêu là phục vụ một tỉ
ngƣời sử dụng cùng một lúc.
PL/Proxy đƣợc thiết kế để phân phối các cuộc gọi stored procedure. Nó tự động
phân phối dự liệu và đảm bảo rằng một phần nhất định của dữ liệu kết thúc tại một nút
nhất định. Khi một yêu cầu đến, PL/Proxy sẽ tự động tìm các phân mảnh, nơi mà chứa dữ
liệu cần cho yêu cầu từ client và nó sẽ lấy dữ liệu trả về cho client. Thuật toán đƣợc
PL/Proxy sử dụng để tìm các phân mảnh là thuật toán Hàm băm, dựa trên hastext của
trƣờng đang chia tách, cái mà cho phép chia tách công bằng giữa một vài các nút mà
không cần biết trƣớc sự phân bố của dữ liệu. Hastext cung cấp hàm nội bộ mà lấy bất kỳ
đầu vào là text và tạo ra đầu ra là một số nguyên nhƣ một mã băm. Một ƣu điểm chính là
các ứng dụng không biết đƣợc dữ liệu thực sự đến từ đâu - điều này đƣợc xử lý bởi
PL/Proxy – nó chỉ cần gọi một stored procedure và chờ đợi câu trả lời [5].
Hình 4: Giải pháp cân bằng tải hệ quản trị CSDL PostgreSQL với PL/Proxy
18
2.3. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL ORACLE
Oracle là một hệ quản trị CSDL đối tƣợng – quan hệ đƣợc cung cấp và phát triển
bởi tập đoàn Oracle . Đây là một hệ quản trị CSDL có tính an toàn, bảo mật cao, tính nhất
quán và toàn vẹn dữ liệu, cho phép ngƣời dùng truy cập tới cơ sở dữ liệu phân tán nhƣ
một khối thống nhất [16].
2.3.1. Giải pháp cân bằng tải phía client
Phƣơng pháp cân bằng tải này có sẵn từ Oracle 8i. Khi một phiên ngƣời dùng cố
gắng để kết nối với cơ sở dữ liệu, cơ sở dữ liệu của ngƣời nghe sẽ chỉ định phiên ngẫu
nhiên đến một trong số nhiều thiết bị đầu cuối đƣợc liệt kê để lắng nghe.
Hình 5: Giải pháp cân bằng tải cho hệ quản trị CSDL Oracle phía client
Phƣơng pháp cân bằng tải này dễ dàng đƣợc thực hiện, tuy nhiên nó cũng có một
giới hạn rõ ràng: ngƣời lắng nghe không có ý tƣởng nếu phiên ngƣời dùng không đƣợc
giao cho một thiết bị đầu cuối tƣơng ứng với cơ sở dữ liệu khi máy chủ đã quá tải. Hơn
nữa, khi ngƣời nghe chủ yếu đƣợc chọn các kết nối hoàn toàn ngẫu nhiên thì không có
đảm bảo rằng kết nối đã chọn đang sẵn sàng ở thời điểm đó. Điều này có thể buộc các
phiên ngƣời dùng chờ đợi trong một thời gian tƣơng đối dài – thậm chí là vài phút - cho
19
đến khi hệ điều hành chỉ ra cho ngƣời nghe rằng kết nối không sẵn sàng, làm cho phiên
ngƣời dùng thất bại với lỗi ORA-01034ORACLE not available[17].
2.3.2. Giải pháp cân bằng tải phía server
Do hạn chế của phƣơng pháp trên nên rõ ràng, một giải pháp tốt hơn là cần thiết, và
từ Oracle 9i đã cung cấp một cân bằng tải phía server. Phƣơng pháp cân bằng tải phía này
chia đều tải kết nối giữa tất cả các server có sẵn bằng cách xác định tổng số các kết nối
trên mỗi server, và sau đó phân bố các yêu cầu kết nối phiên ngƣời dùng đến server có tải
ít nhất dựa trên tổng số phiên đã đƣợc kết nối [17].
Hình 6: Giải pháp cân bằng tải phía server cho hệ quản trị CSDL Oracle
2.3.3. Giải pháp Oracle Real Application Cluster
Oracle Real Application Cluster (RAC) cung cấp các tùy chọn cho các ứng dụng
mở rộng quy mô vƣợt quá khả năng của một server. Điều này cho phép khách hàng tận
dụng lợi thế của chi phí phần cứng thấp để giảm tổng chi phí sở hữu của họ và cung cấp
môi trƣờng có khả năng mở rộng tính toán mà hỗ trợ khối lƣợng công việc ứng dụng của
họ.
20
Một phân cụm cơ sở dữ liệu RAC bao gồm ít nhất là hai nút (và thƣờng là nhiều
hơn), mỗi khi chạy một thể hiện riêng của cơ sở dữ liệu phân cụm. Ngoài ra, một cơ sở
dữ liệu RAC cần để cung cấp một số lƣợng tối thiểu của các kết nối và tài nguyên cho
một vài ứng dụng, vì vậy việc tải ứng dụng đó đƣợc đặt trên mỗi thể hiện trong cơ sở dữ
liệu phân cụm. Cuối cùng một cơ sở dữ liệu phân cụm RAC sẽ cần phải đảm bảo một
cardinality tối thiểu (tức là số lƣợng nút mà trên đó các ứng dụng cần chạy ở tất cả các
lần) cho một hoặc nhiều ứng dụng quan trọng [18].
Hình 7: Giải pháp cân bằng tải cho hệ quản trị CSDL Oracle Real Application Cluster
21
2.4. GIẢI PHÁP CÂN BẰNG TẢI CHO HỆ QUẢN TRỊ CSDL SQL
Hệ quản trị CSDL SQL là một hệ quản trị CSDL quan hệ, đƣợc phát triển bởi tập
đoàn Microsoft.
2.4.1. Giải pháp sử dụng Replication cơ sở dữ liệu
a) Merge replication
Merge replication đƣợc thực hiện bởi SQL Server Snapshot Agent và Merge Agent.
Nếu publication (publication đƣợc định nghĩa trong một hoặc nhiều cơ sở dữ liệu trong
Publisher, publication thiết lập các bảng, cột và các bộ lọc) không đƣợc lọc hoặc sử dụng
bộ lọc tĩnh, Snapshot Agent tạo ra một ảnh chụp duy nhất. Nếu publication sử dụng bộ
lọc tham số, Snapshot Agent tạo ra một ảnh chụp cho mỗi phân mảnh của dữ liệu. Merge
Agent áp dụng cho các ảnh chụp ban đầu đến các Subscriber. Khi dữ liệu thay đổi và
lƣợc đồ đƣợc sửa đổi ở Publisher thì Subscriber đƣợc theo dõi với các thay đổi đó.
Subscriber đồng bộ với Publisher khi kết nối mạng và trao đổi tất cả những thay đổi giữa
Publisher và Subcriber kể từ khi đồng bộ hóa xảy ra ở thời điểm gần nhất [19].
Merge replication thƣờng đƣợc sử dụng trong môi trƣờng server-client. Merger
replication thích hợp trong bất kỳ tình huống sau:
- Subscriber có thể có nhiều cập nhật cùng một dữ liệu ở các thời điểm khác nhau
và sau đó lan truyền những thay đổi đó đến Publisher và đến các Subscriber khác.
- Subscriber cần để nhận dữ liệu, làm thay đổi ngoại tuyến, và sau đó đồng bộ các
thay đổi với Publisher và các Subscriber khác.
- Mỗi Subscriber yêu cầu các phân mảnh khác nhau của dữ liệu.
- Xung đột có thể xảy ra, khi đó cần có khả năng phát hiện và giải quyết chúng.
- Ứng dụng yêu cầu dữ liệu
22
Hình 8: Giải pháp Merge replication cân bằng tải cho hệ quản trị CSDL SQL
Đây là một loại cấu hình lý tƣởng, kể từ khi Subscriber đƣợc truy vấn/cập nhật suốt
cả ngày, trong khi kho cung cấp thông tin có thể đƣợc cập nhật hàng trăm hoặc hàng ngìn
lần trƣớc khi một cập nhật đƣợc thông qua Publisher. Một hệ thống nhƣ vậy sẽ giữ cho
độ trễ mạng ở mức tối thiểu cũng nhƣ giảm tải mạng cần thiết cho một hệ thống chức
năng.
b) Transactional replication
Transactional replication thƣờng bắt đầu với một ảnh chụp của các đối tƣợng và dữ
liệu từ publication. Ngay sau khi ảnh chụp ban đầu đƣợc thực hiện, những thay đổi dữ
liệu và sửa đổi biểu đồ đƣợc thực hiện tại Publisher sẽ thƣờng xuyên đƣợc phân phối đến
Subscriber khi chúng xảy ra (gần thời gian thực). Những thay đổi dữ liệu đƣợc áp dụng
cho Subscriber trong cùng một thứ tự và trong phạm vi giao dịch giới hạn khi chúng xảy
ra ở Publisher; vì vậy, trong một publication, thống nhất giao dịch đƣợc đảm bảo.
Transactional replication thƣờng đƣợc sử dụng trong môi trƣờng server-to-server và
thích hợp trong mỗi trƣờng hợp sau:
- Các thay đổi tăng nhanh cần đƣợc truyền đến Subcriber ngay khi chúng xảy ra.
23
- Ứng dụng yêu cầu độ trễ tối thiểu giữa thời gian truyền thay đổi đƣợc tạo ra ở
Publisher đến Subscriber.
- Ứng dụng yêu cầu truy cập đến trạng thái dữ liệu trung gian. Ví dụ, nếu một
dòng thay đổi năm lần, transactional replication cho phép một ứng dụng trả lời
cho mỗi thay đổi.
- Publisher có khối lƣợng các hoạt động insert, update và delete rất lớn.
- Máy chủ cơ sở dữ liệu của Publisher hoặc Subscriber không phải là máy chủ cơ
sở dữ liệu SQL, chẳng hạn nhƣ Oracle.
Mặc định, các Subscriber đƣợc coi là read-only, bởi vì các thay đổi không đƣợc
truyền lại cho Publisher. Transactional replication không cung cấp các tùy chọn cho phép
cập nhật ở Subscriber.
Transaction replication đƣợc thực hiện bởi SQL Server Snapshot Agent, Log
Reader Agent và Distribution Agent. Snapshot Agent chuẩn bị các file ảnh chụp bao gồm
sơ đồ và dữ liệu của các bảng published và các đối tƣợng cơ sở dữ liệu, lƣu trữ các file
trong một thƣ mục ảnh chụp, và đồng bộ hóa các bản ghi trong cơ sở dữ liệu distributor
trên Distributor server.
Log Reader Agent giám sát các transaction log của mỗi cơ sở dữ liệu đƣợc cấu hình
cho transaction replication và sao lƣu các giao dịch đƣợc đánh dấu cho replication từ bản
ghi transaction trong cơ sở dữ liệu distributor, đóng vai trò nhƣ một hàng đợi lƣu trữ và
chuyển tiếp. Distribution Agent sao chép các file ảnh chụp ban đầu từ thƣ mục ảnh chụp
và các giao dịch lƣu giữ trong các bảng của cơ sở dữ liệu distribution đến Subscriber.
Các thay đổi tăng lên sẽ tạo ra ở Publisher một luồng đến Subscriber theo lịch trình
của Distribution Agent, cái mà có thể chạy liên tiếp cho độ trễ tối thiểu, hoặc trong
khoảng thời gian theo lịch trình. Bởi vì các thay đổi từ dữ liệu phải đƣợc tạo ra ở
Publisher (khi transation replication đƣợc sử dụng mà không cập nhật ngay tức khắc hoặc
tùy chọn cập nhật theo hàng đợi), tránh khỏi xung đột cập nhật. Cuối cùng, tất cả
Subscriber sẽ nhận đƣợc cùng một giá trị nhƣ Publisher. Nếu cập nhật ngay tức khắc
hoặc tùy chọn cập nhật theo hàng đợi đƣợc sử dụng với transaction replication, cập nhật
có thể đƣợc tạo ra ở Subscriber và với cập nhật theo hàng đợi thì xung đột có thể xảy ra.
24
Các Subscriber sẽ trả lời các truy vấn chỉ đọc từ client gửi đến và Publisher sẽ chịu
trách nhiệm trả lời các truy vấn ghi với các lệnh cập nhật dữ liệu nhƣ : CREATE,
UPDATE, INSERT, DELETE, DROP,… Công việc phân phối các truy vấn đến các
Subscriber và Publisher đƣợc giao cho một Load Balancer. Load Balancer phải lọc ra các
truy vấn chỉ đọc gửi đến Subsriber và các truy vấn còn lại gửi về Publisher. Nếu có nhiều
Subscriber thì Load Balancer sẽ sử dụng một thuật toán để phân tải đều cho các
Subscriber [20].
Hình 9: Giải pháp Transaction replication cân bằng tải cho hệ quản trị CSDL SQL
c) Log shipping
25
SQL server Log shipping cho phép tự động gửi các bản ghi sao lƣu giao dịch từ
primary database trên một thể hiện của primary server đến một hoặc nhiều secondary
database trên các thể hiện riêng biệt của secondary server. Các bản ghi sao lƣu giao dịch
đƣợc áp dụng cho mỗi secondary database riêng. Một tùy chọn thể hiện server thứ ba,
đƣợc gọi là monitor server, ghi lại lịch sử và trạng thái của sao lƣu và khôi phục lại các
hoạt động và, tùy chọn, đƣa ra cảnh báo nếu các hoạt động đó thất bại không xảy ra nhƣ
dự kiến.
Lợi ích của Log shipping:
- Cung cấp một giải pháp phục hồi thảm họa cho một primary database và một
hoặc nhiều secondary database, trên mỗi một thể hiện riêng biệt của SQL server.
- Hỗ trợ giới hạn truy cập read-only đến secondary database (trong khoảng thời
gian giữa các công việc khôi phục).
- Cho phép một một sự chậm chễ giữa thời gian khi primary server sao lƣu bản ghi
của primary database và khi secondary server phải khôi phục lại bản khi sao lƣu.
Một sự chậm chễ lâu hơn có thể là hữu ích, ví dụ, nếu dã liệu vô tình thay đổi
trên primary database, nếu phát hiện ra điều này một cách nhanh chóng thì thời
gian chậm chễ có thể lấy lại đƣợc dữ liệu chƣa bị thay đổi từ secondary database
trƣớc khi thay đổi đƣợc diễn ra ở secondary database [21].
Hình 10: Giải pháp Log shipping để cân bằng tải cho hệ quản trị CSDL SQL
26
2.4.2. Giải pháp Database mirroring
Database mirroring là phần mềm giải pháp chính cho việc tăng tính sẵn sàng của cơ
sở dữ liệu. Mirroring đƣợc thực hiện trên mỗi một cơ sở dữ liệu cơ bản và chỉ làm việc
với cơ sở dữ liệu mà sử dụng mô hình phục hồi đầy đủ. Các mô hình phục hồi đơn giản
và số lƣợng lớn đăng nhập không hỗ trợ database mirroring. Database mirroring đƣợc hỗ
trợ trong SQL Server Standard và Enterprise.
Database mirroring phản ảnh tính sẵn sàng quan trọng và cung cấp một cách quản lý
thay đổi dễ dàng và bổ sung đến failover clustering hoặc log shipping. Khi một phiên
database mirroring đƣợc đồng bộ hóa, database mirroring cung cấp một hot standby
server mà hỗ trợ failover nhanh chóng mà không mất dữ liệu từ commit giao dịch. Trong
một phiên mirrioring thông thƣờng, sau khi một production server bị lỗi, ứng dụng client
có thể phục hồi rất nhaanh bằng cách tái kết nối đến standby server.
Lợi ích của database mirroring
- Tăng tính sẵn sàng của cơ sở dữ liệu. Trƣơng trƣờng hợp xảy ra thảm họa, chế
độ an toàn cao với failover tự động, failover nhanh chóng mang đến một bản sao
sự phòng của cơ sở dữ liệu trực tuyến (không mất dữ liệu). Trong chế độ hoạt
động khác, ngƣời quản trị cơ sở dữ liệu có thể thay thế dịch vụ bắt buộc (với sự
mất mát dữ liệu có thể xảy ra) đến các bản sao dự phòng của cơ sở dữ liệu.
- Tăng tính bảo vệ dữ liệu. Database mirroring cung cấp sự dƣ thừa hoàn toàn hoặc
gần nhƣ hoàn toàn của dữ, phụ thuộc vào chế độ hoạt động là an toàn cao hay
hiệu năng cao.
- Cải thiện sự sẵn sàng của production database trong quá trình nâng cấp. Để
giảm thiểu thời gian chết cho cơ sở dữ liệu nhân rộng, nâng cấp tuần tự các thể
hiện của SQL server là hosting đối tác failover. Điều này sẽ bị thời gian chế chỉ ở
một failover [22].
27
Hình 11: Giải pháp Database Mirroring cân bằng tải cho hệ quản trị CSDL SQL
Database mirroring trong SQL Server yêu cầu ba thể hiện: một thể hiện chính
(principal role) quản lý cơ sở dữ liệu, một thể hiện phụ (mirror) đảm bảo việc sao lƣu cơ
sở dữ liệu, một thể hiện giám sát (witness) kết nối với hai thể hiện chính và phụ để giám
sát và đảm bảo tính sẵn sàng của cơ sở dữ liệu. Trong trƣờng hợp máy chủ chính gặp sự
cố, máy chủ witness sẽ tự động chuyển máy chủ mirror thành máy chủ chính. Nếu sau đó,
máy chủ chính hoạt động trở lại, máy chủ chính sẽ đảm nhận vai trò là máy chủ mirror
(hai máy chủ giờ đổi vai trò cho nhau) cho đến khi có sự can thiệp của nhà quản trị (Hình
11).
2.4.3. Giải pháp Network Load Balancing
Network load balancing, một công nghệ clustering có trong các hệ điều hành
Microsoft Windows 2000 Advanced Server và Datacenter Service, tăng cƣờng khả năng
mở rộng và tính sẵn sàng của nhiệm vụ quan trọng, các dịch vụ dựa trên TCP/IP, nhƣ
Web, Terminal Services và mạng riêng ảo. Thành phần này chạy trong cluster host nhƣ
một phần của hệ điều hành Windows 2000 và không yêu cầu phải hỗ trợ phần cứng
chuyên dụng. Để thực hiện quy mô, Network Load Balancing phân phối lƣu lƣợng IP qua
nhiều cluster host. Nó cũng đảm bảo tính sẵn sàng cao bằng cách phát hiện lỗi của máy
chủ và tự động phân phối lại lƣu lƣợng truy cập đến các máy chủ còn lại. Network Load
Balancing cung cấp khả năng điều khiển từ xa và hỗ trợ rolling nâng cấp từ hệ điều hành
Windows NT 4.0.
28
Các chƣơng trình máy chủ mạng hỗ trợ các ứng dụng quan trọng nhƣ giao dịch tài
chính, truy cập cơ sở dữ liệu, mạng nội bộ của công ty và các chức năng quan trọng khác
phải chạy liên tục suốt 24h/24h. Và mạng lƣới cần phải có khả năng mở rộng hiệu suất
xử lý khối lớn các yêu cầu của client mà không có sự chậm chễ. Với lí do này, clustering
đƣợc sự quan tâm rộng rãi của các doanh nghiệp. Clustering cho phép một nhóm các máy
chủ độc lập đƣợc quản lý nhƣ một hệ thống duy nhất cho tính sẵn sàng cao, quản lý dễ
dàng hơn và khả năng mở rộng lớn hơn.
Máy chủ Network Load Balancing (còn đƣợc gọi là hosts) trong một cluster giao
tiếp các cluster với nhau cung cấp các lợi ích quan trọng sau:
- Khả năng mở rộng: Network Load Balancing mở rộng hiệu suất của một chƣơng
trình dựa trên server, nhƣ Web server, bằng cách phân phối các yêu cầu của
khách hàng đến nhiều server trong cluster. Khi lƣu lƣợng tăng lên, bổ sung server
có thể đƣợc thêm trong cluster, với 32 máy chủ có thể trong bất kỳ một cluster.
- Tính sẵn sàng cao: Network Load Balancing cung cấp tính sẵn sàng cao bằng
cách tự động phát hiện server bị lỗi và phân phối lại truy cập của client đến các
server còn lại trong cluster, do vậy cung cấp cho ngƣời dùng với dịch vụ liên tục
[23].
Network Load Balancing phân phối lƣu lƣợng IP đến nhiều bản sao (hay còn gọi là
instance) của một dịch vụ TCP/IP, nhƣ Web server, mỗi web server chạy trên một hosts
trong cluster. Network Load Balancing phân chia các yêu cầu của client một cách minh
bạch giữa các hosts và cho phép client truy cập vào cluster bằng cách sử dụng một hoặc
nhiều địa chỉ IP ảo. Từ quan điểm của client, cluster xuất hiện là một server duy nhất trả
lời các yêu cầu của client. Khi tăng lƣu lƣợng truy cập doanh nghiệp, quản trị mạng có
thể chỉ cần thêm một máy chủ khác vào cluster.
29
Ví dụ:
Hình 12: Giải pháp Network load balancing cân bằng tải cho hệ quản trị CSDL SQL
Network Load Balancing có địa chỉ IP là 111.111.111.10, đây đƣợc coi là địa chỉ IP
ảo. Các server trong cluster có các địa chỉ IP là 111.111.111.1, 111.111.111.2 và
111.111.111.3. Khi client gửi yêu cầu đến thì nó sẽ gửi đến địa chỉ IP của Network Load
Balancing chứ không phải là đến địa chỉ của server, nhƣng client không hề biết điều này.
Network Load Balancing có nhiệm vụ phân phối đều các truy vấn của client đến ba
server trong cluster theo thuật toán Round robin [24].
2.5. Các thuật toán 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 đó. Trong khóa luận
đã lựa chọn ba thuật toán sau để sử dụng cho bài toán cân bằng tải.
2.5.1. Giải thuật thuật Roun-robin
Giải thuật Roun-robin là giải thuật xoay vòng, đƣợc phát biểu nhƣ sau:
30
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 Vòng 2 ….
query1 gửi về server1
query2 gửi về server2
query3 gửi về server3
….
queryk gửi về serverk
queryk+1 gửi về server1
queryk+2 gửi về server2
queryk+3 gửi về server3
….
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; i<N; i++)
for(j=0; j<K; j++)
send 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
2.5.2. Hàm băm
Hàm băm là giải thuật nhằm sinh ra các giá trị băm tƣơng ứng với mỗi
database server. Giá trị băm đóng vai gần nhƣ một khóa để phân biệt các database server.
31
Input: N truy vấn từ client
K database server có các server-id tƣơng ứng
giá trị khóa đầu vào: x
output: h(x) = giá trị băm ≡ server-id
Cách thực hiện: Giả sử giá trị khóa x là xâu ký tự
Để băm các xâu ký tự, trƣớc hết chúng ta chuyển đổi các xâu ký tự thành các số
nguyên. Các ký tự trong bảng mã ASCII gồm 128 ký tự đƣợc đánh số từ 0 đến 127, đo đó
một xâu ký tự có thể xem nhƣ một số trong hệ đếm cơ số 128. Áp dụng phƣơng pháp
chuyển đổi một số trong hệ đếm bất kỳ sang một số trong hệ đếm cơ số 10, chúng ta sẽ
chuyển đổi đƣợc một xâu ký tự thành một số nguyên. Chẳng hạn, xâu “NOTE” đƣợc
chuyển thành một số nguyên nhƣ sau:
“NOTE” „N‟.1283 + „O‟.128
2 + „T‟.128 + „E‟ =
= 78.1283 + 79.128
2 + 84.128 + 69
Vấn đề nảy sinh với cách chuyển đổi này là, chúng ta cần tính các luỹ thừa của 128,
với các xâu ký tự tƣơng đối dài, kết quả nhận đƣợc sẽ là một số nguyên cực lớn vƣợt quá
khả năng biểu diễn của máy tính.
Trong thực tế, thông thƣờng một xâu ký tự đƣợc tạo thành từ 26 chữ cái và 10 chữ
số, và một vài ký tự khác. Do đó chúng ta thay 128 bởi 37 và tính số nguyên ứng với xâu
ký tự theo luật Horner. Chẳng hạn, số nguyên ứng với xâu ký tự “NOTE” đƣợc tính nhƣ
sau:
“NOTE” 78.373 + 79.37
2 + 84.37 + 69=
= ((78.37 + 79).37 +84).37 +69
Sau khi chuyển đổi xâu ký tự thành số nguyên bằng phƣơng pháp trên, chúng ta sẽ
áp dụng phƣơng pháp chia để tính giá trị băm. Hàm băm các xâu ký tự đƣợc cài đặt nhƣ
sau:
unsigned int hash(const string &k, int K)
{
unsigned int value = 0;
32
for (int i=0; i< k.length(); i++)
value = 37 * value + k[i];
return value % K;
} [4]
Đánh giá thuật toán: hàm băm trên có thể sinh ra giá trị băm bị trùng lặp, tức là số
truy vấn trên một server có thể là không giống nhau. Tuy nhiên, thời gian thực hiện bài
toán này là rất nhanh O(n) do vậy không làm tăng thời gian chờ của client. Bên cạnh đó,
cũng giống với giải thuật Round-robin, hàm băm chỉ định server trả lời truy vấn cho
client mà không quan tâm đến trạng thái hiện tại của server đó (có ít hay nhiều truy vấn).
2.5.3. Giải thuật xác định tổng số kết nối nhỏ nhất
Giải thuật này xác định tổng số kết nối hiện tại trên các database server, nếu server
nào có tổng kết nối nhỏ nhất thì server đó sẽ đƣợc chỉ định là trả lời truy vấn tiếp theo
của client. Trong giải thuật này có quan tâm đến trạng thái của server. Đây là một giải
thuật tối ƣu để cân bằng tải cho các database server. Tuy nhiên, thời gian thực hiện bài
toán là lâu hơn hai giải thuật trên, bởi vì nó phải ghi lại và tính số kết nối đến các server
hiện thời.
33
CHƢƠNG 3: BÀI TOÁN CÂN BẰNG TẢI READ CHO HỆ QUẢN TRỊ
CSDL MYSQL VỚI MYSQL PROXY.
3.1. GIỚI THIỆU VỀ MYSQL PROXY VÀ NGÔN NGỮ KỊCH BẢN LUA
3.1.1. Giới thiệu về mysql proxy
MySQL Proxy là một ứng dụng giao tiếp qua mạng sử dụng giao thức mạng
MySQL và cung cấp thông tin liên lạc giữa một hoặc nhiều MySQL server và một hoặc
nhiều client.
Trong cấu hình cơ bản nhất, MySQL Proxy chỉ đơn giản là đặt nó giữa client và
server, chuyển các truy vấn từ client đến MySQL server và trả lại những phản hồi từ
MySQL server cho client thích hợp. Ngoài ra, MySQL Proxy cũng có khả năng giám sát
và thay đổi các thông tin liên lạc giữa client và server bằng cách sử dụng ngôn ngữ kịch
bản Lua. Bằng cách chặn các truy vấn từ client, MySQL proxy có thể sửa thông tin cho
cá truy vấn đề phù hợp với định dạng mà nó sử dụng. MySQL Proxy có thể bổ sung hay
loại bỏ những thông tin không cần thiết, sau đó đặt truy vấn vào danh sách các truy vấn
để gửi đến các server. Khi các server trả kết quả về cho client, MySQL Proxy sẽ lấy các
kết quả này lại, loại bỏ hay bổ sung các thông tin mà các truy vấn tƣơng ứng với kết quả
đó đã đƣợc bổ sung hay loại bỏ thông tin trƣớc khi gửi lên server, để trả lại kết quả cho
client. Vì vậy, các client không biết đƣợc sự có mặt của MySQL Proxy.
Một chức năng quan trọng của MySQL Proxy là nó đọc các truy vấn từ client gửi
đến và lọc ra các truy vấn đọc để gửi đến các slave, lọc ra các truy vấn ghi để gửi đến
master. Nếu có nhiều server thì mặc định MySQL Proxy sẽ sử dụng giải thuật roun-
robin để chuyển các truy vấn đến các server này.
Khi chỉ định nhiều server theo cách này thì MySQL Proxy tự động xác định các server
đang rỗi hay bận. Nếu server bận thì nó sẽ chỉ định server khác để thay thế [25].
MySQL Proxy có thể chạy trên nhiều nên tảng khác nhau nhƣ:
Linux (bao gồm Red Hat, Fedora, Debian, OpenSuSe, Ubuntu)
Mac OS X
FreeBSD
IBM AIX
34
Sun Solaris
Microsoft Windows (bao gồm: Microsoft Windows XP, Microsoft
Windows Vista, Microsoft Windows 2007, Microsoft Windows Server 2003,
Microsoft Windows Server 2008)
3.1.2. Giới thiệu về ngôn ngữ kịch bản Lua
Lua là một ngôn ngữ lập trình thông dịch với đặc điểm nhỏ gọn, thƣờng đƣợc dùng
để viết các file cấu hình trong những phần mềm lớn.
Lua có một số ƣu điểm nổi bật sau
- Tính mở rộng: Ngƣời ta không chỉ quan tâm đến Lua nhƣ một ngôn ngữ mà còn
là một công cụ để xây dựng một ngôn ngữ. Lua dễ dàng giao tiếp với ngôn ngữ
C/C++ và những ngôn ngữ khác nhƣ Fortran, Java, Smalltalk, Ada, và thậm chí
với những ngôn ngữ scripting khác.
- Tính đơn giản: Lua là một ngôn ngữ đơn giản và nhỏ. Nó có rất ít các khái niệm,
kiểu dữ liệu nhƣng lại rất mạnh. Lua rất dễ học và dễ tích hợp vào những chƣơng
trình lớn.
- Tính hiệu quả: chƣơng trình đƣợc viết bằng Lua thực thi khá nhanh, nó đƣợc
đánh giá là một trong những ngôn ngữ nhanh nhất trong những ngôn ngữ kịch
bản.
- Tính khả chuyển: Lua không chỉ chạy tốt trên Windows và Unix mà nó còn chạy
tốt trên mọi platforms nhƣ NextStep, OS/2, …
- Tính đa dạng thức: Lua có cấu trúc đa dạng nhƣng giải quyết đƣợc nhiều vấn đề
phức tạp khác nhau. Lua không có tính kế thừa nhƣng cho phép tạo ra mối quan
hệ đó đối với metatable.
- Thư viện dễ thay đổi: Lua có thể mở rộng các kiểu dữ liệu và các hàm của thƣ
viện.
- Tính tích hợp: sử dụng Lua để tích hợp vào các chƣơng trình ứng dụng của mình
[26].
35
3.1.3. Nguyên lý hoạt động của MySQL Proxy với ngôn ngữ kịch bản Lua [25]
Sự tƣơng tác chính giữa Proxy MySQL và MySQL server đƣợc cung cấp bởi việc
xác định một hoặc nhiều hàm trong ngôn ngữ kịch bản Lua. Một số hàm đƣợc hỗ trợ cho
các sự kiện khác nhau và các hoạt động khác nhau trong thứ tự giao tiếp giữa client và
một hoặc nhiều MySQL server:
connect_server() : Hàm này đƣợc gọi mỗi khi có một kết nối đến MySQL
Proxy từ một client. MySQL Proxy sử dụng chức năng này trong quá trình cân bằng
tải để chặn các kết nối từ một client và quyết định máy chủ nào sẽ giao tiếp với
client đó. Nếu không xác định một giải pháp đặc biệt, thì MySQL Proxy mặc định
sẽ phân phối các truy vấn theo giải thuật round-robin.
read_handshake (): Hàm này đƣợc gọi là khi những thông tin bắt tay đầu
tiên đƣợc trả về bởi server. Proxy có thể nắm bắt những thông tin bắt tay đƣợc trả
lại này và kiểm tra, bổ sung trƣớc khi trao đổi diễn ra.
read_auth (): Hàm này đƣợc gọi khi các gói tin xác nhận (tên ngƣời dùng,
mật khẩu, cơ sở dữ liệu mặc định) của client gửi đến server để xác thực.
read_auth_result (): Hàm này đƣợc gọi là khi server trả về một gói tin xác
nhận cho client nêu rõ việc xác thực đã thành công.
read_query (): Hàm này đƣợc gọi mỗi lần truy vấn đƣợc gửi bởi client đến
server. Proxy có thể chỉnh sửa và thao tác truy vấn gốc, bao gồm thêm các câu truy
vấn mới trƣớc và sau câu lệnh gốc. Ngoài ra cũng có thể sử dụng hàm này để trả về
thông tin trực tiếp đến client. Sử dụng hàm này, proxy có thể lọc các truy vấn không
mong muốn hoặc các truy vấn vƣợt quá giới hạn đƣợc biết đến.
read_query_result (): Hàm này đƣợc gọi là mỗi khi một kết quả đƣợc trả về
từ server, proxy tự động xen các truy vấn vào hàng đợi truy vấn. Proxy thể chỉnh
sửa các tập hợp kết quả, hoặc để loại bỏ hoặc chọn lọc các bộ kết quả.
Thứ tự truy vấn
36
Hình 13: Các thủ tục cần thực hiện khi client gửi một truy vấn đến server qua MySQL
Proxy
1. Khi client gửi một kết nối đến server, MySQL Proxy gọi hàm
connect_server() để gửi yêu cầu kết nối này đến server. Server nhận đƣợc yêu cầu
kết nối của client sẽ gửi lại thông điệp là nó có chấp nhận yêu cầu này hay không.
Nếu server không chấp nhận thì client ngừng kết nối, nếu server chấp nhận thì thực
hiện bƣớc thứ hai
2. Client gửi truy vấn đến server. MySQL Proxy sử dụng hàm read_query()
để đọc truy vấn này, nó xác định đây là loại truy vấn nào để gửi đến server thích
hợp.
3. Sau khi server chấp nhận truy vấn từ client, server gửi kết quả lại cho
client. Kết quả này đi qua MySQL Proxy, MySQP Proxy đọc kết quả bằng cách sử
dụng hàm read_query_result() và trả về kết quả này cho client.
Cấu trúc nội bộ
Ngoài các hàm trên, một số cấu trúc đƣợc xây dựng cung cấp việc kiểm soát của
MySQL Proxy để chuyển các truy vấn và trả về các kết quả bằng cách cung cấp một giao
diện đơn giản hóa các yếu tố nhƣ danh sách các truy vấn và nhóm các tập kết quả đƣợc
trả về.
37
3.2. GIỚI THIỆU VỀ GIẢI PHÁP REPLICATION TRONG 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ễ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:
# log-bin - /data/logs/binary/changelog
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
auto_increment_increment = 10
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].
3.3. GIỚI THIỆU VỀ CÔNG CỤ MYSQLSLAP
mysqlslap là công cụ trong mysql-client đƣợc thiết kế để giả lập các client nhằm
kiểm tra tải cho máy chủ MySQL, đồng thời báo cáo thời gian máy chủ MySQL trả về
kết quả truy vấn cho client.
mysqlslap chạy trong ba giai đoạn:
Giai đoạn 1: tạo lƣợc đồ, bảng và tùy chọn bất kỳ các chƣơng trình lƣu trữ hoặc dữ
liệu để sử dụng cho việc kiểm tra. Trong giai đoạn này chỉ sử dụng kết nối từ một
client.
Giai đoạn 2: Chạy kiểm tra tải. Giai đoạn này có thể sử dụng nhiều client để kết
nối.
Giai đoạn 3: Làm sạch (ngắt kết nối từ client, xóa dữ liệu, bảng và lƣợc đồ nếu
đƣợc chỉ định). Trong giai đoạn này cũng chỉ sử dụng một client để kết nối.
Ví dụ 1:
mysqlslap --delimiter=";"
--create="CREATE TABLE a (b int); INSERT INTO a VALUES (23)"
--query="SELECT * FROM a"
--concurrency=50 --iterations=200
Trong ví dụ này, công cụ mysqlslap tạo bảng a, chèn dữ liệu vào bảng a và sinh truy
hiển thị tất cả dữ liệu trong bảng a đến máy chủ MySQL; với số client kết nối đến là 50
và đƣợc lặp lại 200 lần.
Ví dụ 2:
43
mysqlslap --concurrency=5
--iterations=5
--query=query.sql --create=create.sql
--delimiter=";"
Trong ví dụ này, các câu lệnh tạo bảng, chèn dữ liệu không hiển thị trực tiếp trong
câu lệnh của mysqlslap mà đƣợc ghi trong file create.sql, các câu lệnh đƣợc phân biệt với
nhau bằng dấu “;”. File query.sql chứa nhiều câu lệnh truy vấn đến máy chủ MySQL, các
câu lệnh đƣợc phân biệt với nhau bằng dấu “;”. Số client kết nối là 5 và đƣợc lặp lại 5
lần.
Ví dụ 3:
mysqlslap --auto-generate-sql
--auto-generate-sql-load-type=write
--concurrency=200 --iterations=50
--number-of-queries=100
Trong ví dụ này, với tùy chọn --auto-generate-sql mysqlslap tự động sinh ra lƣợc
đồ, bảng và dữ liệu mà không phải là chúng ta chỉ định. Mặc định, lƣợc đồ đƣợc sinh ra
có tên là “mysqlslap”, với một bảng tên là “t1(id serial,intcol1 INT(32),charcol1
VARCHAR(128))” và tự động chèn dữ liệu vào bảng. Tùy chọn --auto-generate-sql-sql-
load-type đƣợc sử dụng để sinh ra kiểu truy vấn nhằm kiểm tra tải, với các giá trị là:
write, read, mixed, update và key. Trong trƣờng hợp này, kiểu truy vấn để kiểm tra tải là
write. Số client đƣợc sinh ra để kết nối đến máy chủ là 500, đƣợc lặp lại 50 lần và số
lƣợng truy vấn sinh ra cho mỗi client kết nối đến là 100 [27].
3.4. PHÁT BIỂU BÀI TOÁN
Bài toán cân bằng tải cơ sở dữ liệu MySQL sử dụng MySQL Proxy đƣợc phát biểu
nhƣ sau:
Với N là số lƣợng truy cập của ngƣời dùng đến server, K là số lƣợng slave server
đƣợc Replication từ một master server và một MySQL Proxy. Sử dụng các mô hình
Replication hãy cấu hình MySQL Proxy cho từng mô hình mà MySQL Proxy có thể
thực hiện cân bằng tải cho K slave server và master server, sau đó đánh giá hiệu năng và
tải của từng server trên mỗi mô hình và đƣa ra mô hình tốt nhất.
44
Việc MySQL Proxy thực hiện cân bằng tải cho K slave server và master serve tức
là:
- MySQL Proxy có thể chuyển tất cả M (M<N) truy vấn là đọc của ngƣời dùng
đến tất cả K slave server mà không có xung đột và hợp lý nhất, và
- Chuyển N-M truy vấn là ghi của ngƣời dùng đến master server. (Sau khi chấp
nhận truy vấn ghi thì cơ sở dữ liệu trên master server có sự thay đổi, khi đó nó
lập tức đồng bộ cơ sở dữ liệu đến tất cả K slave server bằng việc sử dụng giải
pháp Replication
3.5. MÔ HÌNH GIẢI QUYẾT BÀI TOÁN
3.4.1. Mô hình MySQL Proxy – một master – một slave
Trong mô hình này, một master đƣợc kết nối với một slave. Proxy đƣợc đặt giữa
client với các server. Master quản lý trực tiếp slave, khi có sự thay đổi dữ liệu trên master
thì nó sẽ đồng bộ dữ liệu đến slave. Các truy vấn client gửi đến server đi qua MySQL
Proxy, đƣợc MySQL Proxy xử lý, lọc ra các truy vấn đọc gửi đến các slave và các truy
vấn ghi đƣợc gửi đến master
Hình 18: Mô hình master-slave replication với MySQL Proxy
3.4.2. Mô hình MySQL Proxy – một master – multi slave
Trong mô hình này, một master đƣợc kết nối với nhiều slave. Proxy đƣợc đặt giữa
client với các server. Master quản lý trực tiếp các slave, khi có sự thay đổi dữ liệu trên
45
master thì nó sẽ đồng bộ dữ liệu đến tất cả các slave. Các truy vấn client gửi đến server đi
qua MySQL Proxy, đƣợc MySQL Proxy xử lý, lọc ra các truy vấn đọc gửi đến các slave
theo giải thuật round-robin và các truy vấn ghi đƣợc gửi đến master
Hình 19: Mô hình master – multi salve replication với MySQL Proxy
46
CHƢƠNG 4: THỰC NGHIỆM VÀ ĐÁNH GIÁ
Dựa vào mô hình đề xuất ở chƣơng 3, tôi tiến hành thực nghiệm để đánh giá khả
năng cân bằng tải cho hệ quản trị CSDL MySQL với MySQL proxy.
4.1. MÔI TRƢỜNG THỰC NGHIỆM
Môi trƣờng thực nghiệm cần ít nhất ba máy tính: trong đó hai hoặc ba máy là
MySQL server – một master và một slave, một máy là MySQL Proxy, client có thể ở một
trong ba máy. Ba máy đƣợc kết nối mạng với nhau để sao cho các máy có thể giao tiếp
đƣợc với nhau. Trong khóa luận, tôi sử dụng mạng LAN để kết nối ba máy, mỗi máy có
một địa chỉ IP cố định và riêng biệt.
Bảng 1: Cấu hình các máy
Tên máy Cấu hình Địa chỉ IP Cổng Hệ điều
hành
Master 10.10.17.40 3306 Debian
Slave 1 10.10.17.5 3306 CentOS
Salve 2 10.10.17.100 3306 OpenSUSE
MySQL Proxy 10.10.17.100 4040 OpenSUSE
4.2. TIẾN HÀNH THỰC NGHIỆM
4.2.1. Cài đặt MySQL Proxy
MySQL Proxy có thể cài đặt theo ba cách khác nhau:
- Cài đặt MySQL Proxy từ phân phối nhị phân
- Cài đặt MySQL Proxy từ mã nguồn (nếu muốn cài đặt trên các môi trƣờng mà
không đƣợc hỗ trợ bởi phân phối nhị phân).
- Cài đặt từ kho Bazaar: phiên bản mới nhất của MySQL Proxy có sẵn trong kho
Bazaar này, đây là cách cài đặt tốt nhất để có thể cập nhật phiên bản mới nhất
cho MySQL Proxy.
47
Trong khóa luận, tôi cài đặt MySQL Proxy theo cách thứ ba: cài đặt từ kho
Bazaar. Để cài đặt MySQL Proxy theo cách này thì cần phải làm theo các bƣớc sau:
Bƣớc 1: Cài đặt các gói phần mềm sau:
bzr 1.10.0 trở lên
autoconf 2.56 trở lên
automake 1.10 trở lên
libevent 1.3 trở lên
lua 5.1 trở lên
glib2 2.4.0 trở lên
pkg-config
mysql 5.0 trở lên
Ngoài ra, tùy theo từng hệ điều hành mà có thể cần phải cài các gói sau: lua-devel,
glib2-devel, mysql-devel, libffi46, libffi46-devel, libreadline6, readline5-devel
Bƣớc 2: Biên dịch các gói phần mềm:
- Đối với libevent:
# wget https://github.com/downloads/libevent/libevent/libevent-2.0.17-stable.tar.gz
# tar zvfx libevent-2.0.17-stable.tar.gz
# cd libevent-2.0.17-stable
# ./configure
# make
# make install
- Đối với glib2
# wget http://fossies.org/unix/misc/glib-2.30.2.tar.gz
# tar zvfx glib-2.30.2.tar.gz
# cd glib-2.30.2/
# ./configure
48
# make
# make install
- Đối với lua
# wget http://www.lua.org/ftp/lua-5.1.5.tar.gz
# tar xvfz lua-5.1.5.tar.gz
# cd lua-5.1.5/
# make linux
# make install
# cp /etc/lua.pc /usr/local/lib64/pkgconfig/
- Đối với mysql-proxy
# bzr branch lp:mysql-proxy
# tar xvfz mysql-proxy-0.8.2.tar.gz
# cd mysql-proxy-0.8.2/
# sh ./autogen.sh
# ./configure
# make
# make install
# /sbin/ldconfig
Bƣớc 3: Chạy thử MySQL Proxy
# mysql-proxy –V
mysql-proxy 0.9.0
chassis: mysql-proxy 0.9.0
glib2: 2.30.2
libevent: 2.0.10-stable
LUA: Lua 5.1.4
49
package.path: /usr/local/lib/mysql-proxy/lua/?.lua
package.cpath: /usr/local/lib/mysql-proxy/lua/?.so
-- modules
admin: 0.9.0
proxy: 0.9.0
4.2.2. Cấu hình cho giải pháp replication trong hệ quản trị CSDL MySQL [7]
a) Giải pháp replication đơn giản: một master – một slave
Cấu hình bên master:
Bước 1: Sửa file cấu hình của my.cnf của MySQL:
[mysqld]
server-id = 1
log-bin = mysql-bin
log-bin-index = mysql-bin.index
Bước 2: Khởi động lại MySQLD
# /etc/init.d/mysql restart
Bước 3: Tạo ngƣời dùng cho replication:
mysql> CREATE UER „replication_user_name‟@„domain.com/IP address‟
IDENTIFIED BY „replication_password‟;
mysql>GRANT REPLICATION SLAVE ON *.* TO
„replication_user_name‟@„domain.com/IP address‟;
mysql>FLUSH PRIVILEGES;
Bước 4: Xem thông tin trạng thái của master
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
mysql> UNLOCK TABLES;
50
Cấu hình bên slave:
Bước 1: sửa file cấu hình my.cnf:
[mysqld]
server-id = 2
relay-log = slave-relay-bin
relay-log-index = slave-relay-bin.index
Giá trị của server-id có thể là một số nguyên khác, miễn là giá trị này không đƣợc
trùng với giá trị của server-id bên master.
Bước 2: Kết nối slave đến master:
Để kết nối slave đến master, có thể sửa trong file cấu hình my.cnf hoặc chạy lệnh
nhƣ sau:
mysql > CHANGE MASTER TO
> MASTER_HOST = “master_host_name”,
> MASTER_USER = “replication_user_name”,
> MASTER_PASSWORD = “replication_password”,
> MASTER_LOG_FILE = “mysql-bin.xxxxx”,
> MASTER_LOG_POS = mysql-bin-position;
mysql-bin.xxxxx là tên file mysql-bin và mysql-bin-possition là vị trí của file mysql-
bin đƣợc hiển thị trong lệnh SHOW MASTER STATUS bên master.
Bƣớc 3: Chạy slave và kiểm tra trạng thái của slave
mysql > START SLAVE;
mysql > SHOW SLAVE STATUS \G
Slave_IO_State: Connecting to master
Master_Host : 10.10.17.40
Master_User : slave2
Master_Port : 3306
Connect_Retry : 60
51
Master_Log_File : mysql-bin.000054
Read_Master_Log_Pos : 480815
Relay_Log_File : slave-relay-bin.000050
Relay_Log_Pos : 4
Relay_Master_Log_File : mysql-bin.000054
Slave_IO_Running : Connecting
Slave_SQL_Running : Yes
b) Giải pháp replication master – multi slave
Trong giải pháp này, các bƣớc thực hiện cấu hình ở master và các slave cũng tƣơng
tự nhƣ trong mô hình trên. Tuy nhiên, nếu có bao nhiều slave thì trên master phải tạo ra
bấy nhiêu ngƣời dùng replication cho các slave, và mỗi slave phải có một server-id riêng
biệt.
4.2.3. Kịch bản Lua
MySQL Proxy hoạt động nhờ ngôn ngữ kịch bản Lua, mọi hoạt động của MySQL
Proxy nhƣ kết nối đến máy chủ MySQL, nhận các truy vấn từ client, nhận truy vấn trả về
từ máy chủ MySQL, lọc ra các truy vấn đọc và ghi,… đƣợc thực hiện do các kịch bản của
ngôn ngữ Lua.
Kịch bản quan trọng nhất của MySQL Proxy trong bài toán cân bằng tải là “read-
write-splitting.lua” – lọc ra các truy vấn đọc/ghi – đƣợc thực hiện trong hàm
read_query(). Các truy vấn đọc – SELECT – gửi đến máy chủ slave, các truy vấn ghi còn
lại – CREATE, INSERT, UPDATE, DROP, DELETE – gửi về master. Sau đây là trích
đoạn trong kịch bản “read-write-splitting.lua”:
proxy.queries:append(1, packet, { resultset_is_needed = true })
-- read/write splitting
-- send all non-transactional SELECTs to a slave
if not is_in_transaction and
cmd.type == proxy.COM_QUERY then
52
tokens = tokens or assert(tokenizer.tokenize(cmd.query))
local stmt = tokenizer.first_stmt_token(tokens)
if stmt.token_name == "TK_SQL_SELECT" then
is_in_select_calc_found_rows = false
local is_insert_id = false
for i = 1, #tokens do
local token = tokens[i]
if not is_in_select_calc_found_rows
and (token.token_name ==
"TK_SQL_SQL_CALC_FOUND_ROWS"
or (token.token_name == "TK_FUNCTION"
and token.text:upper() == "FOUND_ROWS"))
then
is_in_select_calc_found_rows = true
elseif not is_insert_id and token.token_name ==
"TK_FUNCTION"
and token.text:upper() ==
"LAST_INSERT_ID" then
is_insert_id = true
elseif not is_insert_id and token.token_name ==
"TK_LITERAL" then
local utext = token.text:upper()
if utext == "@@INSERT_ID" then
is_insert_id = true
end
53
end
-- we found the two special token, we can't find more
if is_insert_id and is_in_select_calc_found_rows then
break
end
end
-- if we ask for the last-insert-id we have to ask it on the original
-- connection
if is_insert_id then
print(" found a SELECT LAST_INSERT_ID(), going to master")
elseif is_in_select_calc_found_rows then
print(" need to calculate the rows, going to master")
else -- neither of these two, pick an idle slave
local backend_ndx = lb.idle_ro()
if backend_ndx > 0 then
proxy.connection.backend_ndx = backend_ndx
end
end
end
end
4.2.4. Thử nghiệm
a) Chạy MySQL Proxy
Chạy MySQL Proxy với dòng lệnh sau:
# mysql-proxy --admin-username=root \
> --admin-password=giang \
54
> --admin-address=10.10.17.100:4041 \
> --proxy- address=10.10.17.100:4040\
> --proxy-backend-addresses=10.10.17.40:3306 \
> --proxy-read-only-backend-addresses=10.10.17.5:3306 \
> --admin-lua-script=/home/giangvit/workspace/proxy/admin-script.lua \
> --proxy-lua-script=/home/giangvit/workspace/mysqlProxy/rw4.lua
Trong đó:
--admin-username=user_name là tùy chọn xác thực ngƣời dùng cho modul quản trị
--admin-password=password là tùy chọn xác thực mật khẩu cho modul quản trị
--admin-address=host:port là tùy chọn xác định modul quản trị lắng nghe trên tên
miền (hoặc địa chỉ IP) nào và cổng nào (mặc định cổng đƣợc lắng nghe là 4041)
--proxy-address=host:port là tùy chọn xác định tên miền (hoặc địa chỉ IP) và cổng
(mặc định cổng đƣợc lắng nghe là 4040) của MySQL Proxt
--proxy-backend-addresses=host:port là tùy chọn xác định tên miền (hoặc địa chỉ
IP) và cổng của máy chủ MySQL – master – mà MySQL Proxy kết nối tới. Trong trƣờng
hợp có nhiều master, có thể chỉ định nhiều tùy chọn này, khi đó các client kết nối đến
mỗi master theo giải thuật round-robin. Ví dụ, nếu có hai máy chủ MySQL là master A
và B thì xác định hai tùy chọn:
--proxy-backend-addresses=hostA:portA \
--proxy-backend-addresses=hostB:portB
Khi đó, client thứ nhất kết nối đến máy chủ A, client thứ hai kết nối đến máy chủ B,
sau đó lại quay về máy chủ A cho kết nối từ client thứ ba…
--proxy-read-only-backend-addresses=host:port là tùy chọn xác định tên miền
(hoặc địa chỉ IP) và cổng của máy chủ MySQL chỉ trả lời các truy vấn đọc từ client –
máy chủ slave – mà MySQL Proxy kết nối tới. Trong trƣờng hợp có nhiều máy chủ slave
thì có thể chỉ định nhiều tùy chọn này, mỗi tùy chọn xác định một máy chủ slave. Khi đó,
55
các client kết nối đến các máy chủ này đƣợc MySQL Proxy chỉ định theo thuật toán cân
bằng tải.
--admin-lua-script=file_name là tùy chọn xác định file kịch bản Lua để sử dụng cho
modul quản trị proxy.
--proxy-lua-script=file_name là tùy chọn xác định file kịch bản Lua đƣợc nạp vào
hành động của MySQL Proxy. Trong trƣờng hợp này, file kịch bản đƣợc sử dụng để cân
bằng tải đến các máy chủ MySQL Proxy: read-write-splitting.lua.
b) Client kết nối đến MySQL Proxy
Chạy lệnh mysqlslap với các tham số nhƣ dƣới đây:
# mysqlslap --auto-generate-sql \
> --auto-generate-sql-load-type=read \
> --host=10.10.17.100 --port=4040 \
> --concurrency=100 \
> --number-of-queries=100
Trong quá trình kiểm tra, các tùy chọn --concurrency, --number-of-queries có giá trị
tăng dần.
Khi kết nối đến máy chủ MySQL, client không biết sự có mặt của MySQL proxy.
Client chỉ biết đến một địa chỉ IP duy nhất là địa chỉ IP của MySQL Proxy –
10.10.17.100 – và cổng lắng nghe là 4040. Client nghĩ rằng máy chủ MySQL đang trực
tiếp lắng nghe truy vấn của mình.
4.3. PHÂN TÍCH, ĐÁNH GIÁ KẾT QUẢ THỰC NGHIỆM
4.3.1. Client gửi truy vấn trực tiếp đến máy chủ MySQL
Trong mô hình thực nghiệm này, chỉ có duy nhất một MySQL server. Client trực
tiếp gửi truy vấn đến server. Lần lƣợt tăng số truy vấn và số client kết nối đến server, thu
đƣợc kết quả nhƣ sau:
56
Bảng 2: Kết quả thời gian chạy các truy vấn trong mô hình chỉ có một MySQL server
--number-of-queries --concurrency Average number of seconds to run queries
100 100 5
600 600 35.710
1400 700 45.252
1600 800 Quá tải
b) Hiệu năng của máy
Hình 200: Hiệu năng của server trong mô hình chỉ có duy nhất MySQL server
4.3.2. Mô hình MySQL Proxy – một master – một slave
Mô hình này bao gồm một giải pháp replication với một master và một slave.
Máy chủ master có địa chỉ IP và cổng là 10.10.17.40:3306.
Máy chủ slave có địa chỉ IP và công là: 10.10.17.5:3306
MySQL Proxy có địa chỉ IP là 10.10.17.100, lắng nghe trên cổng 4040.
Sử dụng máy có địa chỉ IP là 10.10.17.40 làm client để kết nối đến các máy chủ.
a) Kết quả chạy của MySQL Proxy:
57
Giai đoạn 1 của quá trình công cụ mysqlslap chạy:
Tự động sinh ra lƣợc đồ “mysqlslap”,
Bảng “t1” với ba trƣờng là: id serial, intcol1 INT(32),charcol1 VARCHAR(128)
Sinh dữ liệu ngẫu nhiên và chèn vào bảng t1
Toàn bộ các truy vấn từ client gửi đến đƣợc MySQL Proxy gửi về master:
sending to backend : 10.10.17.40:3306
is_slave : false
# mysql-proxy --admin-username=root \
> --admin-password=giang \
> --admin-address=10.10.17.100:4041 \
> --proxy- address=10.10.17.100:4040\
> --proxy-backend-addresses=10.10.17.40:3306 \
> --proxy-read-only-backend-addresses=10.10.17.5:3306 \
> --admin-lua-script=/home/giangvit/workspace/proxy/admin-script.lua \
> --proxy-lua-script=/home/giangvit/workspace/mysqlProxy/rw4.lua
2012-05-15 16:47:32: [global] (*) mysql-proxy 0.9.0 started
[connect_server] 10.10.17.40:36443
[1].connected_clients = 0
[1].pool.cur_idle = 0
[1].pool.max_idle = 1000000
[1].pool.min_idle = 1
[1].type = 1
[1].state = 0
[1] idle-conns below min-idle
[read_query] 10.10.17.40:36443
58
current backend = 0
client default db =
client username = root
query = DROP SCHEMA IF EXISTS `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:36443
current backend = 0
client default db =
client username = root
query = CREATE SCHEMA `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:36443
current backend = 0
59
client default db =
client username = root
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : false
[read_query] 10.10.17.40:36443
current backend = 0
client default db = mysqlslap
client username = root
query = CREATE TABLE `t1` (id serial,intcol1 INT(32),charcol1 VARCHAR(128))
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:36443
current backend = 0
client default db = mysqlslap
client username = root
60
query = INSERT INTO t1 VALUES
(NULL,1804289383,'mxvtvmC9127qJNm06sGB8R92q2j7vTiiITRDGXM9ZLzkdekb
WtmXKwZ2qG1llkRw5m9DHOFilEREk3q7oce8O3BEJC0woJsm6uzFAEynLH2xCsw
1KQ1lT4zg9rdxBL')
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
(read_query_result) staying on the same backend
in_trans : false
in_calc_found : false
have_insert_id : true
61
Giai đoạn 2 của chạy công cụ mysqlslap: tự động sinh ra các truy vấn đọc:
query = SELECT intcol1,charcol1 FROM t1
để kiểm tra tải của hai máy chủ master và slave.
Toàn bộ các truy vấn này đƣợc gửi về slave:
sending to backend : 10.10.17.5:3306
is_slave : true
[read_query] 10.10.17.40:36471
current backend = 0
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.5:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:36471
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[disconnect_client] 10.10.17.40:36471
[read_query] 10.10.17.40:36472
62
current backend = 0
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.5:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:36472
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[disconnect_client] 10.10.17.40:36472
63
Giai đoạn 3 của quá trình chạy công cụ mysqlslap:
mysqlslap làm sạch quá trình kiểm tra bằng việc xóa dữ liệu và lƣợc đồ đƣợc tạo ra
ở giai đoạn 1 để không làm ảnh hƣởng đến cơ sở dữ liệu sẵn có của máy chủ:
query = DROP SCHEMA IF EXISTS `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
Truy vấn này đƣợc gửi về master.
Đồng thời mysqlslap ngắt kết nối đến máy chủ.
[read_query] 10.10.17.40:47303
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[read_query] 10.10.17.40:40536
current backend = 0
client default db = mysqlslap
client username = root
query = DROP SCHEMA IF EXISTS `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
64
[disconnect_client] 10.10.17.40:47303
[read_query] 10.10.17.40:40536
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[disconnect_client] 10.10.17.40:40536
b) Kết quả thời gian trả về từ công cụ mysqlslap
Kết quả thực nghiệm thời gian chạy các truy vấn trong mô hình này nhƣ bảng sau:
Bảng 3: Kết quả thời gian chạy các truy vấn trong mô hình MySQL Proxy-master-slave
--number-of-queries --concurrency Average number of seconds to run queries
100 100 3.691
600 600 9.348
1500 700 9.599
2000 800 10.470
4.3.3. Mô hình MySQL Proxy – một master – hai slave
Mô hình này bao gồm MySQL Proxy và một giải pháp replication với một master
và hai slave.
Máy chủ master có địa chỉ IP và cổng là 10.10.17.40:3306.
Máy chủ slave thứ nhất có địa chỉ IP và công là: 10.10.17.5:3306
Máy chủ slave thứ hai có địa chỉ IP và cổng là: 10.10.17.100:3306
MySQL Proxy có địa chỉ IP là 10.10.17.100, lắng nghe trên cổng 4040.
65
Sử dụng máy có địa chỉ IP là 10.10.17.40 làm client để kết nối đến các máy chủ.
a) Kết quả chạy của MySQL Proxy:
Kết quả chạy của MySQL Proxy trong mô hình này ở hai giai đoạn 1 và giai đoạn 3
của quá trình chạy công cụ mysqlslap có kết quả tƣơng tự trong giai đoạn 1 và giai đoạn
3 ở mô hình MySQL Proxy – một master – một slave:
Giai đoạn 1 của quá trình chạy công cụ mysqlslap
# mysql-proxy --admin-username=root \
> --admin-password=giang \
> --admin-address=10.10.17.100:4041 \
> --proxy- address=10.10.17.100:4040\
> --proxy-backend-addresses=10.10.17.40:3306 \
> --proxy-read-only-backend-addresses=10.10.17.5:3306 \
> --proxy-read-only-backend-addresses=10.10.17.100:3306 \
> --admin-lua-script=/home/giangvit/workspace/proxy/admin-script.lua \
> --proxy-lua-script=/home/giangvit/workspace/mysqlProxy/rw4.lua
2012-05-15 16:47:32: [global] (*) mysql-proxy 0.9.0 started
[connect_server] 10.10.17.40:38453
[1].connected_clients = 0
[1].pool.cur_idle = 0
[1].pool.max_idle = 1000000
[1].pool.min_idle = 1
[1].type = 1
[1].state = 0
[1] idle-conns below min-idle
66
[read_query] 10.10.17.40:38453
current backend = 0
client default db =
client username = root
query = DROP SCHEMA IF EXISTS `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:38453
current backend = 0
client default db =
client username = root
query = CREATE SCHEMA `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:38453
67
current backend = 0
client default db =
client username = root
sending to backend : 10.10.17.40:3306
is_slave : false
server default db:
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : false
[read_query] 10.10.17.40:38453
current backend = 0
client default db = mysqlslap
client username = root
query = CREATE TABLE `t1` (id serial,intcol1 INT(32),charcol1 VARCHAR(128))
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:38453
current backend = 0
client default db = mysqlslap
68
client username = root
query = INSERT INTO t1 VALUES
(NULL,1804289383,'mxvtvmC9127qJNm06sGB8R92q2j7vTiiITRDGXM9ZLzkdekb
WtmXKwZ2qG1llkRw5m9DHOFilEREk3q7oce8O3BEJC0woJsm6uzFAEynLH2xCsw
1KQ1lT4zg9rdxBL')
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
(read_query_result) staying on the same backend
in_trans : false
in_calc_found : false
have_insert_id : true
69
Giai đoạn 3 của quá trình chạy công cụ mysqlslap:
[read_query] 10.10.17.40:47303
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[read_query] 10.10.17.40:40536
current backend = 0
client default db = mysqlslap
client username = root
query = DROP SCHEMA IF EXISTS `mysqlslap`
sending to backend : 10.10.17.40:3306
is_slave : false
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[disconnect_client] 10.10.17.40:47303
[read_query] 10.10.17.40:40536
current backend = 0
client default db = mysqlslap
client username = root
(QUIT) current backend = 0
[disconnect_client] 10.10.17.40:40536
70
Sự khác nhau chính là ở giai đoạn 2 của quá trình chạy công cụ mysqlslap:
Mô hình trƣớc, các câu lệnh SELECT chỉ đƣợc gửi đến một máy chủ slave. Còn
trong mô hình này, các câu lệnh SELECT đƣợc MySQL Proxy gửi đều về hai slave theo
thuật toán round-robin:
sending to backend : 10.10.17.5:3306
is_slave : true
và
sending to backend : 10.10.17.100:3306
is_slave : true
Giai đoạn 2:
[read_query] 10.10.17.40:38844
current backend = 0
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.5:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:38850
current backend = 0
71
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.100:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[read_query] 10.10.17.40:38864
current backend = 0
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.5:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
[disconnect_client] 10.10.17.40:38745
[read_query] 10.10.17.40:38856
current backend = 0
72
client default db = mysqlslap
client username = root
query = SELECT intcol1,charcol1 FROM t1
sending to backend : 10.10.17.100:3306
is_slave : true
server default db: mysqlslap
server username : root
in_trans : false
in_calc_found : false
COM_QUERY : true
b) Kết quả thời gian trả về từ công cụ mysqlslap
Kết quả thực nghiệm thời gian chạy các truy vấn trong mô hình này nhƣ bảng sau:
Bảng 4: Kết quả thời gian chạy các truy vấn trong mô hình MySQL Proxy-master-multi
slave
--number-of-queries --concurrency Average number of seconds to run queries
100 100 2.550
600 600 9.170
1500 700 9.256
2000 800 9.983
c) Hiệu năng của máy chủ master
73
Hình 211: Hiệu năng CPU của master
Hình 222: Hiệu năng về Processes
74
Hình 233: Hiệu năng trung bình tải
4.4. NHẬN XÉT
Dựa vào kết quả thực nghiệm trong ba mô hình trên, rút ra nhận xét là:
4.4.1. Khả năng chịu tải của server
Khi số client tăng lên thì thời gian trả chạy các truy vấn cũng tăng lên.
Trong mô hình chỉ có một MySQL server, thì thời gian chạy các truy vấn tăng lên
rất nhiều. Khi số client kết nối đến là 800 client thì máy chủ bị quá tải.
Trong hai mô hình mà có mặt của MySQL Proxy, khi client tăng lên thì thời gian
chạy các truy vấn tăng lên là không đáng kể. Thời gian này càng giảm khi có thêm slave
– mô hình MySQL Proxy – master – multi slave. Hơn nữa, hai mô hình này có thể đáp
ứng đƣợc số lƣợng client truy suất đến là rất lớn.
Nhƣ vậy, MySQL Proxy kết hợp với giải pháp replication đã giải quyết rất tốt bài
toán cân bằng tải các truy vấn đọc cho hệ quản trị CSDL MySQL.
4.4.2. Khả năng mở rộng
Không chỉ có khả năng cân bằng tải các truy vấn đọc cho hệ quản trị CSDL
MySQL, khi quy mô của hệ thống đƣợc mở rộng, số client tăng lên thì có thể thêm slave
vào mô hình, giống nhƣ mô hình MySQL Proxy – master – multi slave hoặc sử dụng giải
pháp “relay slave replication” kết hợp với MySQL Proxy để đáp ứng tốt hơn nhu cầu của
75
client. Khi thêm slave vào mô hình, việc cấu hình replication là rất đơn giản, không mất
nhiều thời gian và không ảnh hƣởng đến hệ thống (Xem phần cấu hình trong phần 4.2.2.).
Đặc biệt, để MySQL Proxy biết đƣợc sự có mặt của một server mới thêm vào thì chỉ cần
thêm một dòng lệnh trong cấu hình của MySQL Proxy:
--proxy-read-only-backend-addresses = host:port
4.4.3. Tính sẵn sàng cao
Khi master bị lỗi không thể tiếp tục hoạt động hoặc master đƣợc bảo trì và nâng cấp
thì một slave có thể đảm nhiệm vai trò của master trong thời gian master vắng mặt. Để
làm đƣợc điều này, thì đơn giản chỉ cần thay đổi trong câu lệnh của MySQL Proxy:
Cấu hình cũ khi master vẫn hoạt động:
--proxy-backend-addresses = master-host:port
--proxy-read-only-backend-addresses = slave1-host:port
--proxy-read-only-backend-addresses = slave2-host:port
Khi master ngừng hoạt động, giả sử dùng slave1 để thay thế vị trí của master:
--proxy-backend-addresses = slave1-host:port
--proxy-read-only-backend-addresses = slave2-host:port
Sau khi master đƣợc phục hồi, thì dựa vào file Binary log của slave1, master có thể
biết đƣợc sự thay đổi đã diễn ra trong cơ sở dữ liệu của mình, từ đó, nó đồng bộ dữ liệu
với slave1 mà đã thay thế nó. Lúc này cấu hình trong MySQL Proxy lại quay về nhƣ cũ.
Do vậy, các server của hệ thống luôn sẵn sàng hoạt động, luôn sẵn sàng đáp ứng
đƣợc tất cả các truy vấn của client, không xảy ra một sự chậm chễ nào.
76
KẾT LUẬN
Khóa luận đã tập trung nghiên cứu bài toán cân bằng tải cho hệ quản trị CSDL
MySQL với MySQL Proxy trong hai mô hình: mô hình MySQL Proxy – master – slave
và mô hình MySQL Proxy – master – multi slave.
Về mặt nội dung, khóa luận đã đạt đƣợc những kết quả sau:
Tìm hiểu và phân tích các bài toán cân bằng tải cho các hệ quản trị CSDL
MySQL, PostgreSQL, Oracle và SQL.
Tìm hiểu về các tiêu chí đánh giá tải và hiệu năng của máy chủ.
Tìm hiểu về giải pháp replication trong hệ quản trị CSDL MySQL, tìm hiểu về
MySQL Proxy, các giải thuật trong bài toán cân bằng tải, nguyên lý hoạt động
MySQL Proxy nhờ ngôn ngữ kịch bản Lua. Từ đó, lựa chọn hai mô hình
MySQL Proxy – master – slave và MySQL Proxy – master – multi slave để giải
quyết bài toán cân bằng tải các truy vấn đọc, đánh giá tải và hiệu năng của
MySQL server trong mỗi mô hình.
Do hạn chế về mặt thời gian, kiến thức, số lƣợng và cấu hình của máy tính để thực
nghiệm nên khóa luận vẫn còn những điểm hạn chế sau:
Chỉ dừng lại ở bài toán cân bằng tải các truy vấn đọc cho hệ quản trị CSDL
MySQL.
Chƣa thử nghiệm đƣợc với số lƣợng client truy cập lớn và số lƣợng các MySQL
server chƣa đủ lớn.
Giải pháp cân bằng tải cho hệ quản trị CSDL MySQL sử dụng MySQL Proxy bƣớc
đầu đã có những kết quả tốt, khả quan. Trong thời gian tới, tôi sẽ nghiên cứu và phát triển
bài toán cân bằng tải theo những hƣớng sau:
Cân bằng tải các truy vấn ghi dựa vào phƣơng pháp Sharding cơ sở dữ liệu
MySQL với MySQL Proxy.
Thử nghiệm trên nhiều MySQL server để đánh giá chính xác tải và hiệu năng
của các server.
Tạo caeching cho MySQL Proxy để đạt hiệu suất tốt hơn
77
TÀI LIỆU THAM KHẢO
Tiếng Việt
[1] Võ Duy Pho, Cân bằng tải cho các hệ Webserver lớn và đảm bảo Scalability,
Khóa luận tốt nghiệp, Đại học Bách Khoa Hà Nội, 2006
[2] Đinh Thị Thu Dung, Nghiên cứu, xây dựng và phòng chống Botnet, Khóa luận
tốt nghiệp, Đại học Công nghệ - Đại học Quốc gia Hà Nội, 2012
[3] Đỗ Thanh An, Tìm hiểu MySQL Cluster và ứng dụng, Khóa luận tốt nghiệp, Đại
học Công nghệ - Đại học Quốc gia Hà Nội, 2012
[4] Đinh Mạnh Tƣờng, Cấu trúc dữ liệu và giải thuật, Khoa Công nghệ Thông tin,
Đại học Công nghệ - Đại học Quốc gia Hà Nội, tr. 246-247
Tiếng Anh
[5] Gregory Smith, PostgreSQL 9.0 High Performance, 2010, pp. 370-393
[6] Sheeri Cabral, Keith Murphy, MySQL Administrator‟s Bible, Wiley Publishing,
Inc., Indianapolis, Indiana, 2009, pp.
[7] Charles Bell, Mats Kindahl, and Lars Thalmann, MySQL High Availability,
2010, O‟Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472, pp. 12-16
Trang web
[8] http://en.wikipedia.org/wiki/Web_server
[9] http://www.thanhnien.com.vn/pages/20111231/google-va-facebook-duoc-truy-
cap-nhieu-nhat-nam-2011.aspx
[9] http://www.mysql.com/why-mysql/
[11] http://www.postgresql.org/about/
[12] http://pgcluster.projects.postgresql.org/feature.html
[13] http://bucardo.org/wiki/Bucardo
[14] http://ossipedia.ipa.go.jp/capacity/EV0612230251/
[15] http://www.pgpool.net/docs/latest/doc/pgpool-en.html
http://www.thanhnien.com.vn/pages/20111231/google-va-facebook-duoc-truy-cap-nhieu-nhat-nam-2011.aspx
78
[16] http://www.oracle.com
[17] http://networksandservers.blogspot.com/2011/03/load-balancing-ii.html
[18] http://everac99.wordpress.com/2008/03/31/the-oracle-rac-what-is-it-an-how-
does-it-work/
[19] http://msdn.microsoft.com/en-us/library/ms152746.aspx
[20] http://msdn.microsoft.com/en-us/library/ms151176.aspx
[21] http://msdn.microsoft.com/en-us/library/ms187103.aspx
[22] http://msdn.microsoft.com/en-us/library/ms189852.aspx
[23] http://technet.microsoft.com/en-us/library/bb742455.aspx
[24] http://quantrimaychu.com/showthread.php?t=3355
[25] http://dev.mysql.com/doc/refman/5.5/en/mysql-proxy.html
[26] http://lieuclub.forumvi.com/t119-topic
[27] http://dev.mysql.com/doc/refman/5.5/en/mysqlslap.html
![[MC-CSDL]: Conceptual Schema Definition File FormatMC-CSDL]-140515.… · [MC-CSDL]: Conceptual Schema Definition File Format Intellectual Property Rights Notice for Open Specifications](https://static.fdocuments.net/doc/165x107/5f610a51a891c260525fe103/mc-csdl-conceptual-schema-definition-file-format-mc-csdl-140515-mc-csdl.jpg)
![Giaotrinh csdl[bookbooming.com]](https://static.fdocuments.net/doc/165x107/55985b9d1a28ab5a768b46f5/giaotrinh-csdlbookboomingcom.jpg)
