Giới thiệu về GTID

1. Tổng quan về GTID

GTID (Global Transaction Identifier) là một định danh duy nhất cho mỗi giao dịch trong hệ thống MySQL. Mỗi giao dịch được gán một GTID duy nhất, và GTID này chỉ được thực thi một lần trên một máy chủ để tránh việc thực thi lặp lại gây ra sự không nhất quán dữ liệu hoặc lỗi trong quá trình replication.

GTID được giới thiệu từ MySQL 5.6.5 và hoàn thiện từ phiên bản 5.6.10. Nó thay thế cho phương pháp replication truyền thống sử dụng binlog và position, thay vào đó sử dụng `master_auto_position=1` để tự động khớp điểm ngắt replication dựa trên GTID.

Trong replication truyền thống, slave không cần bật binlog, nhưng với GTID, binlog trên slave là bắt buộc để ghi lại các GTID đã thực thi.

2. Cấu trúc của GTID

Một GTID bao gồm hai phần: UUID của máy chủ và một số thứ tự.

Ví dụ: 7800a22c-95ae-11e4-983d-080027de205a:10

• UUID: Là định danh duy nhất cho mỗi instance MySQL. Nó cũng được truyền đến slave, vì vậy có thể coi nó là ID nguồn.
• Số thứ tự (Sequence number): Bắt đầu từ 1 và tự động tăng trên mỗi máy chủ MySQL. Mỗi giá trị tương ứng với một giao dịch.

3. Ưu điểm của GTID so với replication truyền thống

• Thực hiện failover đơn giản hơn: Không cần tìm kiếm file log và position như trước. Chỉ cần biết IP, port, tài khoản và mật khẩu của master, MySQL sẽ tự động tìm điểm đồng bộ thông qua GTID.
• Cài đặt replication đơn giản hơn: Quá trình thiết lập master-slave trở nên dễ dàng hơn.
• An toàn hơn: GTID đảm bảo tính nhất quán và an toàn cho dữ liệu.
• Không có khoảng trống: GTID là liên tục, vì vậy khi có xung đột dữ liệu, có thể bỏ qua bằng cách thêm một giao dịch trống.

4. Nguyên lý hoạt động của GTID

1. Master cập nhật dữ liệu, tạo GTID trước khi giao dịch và ghi vào binlog.
2. Thread I/O trên slave đọc binlog đã thay đổi từ master và ghi vào relay log cục bộ.
3. Thread SQL trên slave lấy GTID từ relay log và so sánh với binlog của chính nó.
4. Nếu GTID đã có trong binlog, slave sẽ bỏ qua.
5. Nếu chưa có, slave sẽ thực thi giao dịch từ relay log và ghi GTID vào binlog của mình.
6. Trong quá trình phân tích, hệ thống sẽ kiểm tra xem có khóa chính không, nếu không sẽ sử dụng chỉ mục thứ cấp, nếu không sẽ quét toàn bộ.

Cấu hình GTID

1. Chuẩn bị môi trường

• Hệ điều hành: CentOS 6.6 x86_64
• Phiên bản MySQL: 5.6.36 MySQL Community Server (Khuyến nghị sử dụng phiên bản 5.6.10 trở lên)
• Tắt firewall và SELinux
• Đồng bộ thời gian
• Cấu hình máy chủ:
  • Chủ (Master): 192.168.1.11
  • Phụ (Slave): 192.168.1.12

2. Cấu hình my.cnf trên Master và Slave để hỗ trợ GTID

Để sử dụng replication trong MySQL 5.6, phần cấu hình dịch vụ `[mysqld]` cần định nghĩa các tùy chọn sau:

• binlog-format: Định dạng log nhị phân, có row, statement và mixed.
• log-slave-updates, gtid-mode, enforce-gtid-consistency, report-port, report-host: Bật GTID và các yêu cầu liên quan.
• master-info-repository và relay-log-info-repository: Bật để đảm bảo an toàn cho binary log và thông tin slave trong trường hợp sập.
• sync-master-info: Bật để đảm bảo không mất thông tin.
• slave-paralles-workers: Đặt số lượng thread SQL trên slave; 0 để tắt replication đa luồng.
• binlog-checksum, master-verify-checksum, slave-sql-verify-checksum: Bật kiểm tra tổng cho replication.
• binlog-rows-query-log-events: Bật để ghi thông tin sự kiện vào binary log, giúp gỡ lỗi dễ dàng hơn.
• log-bin: Bật binary log, là điều kiện tiên quyết cho replication.
• server-id: ID của mỗi máy chủ trong topology replication phải là duy nhất.

Cấu hình trên Master:

Thêm các dòng sau vào phần `[mysqld]`:

binlog-format=ROW
log-slave-updates=true
gtid-mode=on
enforce-gtid-consistency=true
master-info-repository=TABLE
relay-log-info-repository=TABLE
sync-master-info=1
slave-parallel-workers=2
binlog-checksum=CRC32
master-verify-checksum=1
slave-sql-verify-checksum=1
binlog-rows-query-log_events=1
server-id=1
report-port=3306
report-host=192.168.1.11

Cấu hình trên Slave:

Cài đặt MySQL trên Slave tương tự như trên Master. Chỉ có hai tham số sau khác với Master:

server-id=2
report-host=192.168.1.12

Khởi động lại dịch vụ MySQL.

3. Tạo user replication trên Master

mysql> grant replication slave, replication client on *.* to 'sao_chép'@'192.168.1.%' identified by 'mat_khau_123';
Query OK, 0 rows affected (0.15 sec)

mysql> flush privileges;
Query OK, 0 rows affected (0.06 sec)

4. Khóa Master ở chế độ chỉ đọc và xem vị trí binary log

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.10 sec)

mysql> SHOW MASTER STATUS;
+------------------+----------+--------------+------------------+------------------------------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set                        |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000001 |      561 |              |                  | e9598c9e-f605-11e7-9c77-000c29c24776:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.04 sec)

5. Sao lưu cơ sở dữ liệu và sao chép sang slave

Trong một kết nối SSH khác, thực hiện sao lưu:

[root@chủ ~]# mysqldump --single-transaction --master-data=2 --all-databases --triggers --routines --events  > /tmp/backup_db.sql
[root@chủ ~]# scp /tmp/backup_db.sql 192.168.1.12:/root

6. Mở khóa Master

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.05 sec)

7. Nhập file SQL vào Slave và làm mới quyền

[root@phụ ~]# mysql < backup_db.sql
[root@phụ ~]# mysql -e "FLUSH PRIVILEGES;"

8. Thiết lập Master trên Slave

mysql> CHANGE MASTER TO MASTER_HOST='192.168.1.11', MASTER_USER='sao_chép', MASTER_PASSWORD='mat_khau_123', MASTER_LOG_FILE='mysql-bin.000001', MASTER_LOG_POS=561;
Query OK, 0 rows affected, 2 warnings (0.17 sec)

mysql> start slave;
Query OK, 0 rows affected, 1 warning (0.15 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.1.11
                  Master_User: sao_chép
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000001
          Read_Master_Log_Pos: 561
               Relay_Log_File: relay-log.000002
                Relay_Log_Pos: 314
        Relay_Master_Log_File: mysql-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
             .........................<br></br>             ......................略
             Master_Server_Id: 1
                  Master_UUID: e9598c9e-f605-11e7-9c77-000c29c24776
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 826b1c09-f608-11e7-9c88-000c29e543b4:1,
e9598c9e-f605-11e7-9c77-000c29c24776:1-2
                Auto_Position: 0
1 row in set (0.00 sec)

9. Xem thông tin slave trên Master

mysql> show slave hosts;
+-----------+--------------+------+-----------+--------------------------------------+
| Server_id | Host         | Port | Master_id | Slave_UUID                           |
+-----------+--------------+------+-----------+--------------------------------------+
|         2 | 192.168.1.12 | 3306 |         1 | 826b1c09-f608-11e7-9c88-000c29e543b4 |
+-----------+--------------+------+-----------+--------------------------------------+
1 row in set (0.00 sec)