Bản sao MySQL: Giây sau Master siêu cao


8

Tôi đã thiết lập một máy chủ db nô lệ cho cơ sở dữ liệu sản xuất của mình, nhưng khi tôi kiểm tra trạng thái nô lệ hiển thị, tôi nhận thấy một con số siêu lớn chỉ sau vài giây.

Đây là đầu ra:

           Slave_IO_State: Waiting for master to send event
              Master_Host: 1.2.3.4
              Master_User: replicator
              Master_Port: 3306
            Connect_Retry: 60
          Master_Log_File: mysql-bin.000173
      Read_Master_Log_Pos: 15909435
           Relay_Log_File: mysqld-relay-bin.000079
            Relay_Log_Pos: 91173356
    Relay_Master_Log_File: mysql-bin.000093
         Slave_IO_Running: Yes
        Slave_SQL_Running: Yes
          Replicate_Do_DB: 
      Replicate_Ignore_DB: 
       Replicate_Do_Table: 
   Replicate_Ignore_Table: 
  Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
               Last_Errno: 0
               Last_Error: 
             Skip_Counter: 0
      Exec_Master_Log_Pos: 91173210
          Relay_Log_Space: 8179978166
          Until_Condition: None
           Until_Log_File: 
            Until_Log_Pos: 0
       Master_SSL_Allowed: No
       Master_SSL_CA_File: 
       Master_SSL_CA_Path: 
          Master_SSL_Cert: 
        Master_SSL_Cipher: 
           Master_SSL_Key: 
    Seconds_Behind_Master: 486330
Master_SSL_Verify_Server_Cert: No
            Last_IO_Errno: 0
            Last_IO_Error: 
           Last_SQL_Errno: 0
           Last_SQL_Error: 
Replicate_Ignore_Server_Ids: 
         Master_Server_Id: 1
1 row in set (0.00 sec)

ERROR: 
No query specified

Sau đó, khi tôi chạy SHOW PROCESSLIST, tôi thấy rằng thời gian của chuỗi khớp với thời gian được chỉ định trong vài giây sau:

mysql> SHOW PROCESSLIST;

| 40 | system user |           | NULL | Connect |  66530 | Waiting for master to send event | NULL             |
| 41 | system user |           | NULL | Connect | 486330 | Reading event from the relay log | NULL             |
| 45 | root        | localhost | NULL | Query   |      0 | NULL                             | SHOW PROCESSLIST |

Thời gian đó đang giảm dần, từ từ. Read_Master_Log_Pos, Relay_Log_Pos, Exec_Master_Log_Pos và Relay_Log_Space luôn thay đổi.

Tôi cũng đã kiểm tra thời gian / ngày và cả hai máy chủ đều được đồng bộ hóa.

Về phía chủ nhân:

mysql> SHOW PROCESSLIST;

| 66739 | replicator | 1.2.3.5:52884 | NULL                | Binlog Dump |    65671 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL             

và hiển thị máy chủ nô lệ trông trống rỗng ...

mysql> SHOW SLAVE HOSTS;
+-----------+------+------+-----------+
| Server_id | Host | Port | Master_id |
+-----------+------+------+-----------+
|         2 |      | 3306 |         1 |
+-----------+------+------+-----------+
1 row in set (0.00 sec)

mysql> 

Vì vậy, những gì đang thực sự xảy ra ở đây? Hình như nô lệ thực sự được kết nối và làm việc, nhưng rất rất chậm? Ai đó có thể cho tôi một số gợi ý về cách để gỡ lỗi nhiều hơn về điều này? Máy chủ khá nhàn rỗi ở mức 95%.

Câu trả lời:


15

Khi bạn nhìn thấy Seconds_Behind_Mastermức cao đó, tôi nhìn vào như sau:

Relay_Log_Space: 8179978166

Bạn có 7.6182GB nhật ký chuyển tiếp để xử lý.

Master_Log_File: mysql-bin.000173
Relay_Master_Log_File: mysql-bin.000093

Điều này cho tôi biết rằng bạn đã đọc đến mysql-bin.000173, nhưng bạn hiện đang xử lý mọi thứ từ mysql-bin.000093.

Điều này cũng cho tôi biết bạn có khoảng 80 nhật ký nhị phân trên Master, mỗi bản ghi khoảng 100 MB.

Đơn Seconds_Behind_Mastergiản chỉ là NOW () trừ đi bộ TIMESTAMP ở mysql-bin.000093vị trí 91173210(Relay_Master_Log_File) (Exec_Master_Log_Pos).

Miễn là Slave_Query_Thread là Có, nhật ký chuyển tiếp sẽ được xử lý

  • Relay_Log_Space sẽ giảm mỗi khi nhật ký chuyển tiếp được thực hiện
  • Exec_Master_Log_Pos sẽ tăng cho đến khi nhật ký rơle hiện tại được thực hiện, sau đó đặt lại vào đầu rơle tiếp theo
  • TIMESTAMP tiếp tục tăng, làm Seconds_Behind_Mastergiảm (NOW () trừ đi bộ TIMESTAMP tại vị trí Relay_Master_Log_File Exec_Master_Log_Pos)

Đây là những gì xảy ra khi tắt bản sao trong 486330 giây (5 ngày 15 giờ 5 phút 29 giây) và bạn chạy start slave;

Nhìn vào bạn SHOW PROCESSLIST;. Chủ đề IO đã tăng lên 66530 giây (18 giờ 28 phút 50 giây). Điều này có nghĩa là ai đó hoặc một cái gì đó bắt đầu sao chép 18 giờ 28 phút 50 giây trước.

Bạn đã nêu trong câu hỏi của bạn rằng bạn đã thiết lập sao chép cho máy chủ sản xuất. Điều này có nghĩa là bạn đã chạy mysqldump 5 ngày 15 giờ 5 phút 29 giây trước và bắt đầu sao chép từ bản gốc sản xuất 18 giờ 28 phút 50 giây trước.

Nếu bạn đã thiết lập Slave cùng ngày, bạn đã nhận được mysqldump từ Master, tải nhân rộng sẽ ít hơn rất nhiều. Mặc dù vậy, nhân rộng đang hoạt động bình thường được cung cấp Slave_IO_ThreadSlave_SQL_Threadcả hai đều nói Yes.


1
Chính xác. SLAVE START đã được lên kế hoạch để chạy một ngày sau bãi rác MASTER nhưng nó đã không xảy ra, vì vậy tôi đã phải SLAVE START sau một ngày cuối tuần dài. Những gì tôi đã làm là đặt innodb_flush_log_at_trx_commit = 2 và điều này đã làm giảm LAG. Làm thế nào an toàn là để làm điều này?
Matías
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.