Tôi đang sử dụng MySQL-5.1.50 với thiết lập sao chép Master-Slave.

Hầu hết thời gian nô lệ bị tụt lại phía sau chủ.

Khi tôi chạy show processlist;, không có truy vấn nào mất nhiều thời gian. Tôi cũng kích hoạt slow_log. Tuy nhiên, nó không tìm thấy bất kỳ truy vấn chạy chậm.

Các nô lệ liên tục đưa ra cảnh báo rằng sao chép là chậm hơn so với chủ. Đôi khi, thời gian trễ tăng lên.

Làm thế nào để tôi chẩn đoán nguyên nhân của vấn đề?

Tôi cần sự giúp đỡ khẩn cấp, vì vấn đề này đã tồn tại trong 20 ngày qua.

Seconds_Behind_Master thực sự giống như xem quá khứ thông qua du hành thời gian.

Nghĩ theo cách này:

• Mặt trời là 93.000.000 dặm từ Trái Đất
• Vận tốc ánh sáng là 186.000 dặm / giây
• Phân chia đơn giản cho thấy phải mất khoảng 500 giây (8 phút 20 giây) để ánh sáng của Mặt trời đến Trái đất
• Khi bạn nhìn vào Mặt trời, bạn thực sự không thấy Mặt trời. Bạn thấy nơi đó là 8 phút 20 giây trước.

Theo cách tương tự, có vẻ như Master đang xử lý rất nhiều truy vấn cùng một lúc.

Bạn nhìn lại Slave, chạy SHOW SLAVE STATUS\Gvà nó báo 200 cho Seconds_Behind_Master. Con số đó được tính như thế nào? Thời gian đồng hồ của Slave (UNIX_TIMESTAMP (NOW ()) - TIMESTAMP của Truy vấn khi nó được hoàn thành và ghi lại trong Nhật ký nhị phân của Master.

Có một số liệu khác để xem xét bên cạnh Seconds_Behind_Master. Số liệu đó được gọi là Relay_Log_Space. Đó là tổng của tất cả các byte cho tất cả các tệp chuyển tiếp trên Slave. Theo mặc định, nhật ký chuyển tiếp đơn lớn nhất được giới hạn ở 1GB. Nếu Relay_Log_Spacedưới 1GB, điều này cho thấy rằng nhiều truy vấn chạy dài được thực thi song song trên Master. Thật không may, do tính chất SQL của Bản sao đơn luồng, các truy vấn được thực hiện nối tiếp nhau.

Ví dụ: giả sử bạn có kịch bản sau đây trên Master:

• Nhật ký truy vấn chậm được bật
• 20 truy vấn được thực hiện song song trên Master
• Mỗi truy vấn mất 3 giây
• Mỗi truy vấn được ghi lại trong Nhật ký nhị phân chính có cùng dấu thời gian

Khi Slave đọc các truy vấn đó từ nhật ký chuyển tiếp của nó và xử lý từng truy vấn một

• Đồng hồ của Slave sẽ di chuyển
• TIMESTAMP cho mỗi trong số 20 truy vấn sẽ giống hệt nhau
• sự khác biệt sẽ tăng 3 giây được hoàn thành truy vấn
• kết quả này trong 60 giây cho Seconds_Behind_Master

Liên quan đến Nhật ký chậm, mặc định cho long_query_time là 10 giây. Nếu tất cả các truy vấn của bạn trong nhật ký chuyển tiếp dưới 10 giây, bạn sẽ không bao giờ bắt được bất cứ điều gì trong Nhật ký truy vấn chậm.

Tôi có các đề xuất sau cho cả máy chủ Master và Slave

• KIẾN NGHỊ # 1 : Nâng cấp lên MySQL 5.5 . Trong MySQL 5.5 và Percona Server 5.1,38+, bạn có thể điều chỉnh InnoDB để truy cập nhiều CPU. Tôi đã viết bài trước đây về điều này
  • Apr 26, 2012: Hiệu suất CPU có phù hợp với máy chủ cơ sở dữ liệu không?
  • Sep 20, 2011: Đa lõi và hiệu suất MySQL
  • Sep 12, 2011: Có thể làm cho MySQL sử dụng nhiều hơn một lõi?
  • May 26, 2011: Giới thiệu về hiệu suất cơ sở dữ liệu đa luồng so với đa luồng
• KIẾN NGHỊ # 2 : Sử dụng InnoDB cho tất cả các bảng . InnoDB lưu trữ dữ liệu và chỉ mục trong RAM, MyISAM chỉ lưu trữ các chỉ mục.
• KIẾN NGHỊ # 3 : Tăng RAM . Bạn phải lưu trữ nhiều dữ liệu và chỉ mục hơn trên Slave và Master như nhau
• KIẾN NGHỊ # 4 : Điều chỉnh tất cả các truy vấn. Giảm mili giây từ các truy vấn chạy hàng trăm lần sẽ giúp giảm bớt Seconds_Behind_Master.

THÊM XỬ LÝ SỰ CỐ

Nếu bạn muốn xem các truy vấn gây ra độ trễ thay thế, hãy làm như sau:

• SHOW SLAVE STATUS\G
• Lấy tên của nhật ký chuyển tiếp từ Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• Trong HĐH, cd /var/lib/mysqlhoặc bất cứ nơi nào ghi nhật ký chuyển tiếp
• Kết xuất nhật ký chuyển tiếp vào một tệp văn bản

Ví dụ: Hãy làm SHOW SLAVE STATUS\G

               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.64.51.149
                  Master_User: replicant
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000009
          Read_Master_Log_Pos: 1024035856
               Relay_Log_File: relay-bin.000030
                Relay_Log_Pos: 794732078
        Relay_Master_Log_File: mysql-bin.000009
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB:
          Replicate_Ignore_DB: search_cache
           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: 1024035856
              Relay_Log_Space: 794732271
              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: 0
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: 106451149

Nếu tôi chạy STOP SLAVE; START SLAVE;, nhật ký chuyển tiếp sẽ đóng và một cái mới được mở. Tuy nhiên, bạn muốn relay-bin.000030.

Kết xuất nội dung như sau:

cd /var/lib/mysql
mysqlbinlog relay-bin.000030 > /root/RelayLogQueries.txt
less /root/RelayLogQueries.txt

Bây giờ bạn có thể thấy các truy vấn mà Slave hiện đang cố xử lý. Bạn có thể sử dụng các truy vấn đó làm điểm bắt đầu để điều chỉnh.

Định dạng nhật ký nhị phân nào bạn đang sử dụng? Bạn đang sử dụng ROW hay TUYÊN BỐ?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

Nếu bạn đang sử dụng ROW dưới dạng định dạng binlog, hãy đảm bảo rằng tất cả các bảng của bạn đều có Khóa chính hoặc Khóa duy nhất:
SELECT t.table_schema,t.table_name,engine FROM information_schema.tables t INNER JOIN information_schema .columns c on t.table_schema=c.table_schema and t.table_name=c.table_name and t.table_schema not in ('performance_schema','information_schema','mysql') GROUP BY t.table_schema,t.table_name HAVING sum(if(column_key in ('PRI','UNI'), 1,0)) =0;

Nếu bạn thực thi, ví dụ như một câu lệnh xóa trên bản gốc để xóa 1 triệu bản ghi trên bảng mà không có PK hoặc khóa duy nhất thì chỉ một lần quét toàn bộ bảng sẽ diễn ra ở phía chủ, không phải là trường hợp trên nô lệ.
Khi ROW binlog_format đang được sử dụng, MySQL sẽ ghi các hàng thay đổi thành nhật ký nhị phân (không phải là câu lệnh như STATMENT binlog_format) và thay đổi đó sẽ được áp dụng trên hàng bên của nô lệ, nghĩa là quét 1 triệu bảng đầy đủ sẽ diễn ra trên nô lệ chỉ phản ánh một câu lệnh xóa trên bản gốc và điều đó gây ra vấn đề độ trễ của nô lệ.

Giá trị giây_behind_master trong SHOW SLAVE STATUS là sự khác biệt giữa thời gian hệ thống trên bản gốc, được lưu trữ khi sự kiện ban đầu được thực hiện và ghi lại trong nhật ký nhị phân ... và thời gian hệ thống trên nô lệ khi sự kiện được thực thi ở đó.

Giây sau chủ sẽ đưa ra các giá trị không chính xác nếu đồng hồ của hai hệ thống không đồng bộ.