MySQL Yedeği Geri Yüklendi: Verinin Eksiksiz Olduğu Nasıl Kontrol Edilir?

“İçe aktarma başarıyla tamamlandı” mesajı, yedeğin uygulamanın ihtiyaç duyduğu bütün veriyi içerdiğini söylemez. Yanlış veritabanı seçilmiş, bazı tablolar yedeğe alınmamış, karakterler dönüşmüş veya uygulamanın kullandığı tetikleyiciler eksik kalmış olabilir. Geri yüklemeyi bitiren şey son SQL komutunun çalışması değil, geri dönen verinin beklenen veri olduğunun kontrolüdür.

Kontrolü üretimden ayrı bir ortamda yapın. Geri yüklenen uygulamanın e-posta, ödeme, webhook ve zamanlanmış görevlerini gerçek sistemlere bağlamayın. Veritabanı event scheduler'ı da testte kapalı veya kontrollü olmalıdır. Bir yedeği denemek, eski işlerin yeniden çalışmasına neden olmamalıdır.

Dosya aynı mı, veri doğru mu?

Yedeği başka bir bilgisayara taşırken SHA-256 özeti dosyanın değişmediğini kontrol etmek için yararlıdır. Windows PowerShell'de aşağıdaki komutu hem kaynak hem hedef dosya üzerinde çalıştırıp değerleri karşılaştırabilirsiniz:

Get-FileHash -LiteralPath 'C:\Backups\site.sql' -Algorithm SHA256

Özetlerin aynı olması, iki dosyanın aynı baytlara sahip olduğuna güçlü bir işarettir. Kaynak yedek eksikse onun eksik kopyası da aynı özeti verir. Bu yüzden dosya bütünlüğünü, mantıksal veri doğrulamasının yerine koymayın. Yedekleme komutu, çıkış kodu, hata günlüğü ve yedeğe giren nesne listesi de saklanmalıdır.

Karşılaştırdığınız kaynak hangi ana ait?

Canlı veritabanı yazım almaya devam ederken bir saat önceki yedeği bugünkü kayıt sayısıyla karşılaştırmak yanıltıcıdır. Kaynak ölçümler, yedeğin ait olduğu tutarlı görüntüyle eşleşmelidir. Kontrollü bir yazım durdurma aralığı veya uygun snapshot yöntemi planlayın; yalnızca iki sorguyu peş peşe çalıştırmak bütün tablolar için aynı anı garanti etmez.

mysqldump --single-transaction, InnoDB gibi uygun işlemsel tablolar için tutarlı okuma sağlar; MyISAM tablolarını aynı şekilde korumaz. Yedekleme sırasında şema değiştiren işlemler de ayrıca ele alınmalıdır. Kullanılan yöntemin hangi motorları ve nesneleri kapsadığını kayıt altına alın.

Tablo listesi ve gerçek kayıt sayıları

SHOW FULL TABLES FROM restore_test;
SELECT COUNT(*) AS kullanici_sayisi FROM restore_test.kullanicilar;
SELECT COUNT(*) AS siparis_sayisi FROM restore_test.siparisler;

Buradaki adlar örnektir; kendi şemanıza uyarlayın. InnoDB için information_schema.tables.TABLE_ROWS tahmini olabilir. Panelde görünen yaklaşık sayıları kesin kayıt sayısı sanmayın. Büyük tabloda COUNT(*) maliyetli olabileceği için kontrolleri test ortamında ve planlı şekilde yürütün.

Tablo sayısının eşleşmesi de tek başına yeterli değildir. Tablo adlarını, motorlarını, sütun türlerini, varsayılan değerlerini ve indekslerini karşılaştırın. Boş olması beklenen tabloyla yedeğe yanlışlıkla verisiz alınmış tablo aynı görünür; beklenen durumun kaydı gerekir.

Aynı sayıda ama farklı içerikte kayıt olabilir

Aşağıdaki örnek, aynı test sunucusunda kaynak_snapshot ve restore_test adlı iki sabit kopyanın bulunduğunu varsayar. yazilar tablosunda benzersiz id ile baslik ve icerik alanları vardır. İlk sorgu eksik veya içeriği farklı kayıtları, ikinci sorgu hedefte fazladan bulunanları gösterir.

SELECT s.id
FROM kaynak_snapshot.yazilar AS s
LEFT JOIN restore_test.yazilar AS t ON t.id = s.id
WHERE t.id IS NULL
   OR NOT (CAST(s.baslik AS BINARY) <=> CAST(t.baslik AS BINARY))
   OR NOT (CAST(s.icerik AS BINARY) <=> CAST(t.icerik AS BINARY));

SELECT t.id
FROM restore_test.yazilar AS t
LEFT JOIN kaynak_snapshot.yazilar AS s ON s.id = t.id
WHERE s.id IS NULL;

NULL güvenli eşitlik operatörü, boş metinle NULL değerini birbirine karıştırmaz. BINARY dönüşümü metin karşılaştırmasının büyük-küçük harf veya aksan farkını gizlemesini önler. Bu örnek yalnızca seçilen alanları doğrular; kendi tablonuzdaki diğer önemli sütunları da ekleyin. Gerçek dönüşüm planında beklenen bir fark varsa onu ayrıca belgeleyin.

Çok büyük tablolarda birincil anahtar aralıklarıyla parçalı karşılaştırma yapılabilir. Rastgele birkaç kaydın doğru çıkması yalnızca örneklem kontrolüdür; bütün verinin eşit olduğunu kanıtlamaz. Motor ve sürüm farkları varken tek bir tablo checksum değerini bağlamından koparıp mutlak doğruluk ölçüsü olarak kullanmayın.

İlişkilerde sahipsiz kayıt arayın

Yükleme sırasında foreign key kontrolü kapatılmışsa yeniden açılması, arada eklenen bütün kayıtları geriye dönük tarayıp doğrulamaz. İlişkiyi açık bir sorguyla kontrol edin. Aşağıdaki örnekte NULL kullanıcı kimliği iş kuralınca izin verilen anonim siparişleri temsil eder; bu nedenle dışarıda bırakılır.

SELECT s.id, s.kullanici_id
FROM restore_test.siparisler AS s
LEFT JOIN restore_test.kullanicilar AS k ON k.id = s.kullanici_id
WHERE s.kullanici_id IS NOT NULL AND k.id IS NULL;

Bu sorgunun boş dönmesi beklenir. Her ilişki için benzer kontrol gerekir; yalnızca uygulamanın ana tablosuna bakmak yeterli değildir. NULL değerine iş kuralınız izin vermiyorsa onu ayrı bir hata olarak sayın. Çakışan kimlikler yeniden eşlendiyse bağlı tabloların aynı eşlemeyi kullandığından emin olun.

Veri dışındaki nesneleri de açın

View, trigger, procedure, function ve event listelerini kaynak envanteriyle karşılaştırın. Döküm aracının seçenekleri bu nesneleri kapsamayabilir. DEFINER hesabının hedefte bulunmaması veya yetkilerinin değişmesi, nesne oluşsa bile uygulama çağrısında hata verebilir. Yetki sorununu herkese geniş ayrıcalık tanıyarak geçiştirmeyin.

Son aşamada test uygulamasından oturum açma, kayıt ekleme ve düzenleme gibi temel akışları çalıştırın. Türkçe metin ve emoji içeren örnekleri bayt düzeyindeki kodlama kontrolleriyle birlikte değerlendirin. Beklenmeyen fark varsa canlı bağlantıyı değiştirmeyin; farkın nedenini, etkilenen tabloları ve tekrar test sonucunu kayda alın.

Teknik başvuru: mysqldump seçenekleri, TABLES metaverisi ve foreign key kontrolleri.