İçeriğe geç
DuyurularBilgi bankasıKampanyalar
Hakkımızdaİletişim DestekTREN
hostingsepetiWEB HOSTING & SUNUCU
Sunucu ve Güvenlik

MariaDB ve MySQL: tutarlı yedek ve izole geri yükleme

Tablo motoru ve kapsamı kontrol ederek veritabanını yedekleyin; üretimin üzerine yazmadan ayrı ortamda geri yükleyin.

MariaDB ve MySQL: tutarlı yedek ve izole geri yükleme

Bir SQL yedeğinin oluşması, veritabanının tutarlı biçimde kurtarılabileceğini tek başına göstermez. Tablo motoru, eşzamanlı işlemler, şema değişiklikleri ve yedeklenen nesne kapsamı sonucu etkiler. MariaDB ile MySQL istemcilerinin sürüm ve seçenekleri de farklılaşabilir. Önce hangi uygulamanın hangi veritabanını kullandığını belirleyin. Geri yükleme testini üretimden ayrı bir veritabanı ve erişim hesabında yapın; canlı tabloya yanlışlıkla içe aktarım veri kaybına yol açabilir.

Başlamadan önce

Sunucu ve istemci sürümünü, tabloların motorlarını ve uygulamanın değişim hızını kaydedin. Çıktının saklanacağı güvenli konumda yeterli boş alan olduğunu kontrol edin. Yedek kullanıcısına yalnızca gereken yetkileri verin. Parolayı komut satırına açık metin olarak koymayın; uygun istemci yapılandırması veya parola istemi kullanın. Arşivi belge köküne veya herkese açık indirme yoluna bırakmayın.

Uygulama adımları

1. Tutarlılık yöntemini seçin

InnoDB gibi transaction destekleyen tablolarda single-transaction yaklaşımını değerlendirin. Bu seçenek transaction desteklemeyen tabloları aynı güvenceyle kapsamaz.

Kontrol: Karma motor varsa uygulama ve kilitleme planı ayrıca gerekir. Yedek sırasında şema değiştiren işlemleri durdurmadan tutarlılığı varsaymayın.

2. Nesne kapsamını belirleyin

Sadece tablo verisini değil gerekli view, trigger, routine ve event nesnelerini de envantere alın. Kullandığınız istemcinin seçeneklerini kendi sürüm belgesinden kontrol edin.

Kontrol: Uygulamanın ihtiyaç duyduğu nesnelerin çıktıda bulunduğunu görün. Başka sürüme ait hazır komutu kontrol etmeden kopyalamayın.

3. Çıktıyı ve tamamlanmayı doğrulayın

Yedek komutunun çıkış kodunu, hata çıktısını, dosya boyutunu ve tamamlanma zamanını kaydedin. Son dosya için hash değeri üretip saklayın.

Kontrol: Boş veya yarıda kalmış çıktı sağlıklı yedek sayılmaz. Yalnızca dosyanın varlığıyla işlemi başarılı işaretlemeyin.

4. İzole hedefe geri yükleyin

Ayrı sunucu veya açıkça adlandırılmış test veritabanı hazırlayın. Dump içindeki veritabanı oluşturma ve seçme ifadelerini hedef açısından inceleyin.

Kontrol: Kullanılan hesap üretim veritabanını değiştirememelidir. İçe aktarımdan önce hedef adını ikinci kez doğrulayın ve gerekli dış servisleri kapatın.

Sonucu nasıl doğrularsınız?

Test hedefinde tablo sayısı, kritik satır sayıları, son işlem zamanı ve önemli veri örneklerini karşılaştırın. Birkaç uygulama sorgusunu çalıştırın; yalnızca import işleminin bitmesi yeterli değildir. Kodlama ve karakter dönüşümünü Türkçe içerikle sınayın. Prosedür veya event kullanan uygulamada bunların varlığını ayrıca doğrulayın. Kurtarma süresini not edin ve yedeğin hedef sürümle gerçekten uyumlu olduğunu belgeleyin.

Sorun devam ederse

İçe aktarım sürüm hatası verirse dump istemcisiyle hedef istemcinin uyumunu kontrol edin; dosyayı rastgele toplu değiştirerek kurtarmaya çalışmayın. Eksik nesneler uygulamayı kısmen çalıştırabilir. Büyük yedekte süre, disk veya ağ kopması ayrı etkiler oluşturur. Başarısız denemede üretim hedefini kullanmak yerine yeni temiz test veritabanı hazırlayın. Test ortamındaki gerçek müşteri verisini erişim ve saklama politikanıza göre koruyun.

Uygulama örneği

Bir sipariş uygulamasının yedeğini sınarken orders ve order_items tablolarının son kayıtlarını birlikte karşılaştırın. Aynı siparişin başlığı bulunup satırları eksikse dosya varlığı yeterli kanıt değildir. Test hesabıyla uygulamanın sadece okuma kontrolünü yapın, dış ödeme bildirimlerini kapalı tutun. Kabul kaydında yedek tarihi, hash, istemci sürümü ve test hedefi bulunmalı; parola veya müşteri kart verisi bulunmamalıdır.

Sık sorulan sorular

single-transaction her tablo için yeterli mi?

Hayır. Transaction desteklemeyen tablolar ve eşzamanlı şema değişimi için aynı tutarlılık varsayımı geçerli değildir. Tablo motorunu ve iş akışını önceden inceleyin.

Yedeği canlı veritabanında test edebilir miyim?

Geri yükleme mevcut tabloları değiştirebilir veya silebilir. Test için üretime yazma yetkisi olmayan ayrı hesap ve izole hedef kullanın.

İşletim kabulü ve bakım kaydı

Geri yüklenen view ve routine nesnelerindeki DEFINER hesabını ve gereken yetkileri ayrıca kontrol edin. Test ortamında aynı hesap bulunmaması çalıştırma hatası oluşturabilir; üretim yetkilerini körlemesine kopyalamak yerine gerekli erişimi sınırlı biçimde tanımlayın. Test sonunda uygulamanın gerçekten ihtiyaç duyduğu sorguyu çalıştırıp sonucu kaydedin. Nesne sayısının eşit olması, nesnenin doğru yetkiyle çalıştığını göstermez.

İlgili rehberler

Süreç özeti

MariaDB ve MySQL: tutarlı yedek ve izole geri yükleme için kontrol sırası

AdımKontrol
1Tutarlılık yöntemini seçin
2Nesne kapsamını belirleyin
3Çıktıyı ve tamamlanmayı doğrulayın
4İzole hedefe geri yükleyin

Resmî kaynaklar