MySQL röle günlüğü bozuk, nasıl düzeltebilirim? Denenmiş fakat başarısız

Makine aniden kapandığında bir MySQL v5.1.61 röle bozuldu. Tamir etmeye çalıştım ama işe yaramadı.
- Nasıl düzeltebilirim? Ben yanlış bir şey mi yaptım?

Okuduğum kadarıyla, bozuk MySQL röle günlükleri kolayca sabitlenir:

change master to master_log_file='<Relay_Master_Log_File>',
                 master_log_pos=<Exec_Master_Log_Pos>;

nerede Relay_Master_Log_Fileve Exec_Master_Log_Postarafından listelenmiştir:
mysql> show slave status;

Ancak yaptığımda change master status ..., birincil bir anahtar ihlali hatası alıyorum. Bu nasıl mümkün olabilir? Yukarıdaki prosedür doğru değil mi, yoksa örneğin +1 eksik mi?

_{(Şimdilik, bir master-data mysqldump'ı master'dan köleye yeniden aktardım ve bu problemi çözdü. Ancak gelecekte bunu yapmak uygun olmayabilir.)}

Özel sorunumla ilgili ayrıntıları aşağıda bulabilirsiniz:

mysql> show slave status \G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: the-master-host
                  Master_User: replication
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000021
          Read_Master_Log_Pos: 33639968
               Relay_Log_File: mysql-relay-bin.000271
                Relay_Log_Pos: 2031587
        Relay_Master_Log_File: mysql-bin.000020
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
              Replicate_Do_DB: the_database
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 1594
                   Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 66395191
              Relay_Log_Space: 36559177
              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: NULL
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 1594
               Last_SQL_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.

Ve ben de öyle yaptım:

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Ve olan bu, bir PK hatası:

131122 15:17:29 [Note] Slave I/O thread: connected to master 'replication@the-master-host:3306',replication started in log 'mysql-bin.000020' at position 66395191
131122 15:17:29 [ERROR] Slave SQL: Error 'Duplicate entry '71373' for key 'PRIMARY'' on query. Default database: 'the_database'. Query: 'insert into ...  values ...', Error_code: 1062
131122 15:17:29 [Warning] Slave: Data truncated for column 'date' at row 1 Error_code: 1265
131122 15:17:29 [Warning] Slave: Duplicate entry '71373' for key 'PRIMARY' Error_code: 1062

Ben tavsiye edilen prosedürü (sadece aşağıdaki bağlantılara bakın) izledi düşünüyorum hala PK hata oluştu :-(? Http://bugs.mysql.com/bug.php?id=26489 , "Geçici" için arama. Http: //mhbarr.wordpress.com/2013/07/26/mysql-slave-corrupted-relay-log/ /programming//a/14438408

Hata: Last_SQL_Errno: 1594 Last_SQL_Error: Röle günlüğü okuma hatası: Röle günlüğü olay girişi ayrıştırılamadı.

Bu hata, ana günlük dosyasının bozuk veya röle günlük dosyasının bozuk olduğu anlamına gelir.

• Bir şey yapmadan önce tüm veritabanlarınızı, günlüklerinizi, görüntü sunucularınızı yedekleyin, birkaç kez tekrarlayın ve yalnızca kendi sorumluluğunuzda devam edin.

İlk çalıştırmada "slave" show slave \ G "slave ve not:

Master_Log_File: mysql-bin.000026
Read_Master_Log_Pos: 2377104
Relay_Log_File: mysqld-relay-bin.000056
Relay_Log_Pos: 1097303
Relay_Master_Log_File: mysql-bin.000026
Exec_Master_Log_Pos: 1097157

Öncelikle ana günlük dosyasının sağlam olduğundan emin olmak istiyoruz, bu yüzden ana sunucuya atlayın ve Relay_Master_Log_File (check / var / log / mysql) komutunu bulun ve aşağıdaki komutu çalıştırın:

mysqlbinlog mysql-bin.000026

Günlük görüntülenecektir ancak umarım herhangi bir hata mesajı görmezsiniz. Hata mesajları görürseniz, ana günlükler bozuktur ve muhtemelen yeniden görüntülemeniz gerekir.

Daha sonra, bağımlı röle günlüğünde aynı komutu çalıştırın (genellikle / var / lib / mysql içinde)

mysqlbinlog mysqld-relay-bin.000056

Çoğaltmayı durduran bozulmayı gösteren bazı hatalar göreceksiniz, bunun gibi:

ERROR: Error in Log_event::read_log_event(): 'read error', data_len: 336, event_type: 2
ERROR: Could not read entry at offset 1097414: Error in log format or read error.
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@db:/var/lib/mysql#

Herhangi bir hata görüyorsanız, ana sistemdeki günlük düzgündür ve yalnızca kölenin geçiş günlüğü bozuktur. Bu iyi haber, köleyi sıfırlayabilir ve ustalara ayrıntılarını ve nereden devam edeceğini söyleyebiliriz. Herhangi bir hata görmüyorsanız, şimdi okumayı bırakın, farklı bir probleminiz var.

Bağımlı röle günlüğü hataları varsa, köle sıfırlamak ve bozuk günlükleri master'a yeniden bağlamak, tamam günlükleri almak ve yeniden bağlamaya başlamak için aşağıdaki komutları çalıştırın. MASTER_LOG_POS’un, Exec_Master_Log_PosMASTER_LOG_FILE’nin Relay_Master_Log_File( her ikisi de ilk komuttan alınan ve atılması gereken röle günlükleriyle eşleşen ilk DEĞİLDİR) olduğuna dikkat edin.

mysql> stop slave;
Query OK, 0 rows affected (0.14 sec)

mysql> reset slave all;
Query OK, 0 rows affected (0.43 sec)

mysql>  CHANGE MASTER TO MASTER_HOST='master.host.com', MASTER_USER='masteruser', MASTER_PASSWORD='masterpass', MASTER_LOG_FILE='mysql-bin.000026', MASTER_LOG_POS=1097157;
Query OK, 0 rows affected (0.93 sec)

mysql> start slave;
Query OK, 0 rows affected (0.00 sec)

[Slave'lerin röle günlüğü bozulduktan sonra MySQL replikasyonunu düzeltme]

Slave'deki MySQL replikasyonu (sürüm 5.XX) durdu. Slave_IO_Running Evet olarak işaretlendi, ancak Slave_SQL_Running No. Olarak işaretlendi. Basit stop / start slave yardımcı olmadı, bu yüzden daha fazla problem analizi gerekliydi. “Mysqlbinlog” ile test etmek bir hataya neden oldu çünkü mevcut kölenin röle günlüğü bozuk görünüyordu. Bu nedenle, çözüm mevcut röle binloglarını atmak ve slave'i son master binlog pozisyonuna getirmekti.

Hatayı düzeltmek için, slave'deki mevcut binlog dosyaları atılmalı ve yeni pozisyona getirilmelidir. Yeni binlog pozisyonunu ayarlamadan önce, SHAY SLAVE STATUS \ G komutunu kullanarak Relay_Master_Log_File ve Exec_Master_Log_Pos değerlerini bozuk bağımlı sunucudan hatırlamak önemlidir :

Relay_Master_Log_File: mysql-bin.002045
Exec_Master_Log_Pos: 103641119

Tamam, bu değerlerle yeni binlog konumu ayarlanabilir:

# stop slave
mysql> stop slave;

# make slave forget its replication position in the master's binary log
mysql> reset slave;

# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.002045', master_log_pos=103641119;

# start slave
mysql> start slave;

Sadece nota reset slavesilecektir master.info, relay-log.infove tüm röle günlük dosyaları, bu yüzden temiz kalanlar için gerekli değil /var/lib/mysqldizinde.

Bir yıldan fazla geçtiğini biliyorum, ama işte bu belirli soruna ne olmuş olabilir.

mysql> stop slave;
mysql> reset slave;
mysql> change master to master_host='the-master-host', master_user='replication', master_password='the-password', master_log_file='mysql-bin.000020', master_log_pos=66395191;
mysql> start slave;

Bozuk röle günlüğünü kaldırdığı için düzeltilmiş olması gerektiği gibi görünüyor.

Öyleyse, 1062 PK hatası alıyorsunuz.

Olağanüstü bir hata var ( http://bugs.mysql.com/bug.php?id=60847MySQL 5.5'te hala etkin ) vardır

Her ne kadar hata mysql - single işlem - flush-log'ları kullanmakla ilgili olsa da, ilgili bir tuhaflık vardır.

MySQL 5.5.15’te geçen hafta bir müşteri için Slave olarak çalışan bazı EC2 sunucularındaki tuhaflığı gördüm.

Master'da INSERT genişletilmiş çok sıralı bir satır vardı, burada eklenen her parça bir SELECT. Olan, bir sonraki atanacak otomatik artışı oluşturan röle günlüğündeki LAST_INSERT_ID'nin önceden çok satırlı ekler nedeniyle Slave'de zaten kullanımda olmasıydı.

Röle günlüğündeki serileştirilmiş INSERT benziyordu

INSERT INTO tablname (column,column) VALUES (value,value,...)

Sütun listesi, sayısal birincil anahtarı içermiyordu. 1062 hatası geri döndüğünde, başarısız olduğu sorguyu kullanırdım, sorguyu el ile çalıştırın. 1062 hatasını çarpmadı. Sonra her zamanki gibi atla köle komutlarını çalıştırdım:

STOP SLAVE;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
START SLAVE;
SET @sleepnumber = SLEEP(3);
SHOW SLAVE STATUS\G

Sonra çoğaltma yakalandı.

Benim tavsiyem ustadaki INSERT'lerinizi doğru bir şekilde seri hale getirmektir, çünkü bu hataya neden olan durum gerçekten önlenebilir.

Bunu oldukça doğru yaptınız (diğerlerinin dediği gibi).

Tek sorun master.info dosyasındadır (master'ın mysql-bin.log dosyasındaki konumu hakkında bilgi içerir) çünkü bu dosya her sorgulamadan sonra diske senkronize edilmez.

Bu nedenle, ana kayıt defterindeki konumlar hakkındaki bilgileriniz eskidir ve atlanması gereken zaten işlenmiş sorguları işliyorsunuzdur SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;.

Ne yazık ki, bazı sorguları UPDATE table SET counter=counter+1 WHERE id = 12345kullanırsanız binlog_format=STATEMENTve veritabanlarınızı kullanıyorsanız senkronizasyondan çıkabilirsiniz.

MySQL sunucusuna her olaydan sonra değişken sync_master_info değişkenini ayarlayarak master.info'yu senkronize etmesini söyleyebilirsiniz, ancak muhtemelen çok büyük performans sonuçları verecektir.