Saya menggunakan MySQL-5.1.50 dengan setup replikasi Master-slave.

Sebagian besar waktu budak tertinggal di belakang tuan.

Ketika saya menjalankan show processlist;, tidak ada permintaan yang membutuhkan waktu lama. Saya mengaktifkan slow_logjuga. Namun, itu tidak menemukan permintaan berjalan lambat.

Budak terus memberi peringatan bahwa replikasi berada beberapa detik di belakang master. Terkadang, jeda waktu meningkat.

Bagaimana cara mendiagnosis penyebab masalah?

Saya butuh bantuan segera, karena masalah ini telah berlangsung selama 20 hari terakhir.

Seconds_Behind_Master sangat suka melihat masa lalu melalui perjalanan waktu.

Pikirkan seperti ini:

• Matahari adalah 93.000.000 mil jauhnya dari Bumi
• Kecepatan cahaya adalah 186.000 mil / detik
• Pembagian sederhana menunjukkan bahwa dibutuhkan sekitar 500 detik (8 menit 20 detik) untuk cahaya Matahari untuk mencapai Bumi
• Ketika Anda melihat Matahari, Anda sebenarnya tidak melihat Matahari. Anda lihat di mana itu 8 menit 20 detik yang lalu.

Dengan cara yang sama, tampaknya Master sedang memproses banyak pertanyaan pada saat yang bersamaan.

Anda melihat kembali pada Budak, jalankan SHOW SLAVE STATUS\Gdan dikatakan 200 untuk Seconds_Behind_Master. Bagaimana angka itu dihitung? Waktu Jam Slave (UNIX_TIMESTAMP (SEKARANG ()) - TIMESTAMP dari Kueri saat selesai dan dicatat dalam Log Biner Master.

Ada metrik lain untuk dilihat selain Seconds_Behind_Master. Metrik itu disebut Relay_Log_Space. Itu mewakili jumlah semua byte untuk semua file relai pada Slave. Secara default, log relai tunggal terbesar dibatasi hingga 1GB. Jika Relay_Log_Spacekurang dari 1GB, ini menunjukkan bahwa banyak permintaan yang berjalan lama dijalankan pada Master secara paralel. Sayangnya, karena sifat tunggal threaded Replication's SQL, query dieksekusi satu di belakang yang lain.

Misalnya, anggap Anda memiliki skenario berikut pada Master:

• Log Permintaan Lambat diaktifkan
• 20 pertanyaan dieksekusi secara paralel pada Master
• Setiap kueri membutuhkan waktu 3 detik
• Setiap kueri direkam dalam Master Binary Log dengan stempel waktu yang sama

Ketika Slave membaca queri-queri itu dari log relay dan memprosesnya satu per satu

• Jam Slave akan bergerak
• TIMESTAMP untuk masing-masing 20 pertanyaan akan sama
• perbedaan akan meningkat 3 detik menjadi permintaan selesai
• ini menghasilkan 60 detik untuk Seconds_Behind_Master

Mengenai Slow Log, default untuk long_query_time adalah 10 detik. Jika semua pertanyaan Anda dalam log relai kurang dari 10 detik, Anda tidak akan pernah menangkap apa pun di Log Kueri Lambat.

Saya memiliki rekomendasi berikut untuk server Master dan Slave

• REKOMENDASI ​​# 1 : Tingkatkan ke MySQL 5.5 . Di bawah MySQL 5.5 dan Percona Server 5.1.38+, Anda dapat menyetel InnoDB untuk mengakses banyak CPU. Saya telah menulis posting sebelumnya tentang ini
  • Apr 26, 2012: Apakah kinerja CPU relevan untuk server basis data?
  • Sep 20, 2011: Multi core dan Kinerja MySQL
  • Sep 12, 2011: Kemungkinan untuk menggunakan MySQL lebih dari satu inti?
  • May 26, 2011: Tentang kinerja basis data single threaded versus multithreaded
• REKOMENDASI ​​# 2 : Gunakan InnoDB untuk semua tabel . InnoDB melakukan cache data dan indeks dalam RAM, MyISAM hanya melakukan cache indeks.
• REKOMENDASI ​​# 3 : Tingkatkan RAM . Anda harus menyimpan lebih banyak data dan indeks pada Slave dan Master
• REKOMENDASI ​​# 4 : Menyetel semua pertanyaan. Mengurangi milidetik dari kueri yang berjalan ratusan kali akan jauh berkurang Seconds_Behind_Master.

PEMECAHAN MASALAH LEBIH LANJUT

Jika Anda ingin melihat kueri yang menyebabkan keterlambatan replciation, lakukan hal berikut:

• SHOW SLAVE STATUS\G
• Dapatkan nama log relai Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• Di OS, cd /var/lib/mysqlatau di mana pun log relai ditulis
• Buang log relai ke file teks

Misalnya, Ayo lakukan 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

Jika saya menjalankan STOP SLAVE; START SLAVE;, log relai ditutup dan yang baru terbuka. Tapi kamu mau relay-bin.000030.

Isi isinya sebagai berikut:

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

Anda sekarang dapat melihat pertanyaan yang sedang diproses oleh Slave. Anda dapat menggunakan kueri tersebut sebagai titik awal untuk penyetelan.

Apa format log biner yang Anda gunakan? Apakah Anda menggunakan ROW atau PERNYATAAN?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

Jika Anda menggunakan ROW sebagai format binlog, pastikan bahwa semua tabel Anda memiliki Kunci Utama atau Unik:
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;

Jika Anda menjalankan mis satu pernyataan penghapusan pada master untuk menghapus 1 juta catatan pada tabel tanpa PK atau kunci unik maka hanya satu pemindaian tabel penuh akan terjadi di sisi master, yang bukan kasus pada slave.
Ketika ROW binlog_format digunakan, MySQL menulis perubahan baris ke log biner (bukan sebagai pernyataan seperti STATEMENT binlog_format) dan perubahan itu akan diterapkan pada baris sisi budak secara berurutan, yang berarti pemindaian tabel penuh 1 juta akan dilakukan pada slave hanya merefleksikan satu pernyataan delete pada master dan itu menyebabkan masalah slave lagging.

Nilai seconds_behind_master di SHOW SLAVE STATUS adalah perbedaan antara waktu sistem pada master, yang disimpan ketika acara awalnya dieksekusi dan dicatat dalam log biner ... dan waktu sistem pada budak ketika acara dieksekusi di sana.

Detik di belakang master akan memberikan nilai yang salah jika jam kedua sistem tidak sinkron.