Güç kesildi - Sorgu bitti mi?


9

Sorgunun bitip bitmediğini kontrol etmenin ve görmenin bir yolu var mı? Geçen hafta tatil için kapı dışarı gitti gibi 3 çok uzun çalışan güncelleme sorguları (her biri +/- 25 saat) koştu. Ne yazık ki, hafta boyunca bir yerlerde güç kesildi ve MYSQL'i çalıştıran makine kapandı. 3 sorgudan (veya üçünün de) tamamlandığını kontrol etmenin ve görmenin bir yolu var mı?

Verilerin güncellenip güncellenmediğini kontrol edebileceğimi biliyorum, ancak NULL'ların doğru ve eksiksiz bir yürütme ile beklenmesi gerekiyor ve incelemek için 48 milyon veri satırı var. Düşüncesi olan var mı?

mysql 

6
Günlükler ... bir şey kaydederseniz. Eğer yapmıyorsanız başlamanızı tavsiye ederim.
Ben

1
@ Ben - bir UPS ve işlem işleme tavsiye için çok geç, sanırım.

1
InnoDB kullanıyorsanız kodunuzu işlemlerde yapabilirsiniz. dev.mysql.com/doc/refman/5.0/en/commit.html

1
Yavaş sorgu günlüğü açık olsaydı, yavaş sorgular yavaş sorgu günlüğünde olabilirdi.

3
Ve düzgün bir şekilde tamamlanmaması durumunda, bir yedeğiniz var mı?

Yanıtlar:


9

İkili günlükler etkinken çalıştırıyorsanız, bu nispeten yüksek güvenilirlikle kontrol edilebilir.

İlk olarak, ikili günlüklerin gerçekten etkin olup olmadığını görmek için şunu çalıştırın:

SHOW BINARY LOGS;

Etkinleştirildiyse, şöyle bir çıktı almalısınız:

+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000244 |  15462544 |
| mysql-bin.000245 | 102622775 |
+------------------+-----------+

Aksi takdirde bir hata mesajı alırsınız.

Şimdi, ikili günlükler etkinleştirilirse, başarılı günlükler de ikili günlüklere yazılır. "Taahhüt" diyorum ama gerçek şu ki, MyISAM gibi işlem dışı tablolarda bile başarılı bir işlem var. Ancak, dürüst olmak gerekirse, sorgularınızın sonucuyla ilgili herhangi bir kesinliğe sahip olmak için, InnoDB gibi bir işlem motoru kullandığınız ya da başka bir şeyden emin olamayacağınızı umuyorum.

Tamam, şimdi ikili günlükleri açtığınızı ve tablolarınızın işlemsel (umarım InnoDB) olduğunu varsayarak, sorgularınızın başarılı bir şekilde tamamlanmasının ikili günlüklere yazılması beklenir.

Şimdi ilgili ikili günlüğü avlamalı ve burada sorguyu aramalısınız. Eğer sorguyu bulursanız - iyi! Değilse - büyük olasılıkla orada değildir. Kısaca açıklayacağım.

Hangi ikili günlük sorgunuzu içerir? Tipik olarak veri dizininizdeki ikili günlük dosyalarına bakın. Zaman damgalarını arayın. Güç geldiğinde yeni bir ikili kütük oluşturuldu. Bul onu. Sizin sorguları büyük olasılıkla ikili günlük birinde önce o biri. Bu bir tahmin. Bundan önce de olabilir, vs. Ama bu iyi bir tahmin.

Şimdi, mysqlbinlogyardımcı programı kullanarak, komut satırından böyle bir şey yürütün:

mysqlbinlog mysql-bin.000245

Dosya adını, sorguyu içerdiğinden şüphelendiğiniz adla değiştirin.

Bu, bu ikili günlük dosyasındaki tüm sorguları standart çıktıya verir. Unix'te grepsorgunuzu bulmak için kullanın:

mysqlbinlog mysql-bin.000245 | grep "something which identifies the query"

Windows'da iyi şanslar. Notepad ++ veya başka bir şeyle açın ve manuel olarak arayın.

Sorgu orada mı? Harika - bunun yapıldığını biliyorsun .

Sorgu orada değil mi? sync_binlogParam üzerinde kontrol etmek gerekiyor . Öyle mi 1 ? Sonra ikili günlük ==> sorgu işlenmedi sorgu. Ancak sync_binlog, 1 değilse , commitikili günlük diske boşaltıldıktan hemen sonra ve çökmeden önce, sorgu henüz ikili günlükte işlenmemiş olabilir . Daha sonra başka yollara dönmeniz gerekir.

Bunlar: (ve umarım, yine de InnoDB kullanıyorsunuz): Sorgunun sonucunu tanımlayabilecek tek bir satır arayın. InnoDB ile "ya hep ya hiç" elde edersiniz. Sorgudan etkilenen tek bir satırdan eminseniz, sorgunun tamamlandığından emin olabilirsiniz.

edit: tabii ki, yavaş günlük etkinse, böyle uzun bir sorgu tamamlandıktan sonra orada oturum açılmasını bekleyebilirsiniz ...

İyi şanslar!


2
Umarım etrafta dolaşırsın.
jcolebrand

2
@jcolebrand Rolando burada biraz rekabet edebilirdi :)
Philᵀᴹ
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.