中文 (中国)
English
DataOnline sẽ hướng dẫn bạn triển khai MariaDB trên hệ thống Ubuntu và áp dụng các phương pháp bảo mật quan trọng bằng cách sử dụng script mysql_secure_installation. Bên cạnh đó, bạn cũng có thể thiết lập một tài khoản quản trị mới với cơ chế xác thực mật khẩu an toàn, giúp tăng cường bảo vệ hệ thống. Với những bước cấu hình này, máy chủ MariaDB của bạn sẽ hoạt động ổn định, bảo mật cao hơn và sẵn sàng xử lý các tác vụ quản lý cơ sở dữ liệu một cách hiệu quả.
Hướng dẫn này mô tả cách cấu hình một instance MySQL trên một máy chủ làm cơ sở dữ liệu nguồn (source) và sau đó cấu hình một instance MySQL trên máy chủ khác để hoạt động như bản sao (replica). Ngoài ra, tài liệu cũng đưa ra cái nhìn tổng quan về cách MySQL xử lý replication.
Lưu ý: Trước đây, kiểu replication này được gọi là “master-slave” replication. Trong một bài đăng blog xuất bản vào tháng 7 năm 2020, nhóm MySQL đã thừa nhận nguồn gốc tiêu cực của thuật ngữ này và công bố nỗ lực cập nhật chương trình và tài liệu của họ nhằm sử dụng ngôn ngữ bao dung hơn.
Quá trình này vẫn đang được thực hiện. Mặc dù tài liệu của MySQL và nhiều lệnh trong phiên bản 8 của chương trình đã được cập nhật để thay thế việc gọi các máy chủ trong topology replication là source và replica, vẫn có những nơi mà thuật ngữ cũ xuất hiện không tránh khỏi. Hướng dẫn này sẽ ưu tiên sử dụng thuật ngữ source-replica bao dung ở những chỗ có thể, nhưng cũng có một vài trường hợp không tránh khỏi sử dụng thuật ngữ cũ.
Yêu Cầu
Để hoàn thành hướng dẫn này, bạn cần:
● Hai máy chủ chạy Ubuntu 20.04. Cả hai máy chủ cần có một người dùng quản trị không phải root với quyền sudo và đã được cấu hình Firewall với UFW. Hãy tham khảo hướng dẫn thiết lập máy chủ ban đầu cho Ubuntu 20.04 để cấu hình cho cả hai máy chủ.
● MySQL được cài đặt trên mỗi máy chủ. Hướng dẫn này giả định bạn đang sử dụng phiên bản MySQL mới nhất có sẵn trong kho lưu trữ mặc định của Ubuntu, tính đến thời điểm viết bài này là phiên bản 8.0.25. Để cài đặt trên cả hai máy chủ, hãy theo dõi hướng dẫn Cách cài đặt MySQL trên Ubuntu 20.04.
Hãy lưu ý rằng quy trình mô tả trong hướng dẫn này sẽ chỉ định MySQL cài đặt trên một máy chủ làm cơ sở dữ liệu nguồn, sau đó cấu hình MySQL trên máy chủ kia làm replica của source. Để dễ phân biệt, bất kỳ lệnh nào cần chạy trên máy chủ của cơ sở dữ liệu nguồn sẽ được đánh dấu với nền màu xanh (blue background):
Tương tự, các lệnh cần chạy trên máy chủ của replica sẽ được đánh dấu với nền màu đỏ:
Cuối cùng, hướng dẫn này bao gồm các bước tùy chọn về cách di chuyển dữ liệu trong cơ sở dữ liệu hiện có từ source sang replica. Quy trình này bao gồm tạo một snapshot của cơ sở dữ liệu nguồn và sao chép file kết quả sang replica. Để làm được điều này, chúng tôi khuyến nghị bạn thiết lập SSH keys trên máy chủ nguồn và sau đó đảm bảo rằng public key của nguồn đã được sao chép sang máy chủ replica.
Hiểu về Replication trong MySQL
Trong MySQL, replication bao gồm việc cơ sở dữ liệu nguồn ghi lại mọi thay đổi được thực hiện trên dữ liệu của một hoặc nhiều cơ sở dữ liệu vào một file đặc biệt gọi là binary log. Khi instance replica được khởi tạo, nó tạo ra hai tiến trình (thread). Tiến trình đầu tiên, được gọi là IO thread, kết nối với instance MySQL nguồn và đọc các sự kiện trong binary log theo thứ tự, sau đó sao chép chúng vào một file cục bộ trên máy chủ replica gọi là relay log. Tiến trình thứ hai, gọi là SQL thread, đọc các sự kiện từ relay log và áp dụng chúng lên instance replica càng nhanh càng tốt.
Các phiên bản MySQL gần đây hỗ trợ hai phương thức để replication dữ liệu. Sự khác biệt giữa các phương thức này liên quan đến cách replica theo dõi các sự kiện cơ sở dữ liệu từ nguồn mà nó đã xử lý.
MySQL gọi phương thức replication truyền thống của nó là replication dựa trên vị trí file binary log (binary log file position-based replication). Khi bạn chuyển một instance MySQL thành replica theo phương thức này, bạn phải cung cấp cho nó một bộ tọa độ binary log. Bộ tọa độ này bao gồm tên của file binary log trên nguồn mà replica cần đọc và một vị trí cụ thể trong file đó đại diện cho sự kiện cơ sở dữ liệu đầu tiên mà replica nên sao chép vào instance MySQL của nó.
Những tọa độ này rất quan trọng vì replica sẽ nhận bản sao toàn bộ binary log của source và, nếu không có tọa độ chính xác, nó sẽ bắt đầu sao chép mọi sự kiện cơ sở dữ liệu được ghi nhận trong file. Điều này có thể dẫn đến các vấn đề nếu bạn chỉ muốn sao chép dữ liệu sau một thời điểm nhất định hoặc chỉ sao chép một phần dữ liệu của nguồn.
Replication dựa trên vị trí file binary log phù hợp với nhiều trường hợp sử dụng, nhưng phương pháp này có thể trở nên cồng kềnh trong các thiết lập phức tạp hơn. Điều này đã dẫn đến sự phát triển của phương pháp replication gốc mới của MySQL, đôi khi được gọi là replication dựa trên giao dịch (transaction-based replication). Phương pháp này liên quan đến việc tạo ra một Global Transaction Identifier (GTID) cho mỗi giao dịch – tức là, một phần công việc độc lập được thực hiện bởi cơ sở dữ liệu – mà instance MySQL nguồn thực hiện.
Cơ chế của replication dựa trên giao dịch tương tự như replication dựa trên file binary log: mỗi khi có giao dịch xảy ra trên nguồn, MySQL gán và ghi lại một GTID cho giao dịch đó trong binary log cùng với giao dịch. Sau đó, GTID và giao dịch được truyền tới các replica của nguồn để xử lý.
Replication dựa trên giao dịch của MySQL có nhiều ưu điểm so với phương pháp truyền thống. Ví dụ, vì cả source và các replica đều lưu giữ GTIDs, nếu source hoặc replica gặp phải giao dịch với GTID đã được xử lý trước đó, chúng sẽ bỏ qua giao dịch đó. Điều này giúp đảm bảo tính nhất quán giữa source và các replica. Ngoài ra, với replication dựa trên giao dịch, các replica không cần phải biết tọa độ binary log của sự kiện tiếp theo cần xử lý. Điều này có nghĩa là việc khởi tạo các replica mới hoặc thay đổi thứ tự của các replica trong chuỗi replication trở nên đơn giản hơn nhiều.
Hãy nhớ rằng đây chỉ là giải thích tổng quát về cách MySQL xử lý replication; MySQL cung cấp rất nhiều tùy chọn mà bạn có thể điều chỉnh để tối ưu hoá thiết lập replication của riêng mình. Hướng dẫn này mô tả cách thiết lập replication dựa trên vị trí file binary log. Nếu bạn quan tâm đến việc cấu hình môi trường replication khác, hãy tham khảo tài liệu chính thức của MySQL.
Bước 1 – Điều chỉnh Firewall của máy chủ nguồn
Giả sử bạn đã thực hiện theo Hướng Dẫn Thiết Lập Máy Chủ Ban Đầu, bạn sẽ đã cấu hình Firewall trên cả hai máy chủ với UFW. Điều này giúp bảo vệ an toàn cho cả hai máy chủ, nhưng Firewall của máy chủ nguồn sẽ chặn mọi nỗ lực kết nối từ instance MySQL replica.
Để thay đổi điều này, bạn cần thêm một quy tắc UFW cho phép kết nối từ replica thông qua Firewall của nguồn. Bạn có thể làm điều này bằng cách chạy lệnh sau trên máy chủ nguồn
Lệnh này cho phép bất kỳ kết nối nào xuất phát từ địa chỉ IP của máy chủ replica – được biểu thị bởi replica_server_ip – đến cổng mặc định của MySQL, 3306:
sudo ufw allow from replica_server_ip to any port 3306
Lưu ý: Hãy thay thế replica_server_ip bằng địa chỉ IP thực của máy chủ replica. Nếu quy tắc được thêm thành công, bạn sẽ thấy thông báo sau:
Output Rule added
Sau đó, bạn không cần thay đổi quy tắc Firewall trên máy chủ replica, vì máy chủ replica không nhận kết nối đến và các kết nối đi ra tới máy chủ MySQL nguồn không bị UFW chặn. Bạn có thể chuyển sang cập nhật cấu hình của instance MySQL nguồn để bật replication.
Bước 2 – Cấu hình cơ sở dữ liệu nguồn
Để cơ sở dữ liệu MySQL nguồn bắt đầu sao chép dữ liệu, bạn cần thay đổi một số thiết lập trong cấu hình của nó.
Trên Ubuntu 20.04, file cấu hình mặc định của MySQL là mysqld.cnf và được tìm thấy trong thư mục /etc/mysql/mysql.conf.d/. Mở file này trên máy chủ nguồn bằng trình soạn thảo văn bản mà bạn ưa thích. Ở đây, chúng ta sử dụng nano:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Trong file, tìm directive bind-address. Theo mặc định, nó sẽ trông như sau:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . bind-address = 127.0.0.1 . . .
Địa chỉ 127.0.0.1 là địa chỉ loopback IPv4 đại diện cho localhost, và việc thiết lập giá trị này cho directive bind-address chỉ định MySQL chỉ lắng nghe các kết nối đến từ chính máy chủ cài đặt nó.
Nhớ rằng bạn đang chuyển instance MySQL trên máy chủ khác thành replica của instance này, vì vậy replica phải có thể đọc được bất kỳ dữ liệu mới nào được ghi vào nguồn. Để cho phép điều này, bạn phải cấu hình instance MySQL nguồn để lắng nghe trên một địa chỉ IP mà replica có thể truy cập, ví dụ như địa chỉ IP công cộng của máy chủ nguồn.
Thay thế 127.0.0.1 bằng địa chỉ IP của máy chủ nguồn. Sau khi thay đổi, directive bind-address sẽ trông như sau (với địa chỉ IP của máy chủ nguồn thay cho source_server_ip):
/etc/mysql/mysql.conf.d/mysqld.cnf . . . bind-address = source_server_ip . . .
Tiếp theo, tìm directive server-id, định nghĩa một định danh mà MySQL sử dụng nội bộ để phân biệt các máy chủ trong thiết lập replication. Mỗi máy chủ trong môi trường replication, bao gồm cả nguồn và các replica, phải có một giá trị server-id duy nhất. Theo mặc định, directive này sẽ bị comment và trông như sau:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . # server-id = 1 . . .
Bỏ dấu thăng (#) để kích hoạt dòng này. Bạn có thể chọn bất kỳ số nào làm giá trị cho directive này, nhưng nhớ rằng số đó phải là duy nhất và không trùng với bất kỳ server-id nào khác trong nhóm replication của bạn. Để đơn giản, ví dụ dưới đây giữ giá trị mặc định là 1:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . server-id = 1 . . .
Bên dưới dòng server-id, tìm directive log_bin. Directive này định nghĩa tên cơ sở và vị trí của file binary log của MySQL.
Khi bị comment, như mặc định, binary logging bị vô hiệu hoá. Máy chủ replica phải đọc file binary log của nguồn để biết khi nào và cách thức sao chép dữ liệu, vì vậy hãy bỏ comment dòng này để bật binary logging trên máy chủ nguồn. Sau khi thay đổi, nó sẽ trông như sau:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . log_bin = /var/log/mysql/mysql-bin.log . . .
Cuối cùng, cuộn xuống dưới cùng của file để tìm directive binlog_do_db bị comment:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . # binlog_do_db = include_database_name
Bỏ dấu thăng để bỏ comment dòng này và thay include_database_name bằng tên của cơ sở dữ liệu bạn muốn sao chép. Ví dụ dưới đây hiển thị directive binlog_do_db trỏ tới cơ sở dữ liệu có tên db; nếu bạn có một cơ sở dữ liệu hiện có trên nguồn mà bạn muốn sao chép, hãy sử dụng tên của nó thay cho db:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . binlog_do_db = db
Lưu ý: Nếu bạn muốn sao chép nhiều hơn một cơ sở dữ liệu, bạn có thể thêm một directive
binlog_do_dbcho mỗi cơ sở dữ liệu. Ví dụ:/etc/mysql/mysql.conf.d/mysqld.cnf . . . binlog_do_db = db binlog_do_db = db_1 binlog_do_db = db_2Ngoài ra, bạn có thể chỉ định các cơ sở dữ liệu mà MySQL không nên sao chép bằng cách thêm directive
binlog_ignore_dbcho mỗi cơ sở dữ liệu:/etc/mysql/mysql.conf.d/mysqld.cnf . . . binlog_ignore_db = db_to_ignore
Sau khi thực hiện các thay đổi, hãy lưu và đóng file. Nếu bạn dùng nano, nhấn CTRL + X, sau đó Y và ENTER để lưu.
Tiếp theo, khởi động lại dịch vụ MySQL bằng lệnh:
sudo systemctl restart mysql
Với những thay đổi này, instance MySQL trên máy chủ nguồn đã sẵn sàng hoạt động như cơ sở dữ liệu nguồn để máy chủ MySQL khác có thể sao chép. Trước khi cấu hình replica, bạn cần thực hiện thêm một vài bước trên máy chủ nguồn để đảm bảo topology replication hoạt động đúng. Bước đầu tiên là tạo một người dùng MySQL dành riêng cho các thao tác liên quan đến replication.
Bước 3 – Tạo người dùng Replication
Mỗi replica trong môi trường replication MySQL kết nối tới cơ sở dữ liệu nguồn bằng một tên người dùng và mật khẩu. Replica có thể kết nối bằng bất kỳ tài khoản MySQL nào có sẵn trên nguồn và có đủ quyền, nhưng hướng dẫn này sẽ mô tả cách tạo một người dùng dành riêng cho mục đích này.
Bắt đầu bằng cách mở MySQL shell:
sudo mysql
Lưu ý: Nếu bạn đã cấu hình một người dùng MySQL riêng dùng xác thực bằng mật khẩu, bạn có thể kết nối bằng lệnh như sau:
mysql -u sammy -p
Thay sammy bằng tên người dùng bạn tạo và nhập mật khẩu khi được nhắc.
Hãy lưu ý rằng một số thao tác trong hướng dẫn này, bao gồm những thao tác phải thực hiện trên máy chủ replica, yêu cầu quyền cao cấp. Vì vậy, có thể thuận tiện hơn nếu bạn kết nối với tư cách người dùng quản trị, như dùng lệnh sudo mysql ở trên. Nếu bạn muốn sử dụng một người dùng MySQL có quyền hạn thấp hơn, người dùng đó cần được cấp ít nhất các quyền: CREATE USER, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, và REPLICATION_SLAVE_ADMIN.
Từ MySQL prompt, tạo một người dùng MySQL mới. Ví dụ dưới đây tạo người dùng tên replica_user. Hãy thay replica_server_ip bằng địa chỉ IP công cộng của máy chủ replica và thay password bằng mật khẩu mạnh mà bạn chọn:
CREATE USER 'replica_user'@'replica_server_ip' IDENTIFIED WITH mysql_native_password BY 'password';
Lưu ý rằng lệnh này chỉ định replica_user sử dụng plugin xác thực mysql_native_password. Bạn cũng có thể sử dụng cơ chế xác thực mặc định của MySQL là caching_sha2_password, nhưng điều này đòi hỏi phải thiết lập kết nối mã hoá giữa nguồn và replica. Thiết lập mã hoá sẽ tối ưu cho môi trường production, nhưng cấu hình kết nối mã hoá vượt quá phạm vi hướng dẫn này. Tài liệu MySQL có hướng dẫn cấu hình môi trường replication sử dụng kết nối mã hoá nếu bạn quan tâm.
Sau khi tạo người dùng mới, cấp cho họ các quyền phù hợp. Tối thiểu, một người dùng replication MySQL phải có quyền REPLICATION SLAVE:
GRANT REPLICATION SLAVE ON *.* TO 'replica_user'@'replica_server_ip';
Tiếp theo, chạy lệnh FLUSH PRIVILEGES để giải phóng bộ nhớ mà server đã cache do các lệnh CREATE USER và GRANT:
FLUSH PRIVILEGES;
Với đó, bạn đã hoàn tất việc thiết lập người dùng replication trên MySQL nguồn. Tuy nhiên, đừng thoát khỏi MySQL shell – hãy giữ nó mở lại vì bạn sẽ sử dụng nó trong bước tiếp theo để lấy thông tin quan trọng về file binary log của nguồn.
Bước 4 – Lấy tọa độ File Binary Log từ nguồn
Nhớ lại phần Hiểu Về Replication Trong MySQL, MySQL thực hiện replication bằng cách sao chép các sự kiện cơ sở dữ liệu từ file binary log của nguồn theo từng dòng và thực hiện từng sự kiện trên replica. Khi sử dụng replication dựa trên vị trí file binary log, bạn phải cung cấp cho replica một bộ tọa độ chi tiết tên file binary log của nguồn và vị trí cụ thể trong file đó. Replica sẽ sử dụng những tọa độ này để xác định điểm bắt đầu sao chép sự kiện và theo dõi những sự kiện đã xử lý.
Bước này hướng dẫn bạn cách lấy tọa độ binary log hiện tại của nguồn để thiết lập replica bắt đầu sao chép dữ liệu từ điểm mới nhất trong file log. Để đảm bảo không có người dùng nào thay đổi dữ liệu trong khi bạn lấy tọa độ (có thể gây ra lỗi), bạn cần khóa cơ sở dữ liệu để ngăn không cho bất kỳ client nào đọc hoặc ghi dữ liệu trong thời gian lấy tọa độ. Bạn sẽ mở khóa sau đó, nhưng quá trình này sẽ gây ra một khoảng thời gian downtime cho cơ sở dữ liệu.
Bạn nên giữ MySQL shell của máy chủ nguồn mở từ bước trước. Từ prompt, chạy lệnh sau để đóng tất cả các bảng mở ở mọi cơ sở dữ liệu trên nguồn và khóa chúng lại:
FLUSH TABLES WITH READ LOCK;
Sau đó, chạy lệnh sau để trả về thông tin trạng thái hiện tại của file binary log của nguồn:
SHOW MASTER STATUS;
Bạn sẽ thấy một bảng kết quả tương tự ví dụ dưới đây:
Output +------------------+----------+--------------+------------------+-------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set | +------------------+----------+--------------+------------------+-------------------+ | mysql-bin.000001 | 899 | db | | | +------------------+----------+--------------+------------------+-------------------+ 1 row in set (0.00 sec)
Đây là vị trí mà replica sẽ bắt đầu sao chép các sự kiện cơ sở dữ liệu. Ghi lại tên file và giá trị Position, vì bạn sẽ cần chúng khi khởi tạo replication.
Hành động bạn thực hiện ngay sau khi có thông tin này phụ thuộc vào việc cơ sở dữ liệu nguồn của bạn có dữ liệu hiện có nào cần di chuyển sang replica hay không. Hãy chuyển sang phần phù hợp với tình huống của bạn.
Nếu nguồn không có dữ liệu hiện có để di chuyển
Nếu instance MySQL nguồn của bạn là cài đặt mới hoặc không có dữ liệu nào cần di chuyển sang replica, bạn có thể mở khóa các bảng ngay lúc này:
UNLOCK TABLES;
Nếu bạn chưa tạo cơ sở dữ liệu cần sao chép, bạn có thể tạo nó ngay trong MySQL shell. Ví dụ, để tạo cơ sở dữ liệu có tên db:
CREATE DATABASE db;
Output Query OK, 1 row affected (0.01 sec)
Sau đó, thoát khỏi MySQL shell:
exit
Bạn có thể chuyển sang bước tiếp theo.
Nếu Nguồn Có Dữ Liệu Hiện Có để Di Chuyển
Nếu trên instance MySQL nguồn có dữ liệu mà bạn muốn di chuyển sang replica, bạn có thể tạo một snapshot của cơ sở dữ liệu bằng tiện ích mysqldump. Tuy nhiên, cơ sở dữ liệu của bạn hiện đang bị khóa. Nếu bạn thực hiện bất kỳ thay đổi nào trong khoảng thời gian này, cơ sở dữ liệu sẽ tự động mở khóa. Tương tự, các bảng cũng sẽ mở khóa nếu bạn thoát khỏi client.
Việc mở khóa các bảng có thể dẫn đến vấn đề vì client có thể thay đổi dữ liệu, dẫn đến sự không khớp giữa snapshot và tọa độ binary log vừa lấy.
Vì lý do này, bạn cần mở một cửa sổ hoặc tab SSH mới trên máy cục bộ để tạo snapshot mà không làm mở khóa MySQL.
Từ cửa sổ/tab mới, mở một phiên SSH tới máy chủ chứa MySQL nguồn:
ssh sammy@source_server_ip
Sau đó, từ cửa sổ/tab mới, xuất cơ sở dữ liệu bằng mysqldump. Ví dụ dưới đây tạo file dump tên db.sql từ cơ sở dữ liệu có tên db – hãy thay thế tên cơ sở dữ liệu của bạn nếu cần. Hãy chắc chắn rằng bạn chạy lệnh này trong bash shell, không phải MySQL shell:
sudo mysqldump -u root db > db.sql
Sau khi tạo snapshot, bạn có thể đóng cửa sổ/tab mới và quay trở lại cửa sổ đầu tiên (vẫn còn mở MySQL shell). Từ MySQL prompt, mở khóa các bảng để cho phép ghi dữ liệu trở lại:
UNLOCK TABLES;
Sau đó, thoát khỏi MySQL shell:
exit
Bạn có thể gửi file snapshot sang máy chủ replica. Giả sử bạn đã cấu hình SSH keys trên máy chủ nguồn và đã thêm public key của nguồn vào file authorized_keys của máy chủ replica, bạn có thể chuyển file một cách an toàn bằng lệnh scp:
scp db.sql sammy@replica_server_ip:/tmp/
Hãy thay sammy bằng tên người dùng quản trị Ubuntu mà bạn đã tạo trên máy chủ replica, và thay replica_server_ip bằng địa chỉ IP của máy chủ replica. Lưu ý lệnh này sẽ đặt file snapshot vào thư mục /tmp/ trên máy chủ replica.
Sau khi gửi file snapshot, SSH vào máy chủ replica:
ssh sammy@replica_server_ip
Sau đó mở MySQL shell:
sudo mysql
Từ MySQL prompt, tạo cơ sở dữ liệu mới mà bạn sẽ sao chép từ nguồn:
CREATE DATABASE db;
Bạn không cần tạo bảng hoặc nạp dữ liệu mẫu, vì tất cả sẽ được thực hiện khi bạn import snapshot vừa tạo. Sau đó, thoát khỏi MySQL shell:
exit
Tiếp theo, import snapshot cơ sở dữ liệu:
sudo mysql db < /tmp/db.sql
Máy chủ replica của bạn bây giờ đã có đầy đủ dữ liệu hiện có từ cơ sở dữ liệu nguồn. Bạn có thể hoàn thành bước cuối cùng để cấu hình máy chủ replica bắt đầu sao chép các thay đổi mới từ nguồn.
Bước 5 – Cấu hình cơ sở dữ liệu Replica
Phần còn lại là thay đổi cấu hình của replica tương tự như cách bạn đã thay đổi của nguồn. Mở file cấu hình MySQL, mysqld.cnf, lần này trên máy chủ replica:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
Như đã đề cập, mỗi instance MySQL trong thiết lập replication phải có giá trị server-id duy nhất. Tìm directive server-id của replica, bỏ comment nó và thay đổi giá trị thành một số nguyên dương khác với giá trị của nguồn. Ví dụ:
/etc/mysql/mysql.conf.d/mysqld.cnf server-id = 2
Tiếp theo, cập nhật các giá trị log_bin và binlog_do_db sao cho khớp với cấu hình trên máy chủ nguồn:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . log_bin = /var/log/mysql/mysql-bin.log . . . binlog_do_db = db . . .
Cuối cùng, thêm directive relay-log định nghĩa vị trí của file relay log trên replica. Thêm dòng sau vào cuối file cấu hình:
/etc/mysql/mysql.conf.d/mysqld.cnf . . . relay-log = /var/log/mysql/mysql-relay-bin.log
Sau khi lưu và đóng file, khởi động lại MySQL trên replica để áp dụng cấu hình mới:
sudo systemctl restart mysql
Sau khi khởi động lại dịch vụ mysql, bạn đã sẵn sàng để bắt đầu sao chép dữ liệu từ cơ sở dữ liệu nguồn.
Bước 6 – Bắt đầu và kiểm tra Replication
Tại thời điểm này, cả hai instance MySQL của bạn đã được cấu hình hoàn toàn để cho phép replication. Để bắt đầu sao chép dữ liệu từ nguồn, mở MySQL shell trên máy chủ replica:
sudo mysql
Từ prompt, chạy lệnh sau để cấu hình một số cài đặt replication cùng một lúc. Sau khi chạy lệnh này, khi bạn kích hoạt replication trên instance này, nó sẽ cố gắng kết nối tới địa chỉ IP sau SOURCE_HOST bằng tên người dùng và mật khẩu được chỉ định ở SOURCE_USER và SOURCE_PASSWORD. Nó cũng sẽ tìm file binary log với tên được chỉ định ở SOURCE_LOG_FILE và bắt đầu đọc từ vị trí sau SOURCE_LOG_POS.
Hãy thay source_server_ip bằng địa chỉ IP của máy chủ nguồn. Tương tự, replica_user và password phải khớp với người dùng replication bạn đã tạo ở bước trước; và mysql-bin.000001 và 899 phải phản ánh tọa độ binary log bạn đã lấy.
Bạn có thể soạn lệnh này trong một trình soạn thảo văn bản trước khi chạy trên máy chủ replica để dễ dàng thay thế thông tin cần thiết:
CHANGE REPLICATION SOURCE TO SOURCE_HOST='source_server_ip', SOURCE_USER='replica_user', SOURCE_PASSWORD='password', SOURCE_LOG_FILE='mysql-bin.000001', SOURCE_LOG_POS=899;
Sau đó, kích hoạt replica:
START REPLICA;
Nếu bạn nhập đúng tất cả thông tin, instance này sẽ bắt đầu sao chép mọi thay đổi được thực hiện trên cơ sở dữ liệu db của nguồn.
Để xem chi tiết trạng thái hiện tại của replica, chạy lệnh sau. Modifier \G sắp xếp lại văn bản cho dễ đọc:
SHOW REPLICA STATUS\G;
Lệnh này sẽ trả về rất nhiều thông tin hữu ích khi bạn cần khắc phục sự cố. Ví dụ, kết quả có thể trông như sau:
Output
*************************** 1. row ***************************
Replica_IO_State: Waiting for master to send event
Source_Host: 138.197.3.190
Source_User: replica_user
Source_Port: 3306
Connect_Retry: 60
Source_Log_File: mysql-bin.000001
Read_Source_Log_Pos: 1273
Relay_Log_File: mysql-relay-bin.000003
Relay_Log_Pos: 729
Relay_Source_Log_File: mysql-bin.000001
. . .
Lưu ý: Nếu replica gặp sự cố trong việc kết nối hoặc replication dừng đột ngột, có thể một sự kiện trong file binary log của nguồn đang gây cản trở. Trong trường hợp đó, bạn có thể chạy lệnh
SET GLOBAL SQL_SLAVE_SKIP_COUNTERđể bỏ qua một số sự kiện sau vị trí binary log đã định nghĩa ở lệnh trước. Ví dụ, để bỏ qua sự kiện đầu tiên:SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;Sau đó, bạn cần khởi động lại replica:
START REPLICA;Nếu bạn cần dừng replication, có thể chạy lệnh sau trên instance replica:
STOP REPLICA;
Máy chủ replica của bạn bây giờ đã sao chép dữ liệu từ nguồn. Mọi thay đổi bạn thực hiện trên cơ sở dữ liệu nguồn sẽ được phản ánh trên instance MySQL của replica. Bạn có thể kiểm tra điều này bằng cách tạo một bảng mẫu trên cơ sở dữ liệu nguồn và kiểm tra xem nó có được sao chép thành công trên replica hay không.
Bắt đầu bằng cách mở MySQL shell trên máy chủ nguồn:
sudo mysql
Chọn cơ sở dữ liệu bạn đã chọn để sao chép:
USE db;
Sau đó, tạo một bảng trong cơ sở dữ liệu đó. Ví dụ, lệnh SQL sau tạo một bảng có tên example_table với một cột có tên example_column:
CREATE TABLE example_table ( example_column varchar(30) );
Output Query OK, 0 rows affected (0.03 sec)
Nếu bạn muốn, bạn có thể thêm một số dữ liệu mẫu vào bảng này:
INSERT INTO example_table VALUES
('This is the first row'),
('This is the second row'),
('This is the third row');
Output Query OK, 3 rows affected (0.03 sec) Records: 3 Duplicates: 0 Warnings: 0
Sau khi tạo bảng và (nếu cần) thêm dữ liệu mẫu, quay trở lại MySQL shell trên máy chủ replica và chọn cơ sở dữ liệu đã được sao chép:
USE db;
Sau đó chạy lệnh SHOW TABLES để liệt kê tất cả các bảng trong cơ sở dữ liệu:
SHOW TABLES;
Nếu replication hoạt động đúng, bạn sẽ thấy bảng example_table được liệt kê trong kết quả:
Output +---------------+ | Tables_in_db | +---------------+ | example_table | +---------------+ 1 row in set (0.00 sec)
Ngoài ra, nếu bạn đã thêm dữ liệu mẫu vào bảng trên nguồn, bạn có thể kiểm tra xem dữ liệu đó có được sao chép bằng câu lệnh sau:
SELECT * FROM example_table;
Trong SQL, dấu hoa thị (*) là viết tắt của “tất cả các cột.” Vì vậy, câu lệnh này yêu cầu MySQL trả về tất cả các cột từ bảng example_table. Nếu replication hoạt động như mong đợi, kết quả sẽ hiển thị dữ liệu mẫu:
Output +------------------------+ | example_column | +------------------------+ | This is the first row | | This is the second row | | This is the third row | +------------------------+ 3 rows in set (0.00 sec)
Nếu một trong các thao tác trên không trả về bảng hoặc dữ liệu như mong đợi, có thể cấu hình replication của bạn có lỗi. Trong trường hợp đó, hãy chạy lệnh SHOW REPLICA STATUS\G để tìm nguyên nhân.
Ngoài ra, bạn có thể tham khảo tài liệu của MySQL về khắc phục sự cố replication để được gợi ý cách giải quyết các vấn đề.
Kết Luận
Sau khi hoàn thành hướng dẫn này, bạn đã thiết lập thành công hệ thống MySQL replication bằng phương pháp sao chép dựa trên vị trí binary log, giúp đồng bộ dữ liệu giữa một máy chủ nguồn (source) và một máy chủ sao chép (replica). Đây chỉ là một trong nhiều cách triển khai replication trong MySQL, và tùy vào nhu cầu cụ thể, bạn có thể khám phá thêm các phương pháp khác như GTID-based replication hoặc multi-source replication để tối ưu hiệu suất. Bên cạnh đó, các giải pháp nâng cao như Galera Cluster cũng có thể được xem xét để cải thiện khả năng chịu lỗi và mở rộng quy mô hệ thống. Việc lựa chọn mô hình replication phù hợp sẽ giúp bạn quản lý dữ liệu hiệu quả hơn, đảm bảo tính toàn vẹn và hiệu suất cao cho ứng dụng của mình.
Nếu bạn có thêm bất kỳ câu hỏi nào về khả năng cụ thể của replication trong MySQL, chúng tôi khuyến khích bạn tham khảo tài liệu chính thức của MySQL về chủ đề này. Nếu bạn muốn tìm hiểu thêm về MySQL nói chung, bạn cũng có thể tham khảo toàn bộ thư viện nội dung liên quan đến MySQL của chúng tôi.
