Master-slave çoğaltma kurulumuyla MySQL-5.1.50 kullanıyorum.

Çoğu zaman köle efendinin gerisinde kalıyor.

Çalıştığımda show processlist;, uzun süren bir sorgu yok. Ben de etkinleştirdim slow_log. Ancak, yavaş çalışan bir sorgu bulamaz.

Köle sürekli olarak çoğaltmanın master'ın arkasında saniye olduğuna dair uyarılar veriyor. Bazen gecikme süresi artar.

Sorunun nedenini nasıl teşhis edebilirim?

Acil yardıma ihtiyacım var, çünkü bu sorun 20 gündür devam ediyor.

Seconds_Behind_Master gerçekten zaman yolculuğu ile geçmişi görmek gibidir.

Bu şekilde düşün:

• Güneş Dünya'dan 93.000.000 mil uzakta
• Işık hızı 186.000 mil / sn'dir.
• Basit bölünme, Güneş ışığının Dünya'ya ulaşmasının yaklaşık 500 saniye (8 dakika 20 saniye) sürdüğünü gösterir
• Güneşe baktığınızda, aslında Güneş'i görmezsiniz. 8 dakika 20 saniye önce nerede olduğunu görüyorsunuz.

Benzer şekilde, Kaptan'ın aynı anda birçok sorguyu işlediği görülüyor.

Köle geri bak, kaç SHOW SLAVE STATUS\Gve 200 diyor Seconds_Behind_Master. Bu sayı nasıl hesaplanıyor? Slave Saat Saati (UNIX_TIMESTAMP (NOW ()) - Tamamlandığında ve Master'ın İkili Günlüğüne kaydedildiğinde Sorgunun TIMESTAMP'ı.

Ayrıca bakılması gereken bir metrik daha var Seconds_Behind_Master. Bu metriğe denir Relay_Log_Space. Bu, Slave üzerindeki tüm geçiş dosyaları için tüm baytların toplamını temsil eder. Varsayılan olarak, en büyük tek röle günlüğü 1 GB ile sınırlıdır. Eğer Relay_Log_Spacedaha az 1GB fazla olması, bu pek uzun süren sorguları paralel Master yürüttüğünü gösterir. Ne yazık ki, tek iş parçacıklı doğa Çoğaltma'nın SQL iş parçacığı nedeniyle, sorgular birbiri ardına yürütülür.

Örneğin, Master'da aşağıdaki senaryolara sahip olduğunuzu varsayalım:

• Yavaş Sorgu günlüğü etkin
• Master'da paralel olarak yürütülen 20 sorgu
• Her sorgu 3 saniye sürdü
• Her sorgu aynı zaman damgası ile Ana İkili Günlüğe kaydedilir

Slave bu sorguları geçiş günlüğünden okuduğunda ve bunları tek tek işlediğinde

• Köle Saati hareket edecek
• 20 sorgunun her biri için TIMESTAMP aynı olacaktır
• fark 3 saniye artacak sorgu tamamlanacak
• bu, 60 saniye içinde Seconds_Behind_Master

Yavaş Günlük ile ilgili olarak, long_query_time için varsayılan değer 10 saniyedir. Geçiş günlüklerindeki tüm sorgularınız 10 saniyeden azsa, Yavaş Sorgu Günlüğünde hiçbir şey yakalamazsınız.

Hem Master hem de Slave sunucular için aşağıdaki önerilerim var

• ÖNERİ # 1 : MySQL 5.5 sürümüne geçin . MySQL 5.5 ve Percona Server 5.1.38+ altında, InnoDB'yi birden fazla CPU'ya erişecek şekilde ayarlayabilirsiniz. Bununla ilgili geçmiş yazılar yazdım
  • Apr 26, 2012: CPU performansı bir veritabanı sunucusuyla alakalı mı?
  • Sep 20, 2011: Çoklu çekirdekler ve MySQL Performansı
  • Sep 12, 2011: MySQL'in birden fazla çekirdeği kullanabilmesi mümkün mü?
  • May 26, 2011: Tek iş parçacıklı ve çok iş parçacıklı veritabanlarının performansı hakkında
• ÖNERİ # 2 : Tüm tablolar için InnoDB kullanın . InnoDB RAM'deki verileri ve dizinleri önbelleğe alır, MyISAM sadece dizinleri önbelleğe alır.
• ÖNERİ # 3 : RAM'i artırın . Slave ve Master'da daha fazla veri ve indeks önbelleğe almalısınız
• ÖNERİ # 4 : Tüm sorguları ayarlayın. Yüzlerce kez çalışan sorgulardan milisaniyeyi azaltmak, azaltılması çok uzun bir yol kat ediyor Seconds_Behind_Master.

DAHA FAZLA SORUN GİDERME

Geri yükleme gecikmesine neden olan sorguları görmek istiyorsanız, aşağıdakileri yapın:

• SHOW SLAVE STATUS\G
• Aktarma günlüğünün adını şuradan al Relay_Log_File
• STOP SLAVE;
• START SLAVE;
• İşletim sisteminde cd /var/lib/mysqlveya röle günlüklerinin yazıldığı her yerde
• Geçiş günlüğünü bir metin dosyasına döküm

Örneğin, yapalı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

Çalıştırırsam STOP SLAVE; START SLAVE;, röle günlüğü kapanır ve yenisi açıktır. Yine de istiyorsun relay-bin.000030.

İçeriği aşağıdaki gibi boşaltın:

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

Artık Slave'in şu anda işlemeye çalıştığı sorguları görebilirsiniz. Bu sorguları ayarlama için başlangıç ​​noktası olarak kullanabilirsiniz.

Hangi ikili günlük biçimini kullanıyorsunuz? ROW veya STATEMENT kullanıyor musunuz?
" SHOW GLOBAL VARIABLES LIKE 'binlog_format';"

ROW'u binlog biçimi olarak kullanıyorsanız, tüm tablolarınızda Birincil veya Benzersiz Anahtar bulunduğundan emin olun:
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;

PK veya benzersiz anahtarı olmayan bir tablodaki 1 milyon kaydı silmek için master'da bir delete deyimi yürütürseniz, master tarafında yalnızca bir tam tablo taraması gerçekleşir, bu da slave'de geçerli değildir.
ROW binlog_format kullanılırken, MySQL satır değişikliklerini ikili günlüklere yazar (STATEMENT binlog_format gibi bir ifade olarak değil) ve bu değişiklik slave'in yan satırına satır satır uygulanır, yani 1 milyon tam tablo taraması gerçekleşir köle üzerinde master sadece bir silme ifadesi yansıtacak ve bu köle gecikme sorununa neden oluyor.

SHOW SLAVE STATUS içindeki seconds_behind_master değeri, olay ilk kez yürütüldüğünde ve ikili günlüğe kaydedildiğinde depolanan sistem zamanı ile olay orada yürütüldüğünde slave'deki sistem zamanı arasındaki farktır.

İki sistemin saatleri senkronize değilse master'ın arkasındaki saniyeler yanlış değerler verecektir.