Npm mysql đồng bộ

Nối chuỗi bài MySQL Toàn tập, lần này Cloudcraft giới thiệu bài hướng dẫn cấu hình MySQL Replication Master-Master sử dụng GTID. Mô hình Master-Master này cho phép bạn Viết/Đọc đồng thời trên cả hai nút chứ không chỉ một nút Viết/Đọc và một nút Chỉ đọc như Master-Slave. Đây là một biến thể tuy không chính thống (rủ ro rất lớn cho tính nhất quán của dữ liệu) nhưng lại rất phổ biến của MySQL Replication

Tl;DR

• Cách làm tương tự như Replication Master-Slave nhưng mỗi Node đóng cả 2 vai trò cùng lúc
• Có thể sử dụng Binlog hoặc GTID
• Vẫn chỉ là MySQL không đồng bộ, không phải là MySQL đồng bộ như NDB Cluster hay Galera Cluster
• Lợi điểm. tăng một phần khả năng HA cho hệ thống và giảm thiểu số lượng tác vụ khi chuyển đổi dự phòng
• Un mode. luôn phải luôn đảm bảo (ở máy khách) cùng một thời điểm chỉ ghi vào một nút. Nếu không thể chắc chắn việc này, hãy cân nhắc sử dụng giải pháp khác
• Thường phải đi kèm một giải pháp Cơ sở dữ liệu Proxy nào đó. Keepalived + LVS/Haproxy, ProxySQL, MaxScale,…

Lending

Ý tưởng của mô hình này cũng khá đơn giản, thay vì mỗi nút MySQL chỉ đóng 1 vai trò Master hoặc Slave, thì ta có thể để mỗi nút đóng cả 2 vai trò cùng lúc. Một nút vừa là Master vừa là Slave của nút khác. Bạn có thể để một nút đang hoạt động, nút còn sao lưu. Khi xảy ra sự cố, chỉ việc trỏ lại Ứng dụng về nút Sao lưu, không cần phải tương tác với MySQL để thăng cấp từ Slave Read-only thành Master như cách làm Master-Slave bình thường. Khi kết hợp với Keepalived + LVS/Haproxy, việc chuyển đổi dự phòng hoàn toàn có thể tự động (tự động chứ không chắc chắn là minh bạch 😀 )

Tuy nhiên, mô hình này vẫn chỉ là MySQL không đồng bộ và không có cơ chế đảm bảo dữ liệu đã được đồng bộ hóa. Viết thành công cũng như có phát sinh confict trên tất cả các nút còn lại hoặc không. Làm như vậy, mô hình này chỉ nên áp dụng ở mô hệ thống quy mô nhỏ cho phù hợp. Nếu có thể đáp ứng yêu cầu cấu hình tối thiểu của các giải pháp MySQL Đồng bộ như Galera Cluster, NDB Cluster,… bạn nên sử dụng các giải pháp này để mở rộng phần Viết cũng như HA cho hệ thống

Do bài viết trước Cloudcraft đã giới thiệu Binlog, bài viết này sẽ theo cách GTID. Với Binlog, bạn cần quan tâm File Log & Position cho phù hợp. GTID ra đời nhằm giảm thiểu độ phức tạp ở đây. GTID viết tắt của Global Transaction ID. Với mỗi sự thay đổi trong 1 node MySQL sẽ phát sinh một ID. ID được đánh mã theo format :. Việc quyết định một change có cần được apply hay không, cần phải apply change nào tiếp theo sẽ dựa trên GTID. Bạn có thể tham khảo thêm ý tưởng về GTID tại link.

Hình minh họa trong bài viết này là mô hình 2 nút, bạn hoàn toàn có thể mở rộng lên các nút 3,4,5,…. Tuy nhiên, như đã đề cập, nếu câu trả lời là tài nguyên dư thừa, bạn nên chuyển đổi thành dạng MySQL Đồng bộ

Bước 1. bật GTID trên cả hai nút

Thêm vào /etc/my. cnf

gtid_mode=on
binlog_format = MIXED
enforce_gtid_consistency = ON
gtid_mode = ON
log_slave_updates = ON
relay_log_info_repository = TABLE
relay_log_recovery = 1
relay_log_purge = 1

Khởi động lại mysql và kiểm tra lại biến gtid_mode

systemctl restart mysql

mysql -e 'show global variables like "gtid_mode"'
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+

Bước 2. Sao lưu dữ liệu và khôi phục trên các nút

Để cấu hình sao chép từ nút này (nguồn) sang nút kia (đích), lần sao lưu dữ liệu từ nút này (nguồn) và khôi phục sang nút kia (đích)

To backup all data (source), you could use mysqldump

________số 8_______

các tùy chọn nâng cao hơn các giới hạn. chỉ sao lưu một số cơ sở dữ liệu nhất định (–database), sao lưu nhưng không kèm theo các trình kích hoạt, thủ tục lưu trữ,… bạn tham khảo tại link. Ngoài ra, bạn có thể sử dụng các công cụ khác như Xtrabackup

Sau đó, sao chép tệp kết xuất sang và khôi phục ra trên nút còn lại (đích)

scp source-ip:/backup.sql ./
mysql -e "reset master"
mysql < backup.sql

Bước 3. Cấu hình GTID Replication

Các lần lượt trên các nút, cấu hình như sau

mysql> change master to master_host="IP/Hostname",


> master_port=3306,


> master_user="Replication_User",


> master_password="password",


systemctl restart mysql

systemctl restart mysql

systemctl restart mysql

• IP/Tên máy chủ. IP/Hostname của nút làm nguồn. Lưu ý nếu dùng tên máy chủ thì không nên cấu hình bỏ qua-tên-giải quyết và bỏ qua-máy chủ lưu trữ trong /etc/my. cnf
• người dùng sao chép. người dùng chỉ có quyền Replication Slave trên nguồn nút. Đây là một phương pháp hay nhất về bảo mật, bạn có thể bỏ qua nếu muốn
• Master_auto_postion=1. cấu hình sao chép bằng GTID. Một ưu điểm của GTID là bạn không cần phải ghi nhận tệp Binlog và vị trí nhật ký trên nguồn

Check back by command

mysql -e "show slave status\G" | grep Running

Nếu cả Slave_IO_Running và Slave_SQL_Running đều là CÓ, thì chúc mừng bạn đã cấu hình thành công, nếu không, hãy kiểm tra Nhật ký MySQL để biết thêm chi tiết lỗi

lặp lại Bước 3 trên tất cả các nút

Sau khi cấu hình xong, bạn có thể thử Create Database, Create User, Create Table, Insert data,… để kiểm tra quá trình đồng bộ

Như vậy, ta đã gạch đầu dòng đầu tiên “Bản sao MySQL hai chiều” trong hình minh họa ở đầu bài viết. Ở bài viết sau, Cloudcraft sẽ mở rộng HA bằng cách kết hợp Keepalived