Practical MySQL & MariaDB

Giải thích Replication MySQL: Hướng dẫn Cài đặt, GTID, Giám sát và Khắc phục sự cố

Nâng cao / Khác
目次

1. MySQL Replication là gì? Tổng quan và các trường hợp sử dụng

MySQL replication là một tính năng đồng bộ các bản sao của cơ sở dữ liệu sang các máy chủ khác trong thời gian thực. Điều này cải thiện tính dự phòng và hiệu năng của cơ sở dữ liệu. Dưới đây, chúng tôi giải thích chi tiết khi nào sử dụng MySQL replication và cách nó hoạt động.

Tổng quan về MySQL Replication

MySQL replication chia sẻ nội dung cơ sở dữ liệu giữa nhiều máy chủ bằng cách sử dụng máy chủ master và một hoặc nhiều máy chủ slave. Cụ thể, các cập nhật dữ liệu được ghi vào binary log của máy chủ master sẽ được đọc và áp dụng bởi các máy chủ slave để giữ cho dữ liệu luôn đồng bộ. Điều này cho phép duy trì dịch vụ bằng cách chuyển sang máy chủ slave nếu máy chủ master gặp sự cố.

Các trường hợp sử dụng MySQL Replication

MySQL replication được áp dụng rộng rãi trong các kịch bản sau:

  • High Availability : Khi có sự cố, việc chuyển sang máy chủ slave giúp giảm thiểu thời gian ngừng hoạt động.
  • Load Balancing : Các truy vấn chỉ đọc có thể được phân phối tới các máy chủ slave, giảm tải cho máy chủ master.
  • Data Protection and Backup : Vì replication sao chép dữ liệu trong thời gian thực, nó cũng có thể đóng vai trò là cơ chế sao lưu.

Các loại Replication

MySQL replication bao gồm các loại sau dựa trên phương pháp đồng bộ hóa:

  • Asynchronous Replication : Máy chủ master tiếp tục mà không chờ xác nhận từ slave. Điều này cho phép phản hồi nhanh hơn nhưng có thể dẫn đến một số dữ liệu chưa tới slave khi có sự cố.
  • Semi-Synchronous Replication : Máy chủ master chờ xác nhận rằng dữ liệu đã được nhận bởi slave trước khi tiếp tục. Điều này mang lại độ tin cậy cao hơn so với asynchronous replication, mặc dù phản hồi sẽ chậm hơn một chút.

Phần tiếp theo sẽ giải thích các khái niệm cơ bản của MySQL replication, bao gồm binary log và GTID.

2. Các khái niệm cơ bản của MySQL Replication

Để hiểu MySQL replication, cần nắm rõ vai trò của binary log và GTID (Global Transaction ID), những thành phần quan trọng trong quá trình replication. Những yếu tố này tạo nền tảng cho việc sao chép dữ liệu chính xác.

Vai trò của Master và Slave

Trong MySQL replication, máy chủ master và máy chủ slave có những vai trò riêng biệt. Master ghi lại các cập nhật dữ liệu vào binary log và gửi chúng tới slave. Slave áp dụng các log đã nhận để cập nhật dữ liệu của mình. Kết quả là slave duy trì cùng một bộ dữ liệu như master.

Binary Log và Relay Log

MySQL replication dựa vào hai loại log sau:

  1. Binary Log
  • Binary log ghi lại các cập nhật dữ liệu (như INSERT, UPDATE và DELETE) trên máy chủ master. Điều này cho phép máy chủ slave duy trì trạng thái dữ liệu giống như master.
  1. Relay Log
  • Relay log lưu trữ các sự kiện binary log nhận được từ master trên máy chủ slave. Thread SQL của slave thực thi relay log một cách tuần tự để áp dụng các thay đổi dữ liệu.

GTID (Global Transaction ID) là gì?

GTID là cơ chế gán một ID duy nhất cho mỗi giao dịch, giúp duy trì tính nhất quán giữa nhiều slave. Khi sử dụng GTID, việc chỉ định vị trí binary log trở nên không cần thiết. Chỉ các giao dịch chưa được lấy từ master mới tự động được áp dụng vào slave, giúp đơn giản hoá việc quản lý.

Lợi ích của GTID

  • Unique Identification : Mỗi giao dịch được gán một GTID duy nhất, cho phép xác định rõ ràng giao dịch nào đã được áp dụng.
  • Easier Recovery : Khi dùng GTID, chỉ các giao dịch chưa được áp dụng sẽ được xử lý lại sau khi master hoặc slave khởi động lại.
  • Efficient Operational Management : Ngay cả trong môi trường quy mô lớn với nhiều slave, tính nhất quán của giao dịch vẫn được duy trì với việc quản lý đơn giản hơn.

Để sử dụng GTID, cần bật các thiết lập gtid_mode=ON và enforce_gtid_consistency=ON. Cấu hình các thiết lập này trên cả master và slave sẽ kích hoạt replication dựa trên GTID.

Phần tiếp theo sẽ giải thích các bước cụ thể để thiết lập MySQL replication.

3. Quy trình thiết lập MySQL Replication

Phần này giải thích các bước cần thiết để thiết lập MySQL replication. Bằng cách thực hiện các bước này, bạn có thể cấu hình một cấu trúc master‑slave cơ bản và bật đồng bộ dữ liệu thời gian thực.

Cấu hình máy chủ Master

Đầu tiên, chỉnh sửa tệp cấu hình của máy chủ master (thường là my.cnf hoặc my.ini) để bật binary log và đặt ID máy chủ.

  1. Chỉnh sửa tệp cấu hình
  • Thêm các cài đặt sau vào phần [mysqld] và đặt một server-id duy nhất (ví dụ: 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id phải là một số duy nhất cho mỗi máy chủ, và log-bin bật binary log.
  1. Tạo người dùng Replication
  • Tạo một người dùng replication chuyên dụng trên máy chủ master và cấp các quyền cần thiết.
    CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
FLUSH PRIVILEGES;
  • Người dùng này cần thiết để máy chủ slave truy cập dữ liệu từ master.
  1. Kiểm tra trạng thái Master
  • Kiểm tra tệp binary log hiện tại và vị trí (vị trí log). Thông tin này cần thiết khi cấu hình máy chủ slave.
    SHOW MASTER STATUS;
  • File (tên tệp log) và Position được hiển thị bởi lệnh này sẽ được sử dụng trong cấu hình slave.

Cấu hình máy chủ Slave

Tiếp theo, chỉnh sửa tệp cấu hình của máy chủ slave và cấu hình server-id cũng như thông tin master.

  1. Chỉnh sửa tệp cấu hình
  • Đặt một server-id duy nhất trên máy chủ slave (ví dụ: 2). Giá trị này phải khác với server-id của master.
    [mysqld]
server-id=2

  • Thường cũng đặt read_only=ON để ngăn việc ghi dữ liệu trên máy chủ slave. 1. Cấu hình thông tin Master trên Slave

  • Thực thi lệnh sau trên máy chủ slave, chỉ định hostname của master, người dùng, tên tệp binary log và vị trí.

    CHANGE MASTER TO
    MASTER_HOST='master_host',
    MASTER_USER='repl',
    MASTER_PASSWORD='password',
    MASTER_LOG_FILE='mysql-bin.000001',
    MASTER_LOG_POS=123;

  • Nhập các giá trị đã xác nhận trước đó trên master cho MASTER_LOG_FILE và MASTER_LOG_POS . 1. Bắt đầu Replication

  • Chạy lệnh sau trên máy chủ slave để bắt đầu replication.

    START SLAVE;

Xác minh trạng thái Replication

Xác minh rằng replication giữa master và slave đã được cấu hình đúng.

  • Check Master Status
    SHOW MASTER STATUS;
  • Check Slave Status
    SHOW SLAVE STATUS\G;
  • Nếu Slave_IO_Running và Slave_SQL_Running đều hiển thị Yes, replication đang hoạt động bình thường.

Phần tiếp theo giải thích các cấu hình replication nâng cao, bao gồm sự khác nhau giữa replication bất đồng bộ và bán đồng bộ và cách thiết lập bằng GTID.

4. Các loại Replication và Sử dụng nâng cao

MySQL replication bao gồm hai loại chính dựa trên phương pháp đồng bộ dữ liệu: replication bất đồng bộ và replication bán đồng bộ. Bằng cách hiểu đặc điểm của chúng và lựa chọn dựa trên trường hợp sử dụng của bạn, bạn có thể cải thiện cả hiệu năng hệ thống và độ tin cậy. Phần này cũng giải thích lợi ích của việc sử dụng GTID (Global Transaction Identifier) cho cấu hình replication.

Sự khác nhau giữa Replication bất đồng bộ và bán đồng bộ

1. Replication bất đồng bộ

Trong replication bất đồng bộ, máy chủ master trả về phản hồi cho client ngay sau khi hoàn thành một giao dịch. Nói cách khác, master có thể tiếp tục xử lý các yêu cầu mới ngay cả khi việc đồng bộ tới máy chủ slave bị trì hoãn. Điều này mang lại hiệu năng phản hồi xuất sắc và phù hợp với các hệ thống tập trung vào phân phối tải. Tuy nhiên, trong trường hợp lỗi, có nguy cơ dữ liệu chưa được áp dụng lên slave có thể bị mất.

2. Replication bán đồng bộ

.In semi-synchronous replication, the master server returns a response to the client only after confirming that data transfer to the slave server has completed. This improves data consistency, but because it waits for the slave, transaction response times may increase. Semi-synchronous replication is well suited for systems that require high data consistency or environments where data reliability is the top priority.

Replication Using GTID

GTID (Global Transaction Identifier) assigns a unique ID to each transaction and maintains transaction consistency between the master and slave. Enabling GTID makes replication management easier compared to traditional binary log position-based replication.

Advantages of GTID

  • Improved Data Consistency : With GTID, the slave can automatically identify transactions that have not yet been applied, making it easier to preserve consistency.
  • Simplified Replication Management : GTID improves efficiency for failover, master/slave switching, and recovery tasks. Because you no longer need to specify binary log positions, operations become simpler.

GTID Replication Configuration

To use GTID, you must add and enable the following options in the configuration files of both the master and the slave.

Master Server Configuration

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Slave Server Configuration

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

In a GTID-enabled environment, replication is performed automatically via GTID simply by setting the master information on the slave using the CHANGE MASTER TO command.

The next section explains maintenance methods for MySQL replication and key monitoring points for operational management.

5. Maintenance and Monitoring of Replication

To operate MySQL replication properly, regular maintenance and monitoring are essential. This section explains commands for checking whether replication is functioning normally and how to handle common errors.

How to Check Replication Status

Use the following commands to check synchronization status between the master and the slave.

Checking Master Status

You can verify the master server’s replication status using the SHOW MASTER STATUS command. This command displays the current binary log file name and position, allowing you to confirm the latest updates that should be delivered to the slave.

SHOW MASTER STATUS;

The output typically includes the following fields:

  • File : The current binary log file name generated by the master
  • Position : The current position within the binary log
  • Binlog_Do_DB and Binlog_Ignore_DB : Databases included/excluded from replication

Checking Slave Status

You can check the slave server’s replication status using the SHOW SLAVE STATUS command. The results include information needed to determine whether the slave is operating correctly.

SHOW SLAVE STATUS\G;

Key fields include:

  • Slave_IO_Running and Slave_SQL_Running : If both are Yes , the slave is running normally.
  • Seconds_Behind_Master : Indicates how far the slave is behind the master (in seconds). Ideally, this value should be 0.

Troubleshooting Replication

Common issues during replication operation include connection errors and data inconsistencies. Below are typical error cases and how to address them.

1. Connection Errors

If Slave_IO_Running is No, it means the slave cannot connect to the master. Try the following:

  • Verify the master hostname or IP address : Make sure the master address is correct.
  • Check firewall settings : Confirm that the required port (usually 3306) is open.

2. Data Inconsistency

.If Last_Error contains an error message, a data inconsistency may have occurred between the master and slave. In such cases, stop the slave and apply corrections before restarting replication.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Giảm Độ Trễ Sao Chép

Replication lag can be caused by slave hardware limitations or network issues. If needed, upgrading the slave server configuration can improve performance.

The next section explores replication troubles in more detail and provides further solutions.

6. Các Vấn Đề Thông Thường và Giải Pháp của Chúng

During MySQL replication operation, various issues may arise. This section explains common problems and how to resolve them. Detecting issues early and applying the correct fixes helps maintain stable system operation.

1. Khi Slave_IO_Running Bị Dừng

Triệu chứng: Nếu Slave_IO_Running shows No in the output of SHOW SLAVE STATUS, the slave is unable to connect to the master.

Nguyên Nhân và Giải Pháp:

  • Network Issues : If there is a network connectivity problem, the slave cannot access the master. Check firewall settings and confirm that the master is reachable.
  • Incorrect Master Hostname or IP Address : Verify that the hostname or IP address specified in CHANGE MASTER TO is correct.
  • User Privilege Issues : If the replication user on the master does not have sufficient privileges, the connection will fail. Confirm that the correct privileges have been granted using GRANT REPLICATION SLAVE .

2. Sự Không Nhất Quán Dữ Liệu trên Slave

Triệu chứng: Nếu data does not match between the master and slave, the slave may enter an inconsistent state.

Nguyên Nhân và Giải Pháp:

  • Manual Data Correction : Stop the slave, manually fix the problematic transaction, and then restart replication. STOP SLAVE; # Fix data if necessary START SLAVE;
  • Resynchronization : If the inconsistency is large-scale, take a full backup from the master and resynchronize the slave.

3. Độ Trễ Sao Chép

Triệu chứng: Nếu Seconds_Behind_Master is not 0 in the output of SHOW SLAVE STATUS, the slave is lagging behind the master. Ideally, this value should be as close to 0 as possible.

Nguyên Nhân và Giải Pháp:

  • Slave Hardware Limitations : If the slave server has insufficient resources, it may not keep up. Upgrading hardware can be effective.
  • Query Optimization : If queries received from the master take too long to execute on the slave, replication delay can occur. Adding indexes and optimizing queries can reduce processing time.

4. Lỗi Quyền Người Dùng Sao Chép

Triệu chứng: Nếu Last_Error shows a permission-related message, the slave may not have sufficient privileges to connect to the master.

Nguyên Nhân và Giải Pháp:

  • Reconfigure User Privileges : Ensure that a user with appropriate privileges exists on the master. Reconfigure if necessary. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Tăng Trưởng Binary Log

Triệu chứng: The master’s binary logs may grow excessively, consuming disk space.

Nguyên Nhân và Giải Pháp:

  • Binary Log Rotation : Regularly delete or archive binary logs to prevent excessive growth. By configuring expire_logs_days , you can automatically remove logs older than a specified period. SET GLOBAL expire_logs_days = 7; # Delete logs older than 7 days

By understanding these common MySQL replication issues and their solutions, you can ensure smoother operational management. The next section summarizes key points for replication management.

7. Kết Luận

MySQL replication là một tính năng quan trọng để cải thiện tính nhất quán dữ liệu và độ tin cậy hệ thống. Trong bài viết này, chúng tôi đã bao quát mọi thứ từ các khái niệm cơ bản về sao chép MySQL đến các thủ tục thiết lập, thực hành giám sát và phương pháp khắc phục sự cố. Dưới đây là tóm tắt các điểm chính để quản lý sao chép hiệu quả.

Các Điểm Chính Cần Nhớ

  1. Chọn Loại Sao Chép Phù Hợp
  • Sao chép bất đồng bộ cung cấp thời gian phản hồi nhanh hơn và lý tưởng cho việc phân phối tải. Tuy nhiên, nếu độ tin cậy là ưu tiên, sao chép bán đồng bộ phù hợp hơn. Chọn dựa trên yêu cầu hệ thống của bạn.
  1. Sử Dụng GTID Hiệu Quả
  • GTID loại bỏ nhu cầu chỉ định vị trí nhật ký nhị phân và cho phép quản lý giao dịch mượt mà. Nó đặc biệt hữu ích trong môi trường có nhiều slave hoặc nơi failover là quan trọng.
  1. Giám Sát Trạng Thái Thường Xuyên
  • Sử dụng SHOW MASTER STATUS và SHOW SLAVE STATUS để giám sát thường xuyên trạng thái hoạt động của cả máy chủ master và slave. Hành động kịp thời khi phát hiện bất thường sẽ giảm thiểu rủi ro như không nhất quán dữ liệu hoặc độ trễ.
  1. Làm Chủ Khắc Phục Sự Cố Cơ Bản
  • Các vấn đề sao chép phổ biến bao gồm lỗi kết nối slave, không nhất quán dữ liệu và độ trễ. Hiểu các giải pháp cơ bản cho mỗi vấn đề đảm bảo hoạt động mượt mà hơn.
  1. Quản Lý Nhật Ký Nhị Phân
  • Vì nhật ký nhị phân có thể tiêu tốn không gian đĩa đáng kể, khuyến nghị cấu hình expire_logs_days cho việc dọn dẹp tự động và thực hiện bảo trì thường xuyên.

Sao chép MySQL không phải là nhiệm vụ thiết lập một lần. Giám sát liên tục và bảo trì đúng cách là thiết yếu. Bằng cách xem xét thường xuyên trạng thái hệ thống và điều chỉnh cấu hình khi cần thiết, bạn có thể xây dựng và duy trì một hệ thống cơ sở dữ liệu đáng tin cậy cao.

Chúng tôi hy vọng hướng dẫn này giúp bạn hiểu và triển khai sao chép MySQL tốt hơn. Chúc bạn có các hoạt động sao chép mượt mà và ổn định.