[MariaDB Replication] Các Test Case cho MariaDB Master-Slave

30/12/2020

Replication MariaDB là một quá trình cho phép dữ liệu từ một máy chủ cơ sở dữ liệu MariaDB (master) được sao chép tự động sang một hoặc nhiều máy chủ cơ sở dữ liệu MariaDB (slaves).

Mục lục

  1. Giới thiệu
  2. Node Failed
  3. Promoting a Slave to Master
  4. Backup/Restore khi hệ thống Master Slave gặp sự cố

1. Giới thiệu

Với cơ sở dữ liệu, nhu cầu lưu trữ lớn, đòi hỏi cơ sở dữ liệu toàn vẹn, trường hợp gặp những sự cố ngoài dự đoán là rất cao sẽ làm mất mát dữ liệu. Vậy một số sự cố thường gặp và cách khắc phục nó ra sao?

Trong bài viết dưới đây mình sẽ trình bày một số sự cố đó và cách khắc phục trong quá trình vận hành MariaDB Master-Slave.

2. Node Failed

2.1. Master Failed

Mô tả

Test với trường hợp tắt node master, sau vài phút bật lại.

Insert và update một số bản ghi và kiểm tra sự đồng bộ giữa 2 nodes.

Quy trình thực hiện

Tạo một Table mới trong database Replica_db tên Test1 , insert vài bản ghi đơn giản , Slave đồng bộ bình thường.

> create table Test1 (id int primary key, name varchar(20));

Tắt node master, trên Slave show slave status thì thấy lỗi không kết nối được đến Node Master

Sau 5 phút, khởi động lại Node Server. Insert và update 1000 bản ghi vào table Test trong database Replica_db.

Kết quả

Dữ liệu trên Master và Slave đồng bộ với nhau và không bị thất thoát dữ liệu.

2.2. Slave Failed

Mô tả

Test với trường hợp tắt node Slave, sau vài giây bật lại.

Insert và update một số bản ghi và kiểm tra sự đồng bộ giữa 2 nodes khi service MariaDB bất ngờ bị stop trong quá trình insert dữ liệu.

Quy trình thực hiện

Tạo table Test trong database Replica_db

> create table Test (id int primary key, name varchar(20));

Tạo Script đơn giản để insert 2000 bản ghi vào Node Master và thực thi:

for i in {1..2000}; do mysql -uroot -ppass -e "use replica_db; INSERT INTO Test (id, name) VALUES ($i, 'test');" done

Trong quá trình chạy, đột ngột tắt Node Slave.

Bật lại Node Slave.

Kết quả

Slave database tiếp tục pull dữ liệu từ master về tính từ thời điểm Slave gặp sự cố.

3. Promoting a Slave to Master

Mô tả

Giả lập Master bị hỏng

Chuyển node slave thành node master tạm thời

Sau khi dựng lại node master cũ, đưa node master cũ trở về master, node master tạm thời trở lại về node slave

Quy trình thực hiện

Master hỏng và không thể khôi phục hoạt động.

Chuyển Node Slave thành Node Master bằng cách :

  • Vào file /etc/my.cnf bỏ dòng read-only=1
  • Đăng nhập vào Slave Database và xóa cấu hình slave cũ bằng câu lệnh :
> stop slave; > reset slave all; #systemctl restart mariadb
  • Trỏ app về địa chỉ IP của Master tạm thời đó.

Hệ thống tiếp tục hoạt động bình thường

Khi Master cũ đã sẵn sàng hoạt động, trả lại Role Master cho Server đó bằng cách :

  • Vào Master tạm thời, dump lại database đồng bộ để đảm bảo không mất mát dữ liệu ra file backup.sql
  • Import backup.sql vào Master cũ và lấy các thông số về Master_log_file và master_log_pos
  • Master tạm thời lại chuyển thành slave bằng việc set read-only trong file /etc/my.cnf và chạy các câu lệnh:
> change master to master_host='10.10.22.xxx',  master_user='slave',  master_password='XXXXXXX',  master_port=3306,  master_log_file='master.00000x',  master_log_pos=xxx,  master_connect_retry=10;  > start slave;

Sau khi xong, kiểm tra lại trên slave Database bằng câu lệnh

show slave statusG;

Thử insert vài bản ghi trên Master để kiểm tra.

Kết quả

Hệ thống vẫn hoạt động cho khi Node Slave chuyển sang Master. Việc thay đổi Role này khá đơn giản và nhanh, đáp ứng được yêu cầu đề ra về tính sẵn sàng và đảm bảo dữ liệu.

4. Backup/Restore khi hệ thống Master Slave gặp sự cố

Mô tả

Khi master gặp sự cố mất mát dữ liệu (record, Table, Schema v.v..) dẫn đến việc Slave cũng đồng bộ theo và khiến cho dữ liệu hệ thống mất đi.

Sử dụng bản backup gần nhất để khôi phục dữ liệu trên Master và kiểm tra xem Slave có đồng bộ lại không hay sẽ phải import lại CSDL trên Slave như khi mới khởi tạo Master-Slave

Quy trình thực hiện

Sử dụng câu lệnh sau để backup dữ liệu

mysqldump -u root -p [dbname] > [backupfile.sql]

Trong đó :

  • [dbname] : Tên của database
  • [backupfile.sql] : Tên file backup muốn lưu

Sử dụng câu lệnh sau để restore dữ liệu

mysql -u root -p [dbname] < [backupfile.sql]

Sử dụng các binary logs để tiếp tục restore Incremental (cần phải xem binary log file để xem thời điểm chính xác).

mysqlbinlog master-bin.000001 master-bin.000002 master-bin.000003 | mysql -uroot -p$pass

Kết quả

2 table usergroup và usergrouprole đã được khôi phục.

Dữ liệu của Database đã được phục hồi đến thời điểm trước khi bị mất dữ liệu.

Chúc mọi người thành công !

Tài liệu liên quan

ONET IDC thành lập vào năm 2012, là công ty chuyên nghiệp tại Việt Nam trong lĩnh vực cung cấp dịch vụ Hosting, VPS, máy chủ vật lý, dịch vụ Firewall Anti DDoS, SSL… Với 10 năm xây dựng và phát triển, ứng dụng nhiều công nghệ hiện đại, ONET IDC đã giúp hàng ngàn khách hàng tin tưởng lựa chọn, mang lại sự ổn định tuyệt đối cho website của khách hàng để thúc đẩy việc kinh doanh đạt được hiệu quả và thành công.
Bài viết liên quan

[ KVM ] Tổng quan về Virtualization và Hypervisor

Virtualization là gì? Virtualization, hay còn gọi là ảo hóa, là một công nghệ được thiết kế để...
30/12/2020

Cài đặt Chrony trên Ubuntu 18.04

Ở bài trước chúng ta đã biết được Chrony là một dịch vụ đồng bộ thời gian trên nhiều hệ...
30/12/2020

[CEPH] [LAB] [Phần2] Hướng dẫn sử dụng block storage của CEPH

Block stoarge sẽ dùng như thế nào nhỉ? Trong phần 1, Onet đã hướng dẫn bạn triển khai cluser ceph...
30/12/2020
Bài Viết

Bài Viết Mới Cập Nhật

Mua proxy v4 chạy socks5 để chơi game an toàn, tốc độ cao ở đâu?
18/05/2024

Thuê mua proxy Telegram trọn gói, tốc độ cao, giá siêu hời
18/05/2024

Thuê mua proxy Viettel ở đâu uy tín, chất lượng và giá tốt? 
14/05/2024

Dịch vụ thuê mua proxy US UK uy tín, chất lượng số #1
13/05/2024

Thuê mua proxy Việt Nam: Báo giá & các thông tin MỚI NHẤT
13/05/2024